Codetools/de: what changed
Revision 3 to 4. 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 | + | ``` | |
| 15 | + | <lazarusdir>/components/codetools/examples/methodjumping.lpi | |
| 16 | + | ``` | |
| 15 | 17 | ||
| 16 | 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: | |
| 17 | 19 | ||
| 18 | 20 | - FPCDIR: der Pfad zu den FPC-Quelltexten, die Vorgabe ist *~/freepascal/fpc*. | |
| 19 | 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. | |
| 20 | 22 | - FPCTARGETOS: weist die CodeTools an, nach einem weiteren Betriebssystem zu suchen ("cross compiling"). Zum Beispiel: linux, freebsd, darwin, win32, win64, wince | |
| 21 | 23 | - FPCTARGETCPU: sucht nach einer anderen CPU. Zum Beispiel: i386, powerpc, x86_64, arm, sparc | |
| 22 | 24 | - LAZARUSDIR: der Pfad zu den Lazarus-Quelltexten. Wird nur benötigt, wenn Sie diese untersuchen wollen. | |
| 23 | 25 | ||
| 24 | 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 | |
| 25 | 27 | ||
| 26 | - | ||
| 28 | + | ``` | |
| 29 | + | <lazarusdir>/components/codetools/examples/finddeclaration.lpi | |
| 30 | + | ``` | |
| 27 | 31 | ||
| 28 | 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. | |
| 29 | 33 | ||
| 30 | 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'. | |
| 31 | 35 | ||
| 32 | 36 | # Verwendung der CodeTools in der IDE mit dem IDEIntf | |
| 33 | 37 | ||
| 34 | 38 | Siehe das \<lazarusdir\>/examples/idequickfix/quickfixexample.lpk Package. Es demonstriert: | |
| 35 | 39 | ||
| 36 | 40 | - Wie man ein IDE-Package schreibt. Wenn Sie es installieren, wird es ein Quick-Fix-Element registrieren. | |
| 37 | 41 | - Wie man ein Quick-Fix-Element schreibt für die Compilermeldung 'Parameter "Sender" not used' | |
| 38 | 42 | - Wie man die CodeTools verwendet, um | |
| 39 | 43 | - eine Unit zu analysieren | |
| 40 | 44 | - Dateiname, Zeile, Spalte in eine CodeTools Quelltextposition umzuwandeln | |
| 41 | 45 | - ein CodeTools-Element an der Cursorposition zu finden | |
| 42 | 46 | - ein 'procedure'-Element und das 'begin..end'-Element zu finden | |
| 43 | 47 | - für eine Anweisung eine günstige Einfügeposition am Anfang eines 'begin..end'-Blocks zu ermitteln | |
| 44 | 48 | - die Einrückung einer Zeile zu erhalten, damit sich die neue Zeile in die Prozedur einfügt | |
| 45 | 49 | - Code einzufügen mit den CodeTools | |
| 46 | 50 | ||
| 47 | 51 | # Codetools-Regeln für FPC-Quelltexte | |
| 48 | 52 | ||
| 49 | 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. | |
| 50 | 54 | ||
| 51 | 55 | ## Gebrauch von testfpcsrcunitrules | |
| 52 | 56 | ||
| 53 | 57 | Gebrauch: lazarus/components/codetools/examples/testfpcsrcunitrules -h | |
| 54 | 58 | ||
| 55 | 59 | -c <compiler file name>, --compiler=<compiler file name> | |
| 56 | 60 | Vorgabe ist es, die Umgebungsvariable PP zu benutzen. | |
| 57 | 61 | Wenn nicht angegeben, suche nach fpc | |
| 58 | 62 | ||
| 59 | 63 | -T <target OS>, --targetos=<target OS> | |
| 60 | 64 | Vorgabe ist es, die Umgebungsvariable FPCTARGET zu benutzen. | |
| 61 | 65 | Wenn nicht angegeben, nimm die Vorgabe des Kompilers. | |
| 62 | 66 | ||
| 63 | 67 | -P <target CPU>, --targetcpu=<target CPU> | |
| 64 | 68 | Vorgabe ist es, die Umgebungsvariable FPCTARGETCPU zu benutzen. | |
| 65 | 69 | Wenn nicht angegeben, nimm die Vorgabe des Kompilers. | |
| 66 | 70 | ||
| 67 | 71 | -F <FPC source directory>, --fpcsrcdir=<FPC source directory> | |
| 68 | 72 | Vorgabe ist es, die Umgebungsvariable FPCDIR zu benutzen. | |
| 69 | 73 | Es gibt keine andere Vorgabe. | |
| 70 | 74 | ||
| 71 | 75 | -u <unit name>, --checkunit=<unit name> | |
| 72 | 76 | Schreibe einen detailierten Bericht über diese Unit. | |
| 73 | 77 | ||
| 74 | 78 | ## Beispiel für testfpcsrcunitrules | |
| 75 | 79 | ||
| 76 | 80 | Öffnen Sie die Datei 'testfpcsrcunitrules.lpi' in der IDE und kompilieren Sie sie. Starten Sie dann das Werkzeug in einer Befehlszeile/Konsole: | |
| 77 | 81 | ||
| 78 | - | ||
| 82 | + | ``` | |
| 83 | + | ./testfpcsrcunitrules -F ~/fpc/sources/2.5.1/fpc/ | |
| 84 | + | ``` | |
| 79 | 85 | ||
| 80 | 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. | |
| 81 | 87 | ||
| 82 | 88 | ## Doppelte Quelltextdateien | |
| 83 | 89 | ||
| 84 | 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': | |
| 85 | 91 | ||
| 86 | 92 | ./testfpcsrcunitrules -F ~/fpc/2.5.1/fpc/ -T wince -P arm -u mmsystem | |
| 87 | 93 | ||
| 88 | 94 | Dadurch erhalten Sie einen detaillierten Bericht darüber, wo diese Unit gefunden wurde und welches Score jede Quelltextdatei erzielt hat. Zum Beispiel: | |
| 89 | 95 | ||
| 90 | - | ||
| 91 | - | ||
| 92 | - | ||
| 93 | - | ||
| 96 | + | ``` pascal | |
| 97 | + | Unit report for mmsystem | |
| 98 | + | WARNING: mmsystem is not in PPU search path | |
| 99 | + | GatherUnitsInFPCSources UnitName=mmsystem File=packages/winunits-base/src/mmsystem.pp Score=11 | |
| 100 | + | GatherUnitsInFPCSources UnitName=mmsystem File=packages/winceunits/src/mmsystem.pp Score=11 => duplicate | |
| 101 | + | ``` | |
| 94 | 102 | ||
| 95 | 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'. | |
| 96 | 104 | ||
| 97 | 105 | Öffnen Sie jetzt die Regeldatei 'fpcsrcrules.inc'. | |
| 98 | 106 | ||
| 99 | 107 | Regeln arbeiten so: | |
| 100 | 108 | ||
| 101 | 109 | ``` pascal | |
| 102 | 110 | Score:=10; | |
| 103 | 111 | Targets:='wince'; | |
| 104 | 112 | Add('packages/winceunits'); | |
| 105 | 113 | ``` | |
| 106 | 114 | ||
| 107 | 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. | |
| 108 | 116 | ||
| 109 | 117 | # Wie die CodeTools Quelltexte untersuchen, abhängig von einem Kompiler | |
| 110 | 118 | ||
| 111 | 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. | |
| 112 | 120 | ||
| 113 | 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: | |
| 114 | 122 | ||
| 115 | 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. | |
| 116 | 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. | |
| 117 | 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. | |
| 118 | 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. | |
| 119 | 127 | - Wird ein Bezeichner gesucht, dann speichert die Suche die gefundenen Basistypen und erzeugt Caches für alle Bezeichner aus dem Interface-Abschnitt. | |
| 120 | 128 | ||
| 121 | 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. | |
| 122 | 130 | ||
| 123 | 131 | Ein Beispiel dafür: | |
| 124 | 132 | ||
| 125 | 133 | unti1.pas: | |
| 126 | 134 | ||
| 127 | 135 | ``` pascal | |
| 128 | 136 | unit Unit1; | |
| 129 | 137 | {$I settings.inc} | |
| 130 | 138 | interface | |
| 131 | 139 | uses | |
| 132 | 140 | {$IFDEF Flag} | |
| 133 | 141 | unix, | |
| 134 | 142 | {$ELSE} | |
| 135 | 143 | windows, | |
| 136 | 144 | {$ENDIF} | |
| 137 | 145 | Classes; | |
| 138 | 146 | ``` | |
| 139 | 147 | ||
| 140 | 148 | settings.inc: | |
| 141 | 149 | ||
| 142 | 150 | ``` pascal | |
| 143 | 151 | {%MainUnit unit1.pas} | |
| 144 | 152 | {$DEFINE Flag} | |
| 145 | 153 | ``` | |
| 146 | 154 | ||
| 147 | 155 | clean source: | |
| 148 | 156 | ||
| 149 | 157 | ``` pascal | |
| 150 | 158 | unit Unit1; | |
| 151 | 159 | {$I settings.inc}{%MainUnit unit1.pas} | |
| 152 | 160 | {$DEFINE Flag} | |
| 153 | 161 | interface | |
| 154 | 162 | uses | |
| 155 | 163 | {$IFDEF Flag} | |
| 156 | 164 | unix, | |
| 157 | 165 | {$ELSE}{$ENDIF} | |
| 158 | 166 | Classes; | |
| 159 | 167 | ``` | |
| 160 | 168 | ||
| 161 | 169 | Tipp: Um eine Unit einfach zu durchlaufen und die Knoten zu erstellen, verwenden Sie **CodeToolBoss.Explore**. | |
| 162 | 170 | ||
| 163 | 171 | # Clean Position und Kursorposition | |
| 164 | 172 | ||
| 165 | 173 | Es gibt verschiedene Methoden, um in den CodeTools eine Position zu definieren. | |
| 166 | 174 | ||
| 167 | 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 Code**Src**. 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 Funktionen**CaretToCleanPos**,**CleanPosToCaret''' zur Verfügung. | |
| 168 | 176 | ||
| 169 | 177 | # Einfügen, Löschen und Ersetzen - der TSourceChangeCache | |
| 170 | 178 | ||
| 171 | 179 | Wenn Sie Änderungen am Quelltext einer Unit (oder ihrer Includedateien) vornehmen, sollten Sie dazu 'CodetoolBoss.SourceChangeCache' benutzen, weil: | |
| 172 | 180 | ||
| 173 | 181 | - Einfache Anwendung. Verbinden, ersetzen, ersetzen, ... anwenden. Siehe unten. | |
| 174 | 182 | - Sie benutzen 'cleanpos' wie durch den Knotenbaum gegeben ODER Sie benutzen die direkten Positionen in einer Datei. | |
| 175 | 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. | |
| 176 | 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. | |
| 177 | 185 | - Er überprüft, ob der Bereich für Ersetzen/Löschen beschreibbar ist. | |
| 178 | 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. | |
| 179 | 187 | - Mehrfache Ersetzungen werden auf Überschneidungen geprüft. Zum Beispiel erhalten Sie beim Einfügen in der Mitte eines gelöschten Codes eine Fehlermeldung. | |
| 180 | 188 | - Mehrfache Ersetzungen an der selben Stelle werden reihenweise abgearbeitet (nach dem FIFO-Prinzip). | |
| 181 | 189 | - Sie können verschiedene Funktionen zum Bearbeiten von Code zu einer größeren Funktion kombinieren. Siehe unten. | |
| 182 | 190 | ||
| 183 | 191 | ## Verwendung | |
| 184 | 192 | ||
| 185 | 193 | Der SourceChangeCache arbeitet mit einer Unit, deshalb müssen Sie ein TCodeTool nehmen und eine Unit/Includedatei damit scannen. Zum Beispiel: | |
| 186 | 194 | ||
| 187 | 195 | ``` pascal | |
| 188 | 196 | // Schritt 1: lade die Datei und untersuche sie | |
| 189 | 197 | Code:=CodeToolBoss.LoadFile(Filename,false,false); | |
| 190 | 198 | if Code=nil then | |
| 191 | 199 | raise Exception.Create('loading failed '+Filename); | |
| 192 | 200 | if not CodeToolBoss.Explore(Code,Tool,false) then | |
| 193 | 201 | ...;// Fehler beim Untersuchen ... | |
| 194 | 202 | ||
| 195 | 203 | // Schritt 2: verbinde mit dem SourceChangeCache | |
| 196 | 204 | CodeToolBoss.SourceChangeCache.MainScanner:=Tool.Scanner; | |
| 197 | 205 | ||
| 198 | 206 | // Schritt 3: nimm Replace zum Einfügen und/oder Löschen von Code. | |
| 199 | 207 | // Die beiden ersten Parameter sind die benötigten Leerzeichen vor und hinter der Einfügestelle. | |
| 200 | 208 | // FromPos, ToPos legen den gelöschten/ersetzten Bereich in CleanPos-Positionen fest. | |
| 201 | 209 | // NewCode ist die Zeichenkette des neuen Codes. Verwenden Sie '' zum Löschen. | |
| 202 | 210 | if not CodeToolBoss.SourceChangeCache.Replace(gtNone,gtNone,FromPos,ToPos,NewCode) then | |
| 203 | 211 | exit; // z.B. Quelltext ist nicht beschreibbar oder ein vorangegangenes Ersetzen hat diese Stelle gelöscht | |
| 204 | 212 | ...einige weitere Ersetzungen... | |
| 205 | 213 | ||
| 206 | 214 | // Schritt 4: wende die Änderungen an | |
| 207 | 215 | if not CodeToolBoss.SourceChangeCache.Apply then | |
| 208 | 216 | exit; // Anwendung wurde abgebrochen | |
| 209 | 217 | ``` | |
| 210 | 218 | ||
| 211 | 219 | ## BeginUpdate/EndUpdate | |
| 212 | 220 | ||
| 213 | 221 | BeginUpdate/EndUpdate verzögert die Anwendung. Dies ist nützlich, wenn Sie verschiedene Code ändernde Funktionen kombinieren. Zum Beispiel: | |
| 214 | 222 | ||
| 215 | 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: | |
| 216 | 224 | ||
| 217 | 225 | ``` pascal | |
| 218 | 226 | // Schritt 1: durchsuche die Unit und verbinde mit SourceChangeCache | |
| 219 | 227 | if not CodeToolBoss.Explore(Code,Tool,false) then | |
| 220 | 228 | ...;// Fehler beim Untersuchen ... | |
| 221 | 229 | CodeToolBoss.SourceChangeCache.MainScanner:=Tool.Scanner; | |
| 222 | 230 | ||
| 223 | 231 | // Schritt 2: verzögere die Anwendung | |
| 224 | 232 | CodeToolBoss.SourceChangeCache.BeginUpdate; | |
| 225 | 233 | ||
| 226 | 234 | // Schritt 3: füge die Unit zum Interface-Bereich hinzu | |
| 227 | 235 | // AddUnitToMainUsesSection würde angewendet und den Code ändern | |
| 228 | 236 | // Wegen BeginUpdate finden die Änderungen noch nicht statt, werden aber in SourceChangeCache gespeichert | |
| 229 | 237 | if not Tool.AddUnitToMainUsesSection('Classes','',CodeToolBoss.SourceChangeCache) then exit; | |
| 230 | 238 | ||
| 231 | 239 | // Schritt 4: entferne die Unit aus dem Implementation-Bereich | |
| 232 | 240 | // Ohne BeginUpdate würde RemoveUnitFromUsesSection die Unit erneut scannen | |
| 233 | 241 | if Tool.FindImplementationUsesSection<>nil then | |
| 234 | 242 | if not Tool.RemoveUnitFromUsesSection(Tool.FindImplementationUsesSection,'Classes',CodeToolBoss.SourceChangeCache) then exit; | |
| 235 | 243 | ||
| 236 | 244 | // Schritt 5: wende alle Änderungen an | |
| 237 | 245 | if not CodeToolBoss.SourceChangeCache.EndUpdate then | |
| 238 | 246 | exit; // Anwendung wurde abgebrochen | |
| 239 | 247 | ``` | |
| 240 | 248 | ||
| 241 | 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. | |
| 242 | 250 | ||
| 243 | 251 | ## Speichern Sie die Änderungen auf Disk | |
| 244 | 252 | ||
| 245 | 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. | |
| 246 | 254 | ||
| 247 | 255 | - Die Puffer, die mit dem nächsten Apply/EndUpdate geändert werden liegen in 'SourceChangeCache.BuffersToModify' und 'BuffersToModifyCount'. | |
| 248 | 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. | |
| 249 | 257 | ||
| 250 | 258 | # Links | |
| 251 | 259 | ||
| 252 | 260 | - [[Lazarus IDE Tools/de|Lazarus IDE Tools (deutsch)]] - Ein Tutorial über die eingebauten Werkzeuge der Standard-IDE. | |
| 253 | 261 | - [[Cody]] - ein IDE-Package mit fortgeschrittenen CodeTools. | |
| 254 | 262 | - [[Extending the IDE/de|Erweitern der IDE (deutsch)]] - Wie Sie Ihre eigenen CodeTool-Plugins für die IDE schreiben. | |
| 255 | 263 | ||
| 256 | 264 | --- | |
| 257 | 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).* |