Codetools/de: what changed

Revision 4 to 5. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		# Was sind die CodeTools
2	2
3	3		Die CodeTools sind ein Lazarus-Package mit Werkzeugen zum Parsen, Untersuchen, Bearbeiten und Refaktorieren von Pascal-Quelltexten. Die CodeTools sind ein Modul für sich und unter der GPL lizensiert. Zahlreiche Beispiele, wie Sie die CodeTools in Ihren eigenen Programmen einsetzen können, finden Sie unter 'components/codetools/examples'.
4	4
5	5		svn:
6	6
7	7		- Lazarus: <http://svn.freepascal.org/svn/lazarus/trunk>
8	8		- Nur CodeTools: <http://svn.freepascal.org/svn/lazarus/trunk/components/codetools>
9	9
10	10		# Verwendung der CodeTools ohne die IDE (gut für Testzwecke)
11	11
12	12		Sie können die CodeTools ohne die IDE verwenden. Dies kann zum Testen eines neuen Werkzeugs genutzt werden. Ein einfaches Beispiel ist
13	13
14		-	~~```~~
	14	+	```text
15	15		<lazarusdir>/components/codetools/examples/methodjumping.lpi
16	16		```
17	17
18	18		Um die find declaration zu testen, müssen die CodeTools die Quellen analysieren, besonders die RTL- und FCL-Quellen. Die Beispiele benutzen folgende Umgebungsvariablen:
19	19
20	20		- FPCDIR: der Pfad zu den FPC-Quelltexten, die Vorgabe ist ~/freepascal/fpc.
21	21		- PP: der Pfad zum ausführbaren Kompiler (/usr/bin/fpc oder /usr/bin/ppc386 oder C:\lazarus\ppc386.exe). Die CodeTools müssen den Kompiler nach den Einstellungen fragen. Als Vorgabe wird mittels der Variablen 'PATH' nach 'fpc' gesucht.
22	22		- FPCTARGETOS: weist die CodeTools an, nach einem weiteren Betriebssystem zu suchen ("cross compiling"). Zum Beispiel: linux, freebsd, darwin, win32, win64, wince
23	23		- FPCTARGETCPU: sucht nach einer anderen CPU. Zum Beispiel: i386, powerpc, x86_64, arm, sparc
24	24		- LAZARUSDIR: der Pfad zu den Lazarus-Quelltexten. Wird nur benötigt, wenn Sie diese untersuchen wollen.
25	25
26	26		FPC ist ein sehr komplexes Projekt mit vielen Suchpfaden, Include-Dateien und Makros. Die CodeTools müssen alle diese Pfade und Makros kennen, um diesen Dschungel zu analysieren. Um dies alles einfach einzurichten, enthalten die CodeTools vordefinierte Schablonen für FPC-, Lazarus-, Delphi- und Kylix-Quellverzeichnisse. Betrachten Sie für ein find declaration folgendes Beispiel
27	27
28		-	~~```~~
	28	+	```text
29	29		<lazarusdir>/components/codetools/examples/finddeclaration.lpi
30	30		```
31	31
32	32		Weil die FPC-Quellen mehrere Versionen einiger Units enthalten und die FPC-Quellen oft geändert werden, verwenden die CodeTools keine starre Pfadtabelle. Stattdessen scannen sie zuerst die gesamte FPC Verzeichnisstruktur und versuchen mittels einiger Regeln herauszufinden, welche Quelle die richtige ist für das gegenwärtige ZielOS und ZielCPU. Dieser Scan kann eine Weile dauern. Alle Beipiele speichern das Ergebnis in codetools.config, damit diese Suche beim nächsten Start übersprungen wird.
33	33
34	34		Wann immer die FPC-Quellen verschoben wurden oder eine Unit umbenannt wurde, löschen Sie einfach die Datei codetools.config. Die Lazarus-IDE hat ihre eigene Konfigurationsdatei und erledigt den Rescan, wann immer das Compiler executable geändert wurde oder der Benutzer dies erzwingt mit 'Einstellungen \> FPC-Quelltextverzeichnis neu einlesen'.
35	35
36	36		# Verwendung der CodeTools in der IDE mit dem IDEIntf
37	37
38	38		Siehe das \<lazarusdir\>/examples/idequickfix/quickfixexample.lpk Package. Es demonstriert:
39	39
40	40		- Wie man ein IDE-Package schreibt. Wenn Sie es installieren, wird es ein Quick-Fix-Element registrieren.
41	41		- Wie man ein Quick-Fix-Element schreibt für die Compilermeldung 'Parameter "Sender" not used'
42	42		- Wie man die CodeTools verwendet, um
43	43		- eine Unit zu analysieren
44	44		- Dateiname, Zeile, Spalte in eine CodeTools Quelltextposition umzuwandeln
45	45		- ein CodeTools-Element an der Cursorposition zu finden
46	46		- ein 'procedure'-Element und das 'begin..end'-Element zu finden
47	47		- für eine Anweisung eine günstige Einfügeposition am Anfang eines 'begin..end'-Blocks zu ermitteln
48	48		- die Einrückung einer Zeile zu erhalten, damit sich die neue Zeile in die Prozedur einfügt
49	49		- Code einzufügen mit den CodeTools
50	50
51	51		# Codetools-Regeln für FPC-Quelltexte
52	52
53	53		Wenn die CodeTools die Quelltexte nach einer FPC ppu-Datei durchsuchen, verwenden sie einen Satz von Regeln. Sie können Ihre eigenen Regeln Schreiben, aber normalerweise werden Sie die Standardregeln benutzen, die in der der Includedatei 'components/codetools/fpcsrcrules.inc' festgelegt sind. Sie können die Regeln testen mit dem Befehlszeilenwerkzeug: components/codetools/examples/testfpcsrcunitrules.lpi.
54	54
55	55		## Gebrauch von testfpcsrcunitrules
56	56
57	57		Gebrauch: lazarus/components/codetools/examples/testfpcsrcunitrules -h
58	58
59	59		-c <compiler file name>, --compiler=<compiler file name>
60	60		Vorgabe ist es, die Umgebungsvariable PP zu benutzen.
61	61		Wenn nicht angegeben, suche nach fpc
62	62
63	63		-T <target OS>, --targetos=<target OS>
64	64		Vorgabe ist es, die Umgebungsvariable FPCTARGET zu benutzen.
65	65		Wenn nicht angegeben, nimm die Vorgabe des Kompilers.
66	66
67	67		-P <target CPU>, --targetcpu=<target CPU>
68	68		Vorgabe ist es, die Umgebungsvariable FPCTARGETCPU zu benutzen.
69	69		Wenn nicht angegeben, nimm die Vorgabe des Kompilers.
70	70
71	71		-F <FPC source directory>, --fpcsrcdir=<FPC source directory>
72	72		Vorgabe ist es, die Umgebungsvariable FPCDIR zu benutzen.
73	73		Es gibt keine andere Vorgabe.
74	74
75	75		-u <unit name>, --checkunit=<unit name>
76	76		Schreibe einen detailierten Bericht über diese Unit.
77	77
78	78		## Beispiel für testfpcsrcunitrules
79	79
80	80		Öffnen Sie die Datei 'testfpcsrcunitrules.lpi' in der IDE und kompilieren Sie sie. Starten Sie dann das Werkzeug in einer Befehlszeile/Konsole:
81	81
82		-	~~```~~
	82	+	```text
83	83		./testfpcsrcunitrules -F ~/fpc/sources/2.5.1/fpc/
84	84		```
85	85
86	86		Dadurch erfahren Sie, welcher Kompiler benutzt wird, welcher Kompiler ausgeführt wird, welche Konfigurationsdateinen getestet und analysiert wurden, Sie werden gewarnt über doppelte Units im FPC-Suchpfad und doppelte Quelltextdateien für die selbe Unit.
87	87
88	88		## Doppelte Quelltextdateien
89	89
90	90		Angenommen, Sie finden heraus, dass die CodeTools für das Ziel 'wince/arm' den falschen Quelltext der Unit mmsystem öffnen. Starten Sie das Werkzeug mit dem Parameter '-u':
91	91
92	92		./testfpcsrcunitrules -F ~/fpc/2.5.1/fpc/ -T wince -P arm -u mmsystem
93	93
94	94		Dadurch erhalten Sie einen detaillierten Bericht darüber, wo diese Unit gefunden wurde und welches Score jede Quelltextdatei erzielt hat. Zum Beispiel:
95	95
96	96		``` pascal
97	97		Unit report for mmsystem
98	98		WARNING: mmsystem is not in PPU search path
99	99		GatherUnitsInFPCSources UnitName=mmsystem File=packages/winunits-base/src/mmsystem.pp Score=11
100	100		GatherUnitsInFPCSources UnitName=mmsystem File=packages/winceunits/src/mmsystem.pp Score=11 => duplicate
101	101		```
102	102
103	103		Dies bedeutet, dass es zwei Quelltextdateien mit dem selben Score gibt, sodass die CodeTools die erste genommen haben. Die letzte im Verzeichnis 'winceunits' ist für das Ziel 'wince' und die erste ist für 'win32' und 'win64'.
104	104
105	105		Öffnen Sie jetzt die Regeldatei 'fpcsrcrules.inc'.
106	106
107	107		Regeln arbeiten so:
108	108
109	109		``` pascal
110	110		Score:=10;
111	111		Targets:='wince';
112	112		Add('packages/winceunits');
113	113		```
114	114
115	115		Das Add fügt eine Regel hinzu für alle Dateien, die mit 'packages/winceunits' beginnen. Zum Score all dieser Dateien wird 10 addiert. Targets ist eine durch Kommas getrennte Liste von Zielbetriebssystemen und/oder Zielprozessoren. Beispielsweise: Targets='wince,linux,i386' bedeutet: wende diese Regel auf das ZielOS 'wince' oder 'linux' und auf die ZielCPU i386 an.
116	116
117	117		# Wie die CodeTools Quelltexte untersuchen, abhängig von einem Kompiler
118	118
119	119		Ein Kompiler ist dazu optimiert den Code linear zu durchlaufen und die benötigten Units und Includedateien dann zu laden, wenn er einen uses-Abschnitt oder eine Direktive findet. Die CodeTools sind dazu optimiert, nur Teile des Codes zu untersuchen. Beispielsweise braucht der Sprung von einer Methodendeklaration zum Methodenrumpf nur die Unit und ihre Includedateien. Wenn die CodeTools eine Deklaration suchen, dann suchen sie rückwärts. Das bedeutet, sie starten die Suche in den lokalen Variablen und dann oberhalb in der Implementation. Wenn sie einen uses-Abschnitt vorfinden, suchen sie den Bezeichner im Abschnitt 'interface' der Units. Wird der Bezeichner gefunden, halten sie an. Das Ergebnis und einige Zwischenschritte werden gecached. Weil oftmals nur einige interface-Abschnitte durchsucht werden müssen, wird ein einzelner Bezeichner rasch gefunden.
120	120
121	121		Die CodeTools durchsuchen einen Quelltext nicht in einem Durchgang wie ein Kompiler, sondern in mehreren Durchgängen, abhängig von den Erfordernissen der aktuellen Funktion:
122	122
123	123		- Zuerst wird ein Quelltext in einen TCodeBuffer geladen. Die IDE benutzt diesen Schritt, um die Kodierung in UTF8 zu ändern. Die Dateien werden im Speicher gehalten und nur nachgeladen, wenn sich das Änderungsdatum ändert oder eine Datei manuell umgeändert wird. Es gibt einige Tools und Funktionen die direkt mit dem Puffer arbeiten.
124	124		- Die nächste Ebene ist das Untersuchen einer Unit oder Includedatei. Eine Unit muss vom Anfang an durchlaufen werden, deshalb versuchen die CodeTools die Hauptdatei herauszufinden, die erste Datei einer Unit. Dabei suchen sie in der ersten Zeile nach einer Direktive, wie {%MainUnit ../lclintf.pp}. Falls diese nicht existiert, wird der 'includelink cache' durchsucht. Die IDE speichert diesen Cache auf dem Laufwerk, so lernt die IDE mit der Zeit dazu.
125	125		- Nachdem die Hauptdatei gefunden wurde, scannt TLinkScanner den Quelltext. Er verarbeitet Kompilerdirektiven, wie Include-Direktiven und 'if-else'-Direktiven. Dem Scanner kann ein Bereich übergeben werden, beispielsweise um nur das Interface einer Unit zu durchsuchen. Der Scanner erzeugt den clean source. Der 'clean source' besteht aus allen Includedateien und befreit von sämtlichen übersprungenen Codestellen aus den 'else'-Teilen. Er erzeugt auch eine Liste von links, die den 'clean source' und die realen Quelltextdatein verbinden. Der 'clean source' ist jetzt Pascal. Beachten Sie: es gibt auch Tools, um eine einzelne Quelle nach allen Direktiven zu durchsuchen und einen Direktivenbaum zu erstellen.
126	126		- Nach dem Erzeugen des 'clean source' untersucht ein TCodeTool diesen und erstellt einen Baum von 'TCodeTreeNode'-Elementen. Auch hier ist eine Bereichsangabe möglich. Dieser Parser überspringt einige Teile, zum Beispiel 'class members', 'begin..end'-Blocks und Parameterlisten. Viele Tools brauchen diese nicht. Diese Unterknoten werden nur bei Bedarf erzeugt. Ein TCodeTreeNode hat einen Bereich StartPos..EndPos, welche 'clean positions' sind, also Positionen im 'clean source'. Es gibt nur Knoten für die wichtigen Teile. Knoten für jedes Detail zu erstellen würde mehr Speicher benötigen als der Quelltext selbst und ist auch selten erforderlich. Zahlreiche Funktionen sind dazu da, die Details herauszufinden. Ob beispielsweise eine Funktion der Aufrufskonvention 'cdecl' entspricht.
127	127		- Wird ein Bezeichner gesucht, dann speichert die Suche die gefundenen Basistypen und erzeugt Caches für alle Bezeichner aus dem Interface-Abschnitt.
128	128
129	129		Jede Ebene hat ihre eigenen Caches, die vor dem Aufruf einer Funktion geprüft und aktualisiert werden müssen. Viele High-level-Funktionen, auf die mittels 'CodeToolBoss' zugegriffen werden kann, machen das automatisch. Für andere liegt die Verantwortung beim aufrufenden Prozess.
130	130
131	131		Ein Beispiel dafür:
132	132
133	133		unti1.pas:
134	134
135	135		``` pascal
136	136		unit Unit1;
137	137		{$I settings.inc}
138	138		interface
139	139		uses
140	140		{$IFDEF Flag}
141	141		unix,
142	142		{$ELSE}
143	143		windows,
144	144		{$ENDIF}
145	145		Classes;
146	146		```
147	147
148	148		settings.inc:
149	149
150	150		``` pascal
151	151		{%MainUnit unit1.pas}
152	152		{$DEFINE Flag}
153	153		```
154	154
155	155		clean source:
156	156
157	157		``` pascal
158	158		unit Unit1;
159	159		{$I settings.inc}{%MainUnit unit1.pas}
160	160		{$DEFINE Flag}
161	161		interface
162	162		uses
163	163		{$IFDEF Flag}
164	164		unix,
165	165		{$ELSE}{$ENDIF}
166	166		Classes;
167	167		```
168	168
169	169		Tipp: Um eine Unit einfach zu durchlaufen und die Knoten zu erstellen, verwenden Sie CodeToolBoss.Explore.
170	170
171	171		# Clean Position und Kursorposition
172	172
173	173		Es gibt verschiedene Methoden, um in den CodeTools eine Position zu definieren.
174	174
175	175		Die absolute Position bezieht sich auf den Quelltext als Zeichenkette und beginnt bei 1. Beispielsweise hält ein TCodeBuffer den Dateiinhalt als Zeichenkette in der Eigenschaft 'Source'. Die Positionen der Einfügemarke oder des Kursors sind als X,Y gegeben, wobei Y die Zeilennummer ist (bei 1 beginnend) und X die Spaltennummer (bei 1 beginnend). Ein TCodeBuffer stellt zum Umwandeln die Funktionen LineColToPosition und AbsoluteToLineCol'' zur Verfügung. Wenn Sie mit mehreren Quelltextdateinen arbeiten, wie einer Unit, die aus verschiedenen Includedateien bestehen kann, dann bezieht sich 'Clean Position' auf die absolute Position im bereinigten CodeSrc. Src ist eine Zeichenkette und Clean Positions beginnt bei 1. Die Kursorpositionen werden angegeben als TCodeXYPosition (Code,X,Y). Ein TCodeTool stellt zum Umwandeln die FunktionenCaretToCleanPos,CleanPosToCaret''' zur Verfügung.
176	176
177	177		# Einfügen, Löschen und Ersetzen - der TSourceChangeCache
178	178
179	179		Wenn Sie Änderungen am Quelltext einer Unit (oder ihrer Includedateien) vornehmen, sollten Sie dazu 'CodetoolBoss.SourceChangeCache' benutzen, weil:
180	180
181	181		- Einfache Anwendung. Verbinden, ersetzen, ersetzen, ... anwenden. Siehe unten.
182	182		- Sie benutzen 'cleanpos' wie durch den Knotenbaum gegeben ODER Sie benutzen die direkten Positionen in einer Datei.
183	183		- Sie können 'Replace' zum Einfügen und Löschen benutzen. Dies löst automatisch Ereignisse aus, wodurch verbundene Editoren über Veränderungen benachrichtigt werden.
184	184		- Es können automatisch benötigte Leerzeichen eingefügt werden, ebenso Zeilenendezeichen oder Leerzeilen vor doer nach jedem Replace. Zum Beispiel definieren Sie, dass jeweils eine Leerzeile voran gehen soll. Der SourceChangeCache prüft, was eingefügt werden soll, wie viel Platz bereits dort ist und wird den notwendigen Platz einfügen.
185	185		- Er überprüft, ob der Bereich für Ersetzen/Löschen beschreibbar ist.
186	186		- Sie können mehrfache Ersetzungen vornehmen und Sie steuern, wann diese angewendet werden. Bedenken Sie dabei, dass das Einfügen von Code bedeutet, dass der untersuchte Baum ungültig wird und neu erstellt werden muss.
187	187		- Mehrfache Ersetzungen werden auf Überschneidungen geprüft. Zum Beispiel erhalten Sie beim Einfügen in der Mitte eines gelöschten Codes eine Fehlermeldung.
188	188		- Mehrfache Ersetzungen an der selben Stelle werden reihenweise abgearbeitet (nach dem FIFO-Prinzip).
189	189		- Sie können verschiedene Funktionen zum Bearbeiten von Code zu einer größeren Funktion kombinieren. Siehe unten.
190	190
191	191		## Verwendung
192	192
193	193		Der SourceChangeCache arbeitet mit einer Unit, deshalb müssen Sie ein TCodeTool nehmen und eine Unit/Includedatei damit scannen. Zum Beispiel:
194	194
195	195		``` pascal
196	196		// Schritt 1: lade die Datei und untersuche sie
197	197		Code:=CodeToolBoss.LoadFile(Filename,false,false);
198	198		if Code=nil then
199	199		raise Exception.Create('loading failed '+Filename);
200	200		if not CodeToolBoss.Explore(Code,Tool,false) then
201	201		...;// Fehler beim Untersuchen ...
202	202
203	203		// Schritt 2: verbinde mit dem SourceChangeCache
204	204		CodeToolBoss.SourceChangeCache.MainScanner:=Tool.Scanner;
205	205
206	206		// Schritt 3: nimm Replace zum Einfügen und/oder Löschen von Code.
207	207		// Die beiden ersten Parameter sind die benötigten Leerzeichen vor und hinter der Einfügestelle.
208	208		// FromPos, ToPos legen den gelöschten/ersetzten Bereich in CleanPos-Positionen fest.
209	209		// NewCode ist die Zeichenkette des neuen Codes. Verwenden Sie '' zum Löschen.
210	210		if not CodeToolBoss.SourceChangeCache.Replace(gtNone,gtNone,FromPos,ToPos,NewCode) then
211	211		exit; // z.B. Quelltext ist nicht beschreibbar oder ein vorangegangenes Ersetzen hat diese Stelle gelöscht
212	212		...einige weitere Ersetzungen...
213	213
214	214		// Schritt 4: wende die Änderungen an
215	215		if not CodeToolBoss.SourceChangeCache.Apply then
216	216		exit; // Anwendung wurde abgebrochen
217	217		```
218	218
219	219		## BeginUpdate/EndUpdate
220	220
221	221		BeginUpdate/EndUpdate verzögert die Anwendung. Dies ist nützlich, wenn Sie verschiedene Code ändernde Funktionen kombinieren. Zum Beispiel:
222	222
223	223		Sie wollen die Unit scannen, fügen eine Unit in der uses-Klausel des Interface-Bereichs hinzu und entfernen die Unit aus der uses-Klausel des Implementation-Bereichs. Die zwei Funktionen 'AddUnitToMainUsesSection' und 'RemoveUnitFromUsesSection' benutzen 'Apply', ändern den Quelltext, sodass die zweite Funktion die Unit ein zweites Mal scannen würde. Weil aber beide Funktionen voneinander unabhängig sind (Sie verändern verschiedene Teile des Quelltextes) können Sie beide miteinander kombinieren und nur einen Scan machen:
224	224
225	225		``` pascal
226	226		// Schritt 1: durchsuche die Unit und verbinde mit SourceChangeCache
227	227		if not CodeToolBoss.Explore(Code,Tool,false) then
228	228		...;// Fehler beim Untersuchen ...
229	229		CodeToolBoss.SourceChangeCache.MainScanner:=Tool.Scanner;
230	230
231	231		// Schritt 2: verzögere die Anwendung
232	232		CodeToolBoss.SourceChangeCache.BeginUpdate;
233	233
234	234		// Schritt 3: füge die Unit zum Interface-Bereich hinzu
235	235		// AddUnitToMainUsesSection würde angewendet und den Code ändern
236	236		// Wegen BeginUpdate finden die Änderungen noch nicht statt, werden aber in SourceChangeCache gespeichert
237	237		if not Tool.AddUnitToMainUsesSection('Classes','',CodeToolBoss.SourceChangeCache) then exit;
238	238
239	239		// Schritt 4: entferne die Unit aus dem Implementation-Bereich
240	240		// Ohne BeginUpdate würde RemoveUnitFromUsesSection die Unit erneut scannen
241	241		if Tool.FindImplementationUsesSection<>nil then
242	242		if not Tool.RemoveUnitFromUsesSection(Tool.FindImplementationUsesSection,'Classes',CodeToolBoss.SourceChangeCache) then exit;
243	243
244	244		// Schritt 5: wende alle Änderungen an
245	245		if not CodeToolBoss.SourceChangeCache.EndUpdate then
246	246		exit; // Anwendung wurde abgebrochen
247	247		```
248	248
249	249		BeginUpdate/EndUpdate arbeiten mit einem Zähler, wenn Sie also BeginUpdate zwei Mal aufrufen, müssen Sie auch EndUpdate zwei Mal aufrufen. Dies bedeutet, dass Sie obiges Beispiel in eine Funktion stellen und mit einer weiteren Funktion kombinieren können.
250	250
251	251		## Speichern Sie die Änderungen auf Disk
252	252
253	253		Die obigen Änderungen werden nur in den Codepuffern gemacht und diese Puffer als 'verändert' markiert. Um die Änderungen auf Disk zu speichern, müssen Sie für jeden veränderten Puffer 'Save' aufrufen.
254	254
255	255		- Die Puffer, die mit dem nächsten Apply/EndUpdate geändert werden liegen in 'SourceChangeCache.BuffersToModify' und 'BuffersToModifyCount'.
256	256		- Die Ereignisse 'SourceChangeCache.OnBeforeApplyChanges/OnAfterApplyChanges' werden von CodeToolBoss benutzt, der sie mit seinen eigenen 'OnBeforeApplyChanges/OnAfterApplyChanges' verbindet. Die Lazarus-IDE setzt diese Ereignisse und öffnet automatisch die geänderten Dateien im Quelltexteditor, dadurch scheinen alle Änderungen in der Undo-Liste von Synedit auf.
257	257
258	258		# Links
259	259
260	260		- [[Lazarus IDE Tools/de\|Lazarus IDE Tools (deutsch)]] - Ein Tutorial über die eingebauten Werkzeuge der Standard-IDE.
261	261		- [[Cody]] - ein IDE-Package mit fortgeschrittenen CodeTools.
262	262		- [[Extending the IDE/de\|Erweitern der IDE (deutsch)]] - Wie Sie Ihre eigenen CodeTool-Plugins für die IDE schreiben.
263	263
264	264		---
265	265		From the Free Pascal wiki, page "Codetools/de", as it stood on 2020-02-11 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history