Lazarus For Delphi Users/de: what changed

Revision 2 to 3. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		Zurück zu den [[Additional information/de\|Zusätzlichen Informationen]].\
2	2
3	3		Diese Beschreibung ist für Leute gedacht, die an Lazarus interessiert sind und Delphi bereits kennen. Sie beschreibt die Unterschiede zwischen den beiden.
4	4
5	5		## Delphi -\> Lazarus
6	6
7	7		Lazarus ist ein Rapid Application Development (RAD) Tool wie Delphi. Das bedeutet, es enthält eine visuelle Komponentenbibliothek und eine IDE. Die Lazarus Component Library (LCL) ist sehr ähnlich zu Delphi's VCL. Die meisten Units, Klassen und Eigenschaften haben den selben Namen und die selbe Funktionalität. Dies macht eine Portierung (von Delphi zu Lazarus) einfach. Aber Lazarus ist kein 'Open Source Delphi Klon'. Erwarten Sie daher keine 100%ige Kompatibilität.
8	8
9	9		### Die größten Unterschiede
10	10
11	11		Lazarus ist komplett Open Source, ist plattformunabhängig geschrieben und benutzt den mächtigen [[Free Pascal/de\|Free Pascal]] Compiler (FPC). FPC läuft auf mehr als 15 Plattformen. Aber nicht alle Packages und Bibliotheken sind portiert, so dass Lazarus gegenwärtig unter Linux (i386, x86_64), FreeBSD (i386), Mac OS X (powerpc, i386) und Windows (i386, x86_64) läuft.
12	12
13	13		Lazarus ist nicht komplett, genau so wenig wie es dieser Text ist. Wir suchen ständig neue Entwickler, Package-Entwickler, Portierer, Dokumentations-Schreiber, ... .
14	14
15	15		### Die erste Aktion bei der Konvertierung eines Delphi-Projekts
16	16
17	17		Nachdem Lazarus gestartet ist, gehen Sie zu Werkzeuge und dann zu Delphi- in Lazarus-Project umwandeln. Das wird nicht alles für Sie erledigen, Sie aber ein gutes Stück weiter bringen. Beachten Sie, dass die Konvertierungstools der Lazarus-IDE generell nur Einweg-Konvertierungen durchführen. Falls Sie die Kompatibilität zu Delphi aufrecht halten müssen, sodass Sie Ihr Projekt sowohl mit Delphi als auch mit Lazarus kompilieren können, versuchen Sie stattdessen Ihre Dateien mit dem [XDev Toolkit](http://wiki.lazarus.freepascal.org/XDev_Toolkit) zu konvertieren.
18	18
19	19		### Unicode-Unterstützung
20	20
21	21		Die Versionen von Delphi bis zu Delphi 2007 hatten keine Unterstützung von Unicode, aber verwendeten die Windows-ANSI-Kodierung. Delphi unterstützt Unicode mit in UTF-16 kodierten Zeichenketten seit der Version 2009.
22	22
23	23		Lazarus startete im Gegensatz dazu seine Unicode-Unterstützung früher und verwendet in UTF-8 kodierte Zeichenketten. Für weitere Informationen siehe [[LCL Unicode Support]].
24	24
25	25		## Delphi IDE -\> Lazarus IDE
26	26
27	27		### Projekte
28	28
29	29		Die Hauptdatei einer Delphi Anwendung ist die .dpr Datei. Die Hauptdatei eines Lazarus Projekts ist die .lpi Datei (Lazarus Project Information). Eine .dpr Datei ist die Hauptquelle eines Programms und die Delphi IDE speichert hier einige Informationen über die Compiler-Schalter und Units. Eine Lazarus-Anwendung hat auch eine .lpr Datei, die auch die wichtigste Quelldatei ist. Aber alle anderen Informationen werden in der .lpi Datei gespeichert. Daher ist die .lpi Datei die wichtigste Datei.
30	30
31	31		Zum Beispiel:
32	32
33	33		Delphi speichert die Pfade der Units in der .dpr-Datei. Beispielsweise: unit1 in 'path/Unit1.pas'. Diese 'in'-Pfade sind Delphispezifisch und werden nicht von der Lazarus-IDE gelesen. Verwenden Sie sie nicht. Benutzen Sie stattdessen die Unitpfade der Compilereinstellungen.
34	34
35	35		Delphi speichert Compilereinstellungen in der .dpr-Datei. Beispielsweise {\$APPTYPE CONSOLE}. Diese werden von der Lazarus-IDE ignoriert. Verwenden Sie sie nicht. Benutzen Sie stattdessen die Compilereinstellungen.
36	36
37	37		Eine wichtige Regel: Es gibt immer ein Projekt. Der einzige Weg, um ein Projekt "zu beenden", ist, Lazarus zu beenden oder ein anderes Projekt zu öffnen. Das ist so, weil ein Lazarus Projekt auch eine "Sitzung" ist. Das bedeutet, dass die aktuellen Editoreinstellungen auch in der .lpi Datei gespeichert sind und wiederhergestellt werden, wenn sie das Projekt wieder öffnen. Zum Beispiel: Sie debuggen eine Anwendung, setzen eine Menge Haltepunkte (Breakpoints) und Lesezeichen (Bookmarks). Sie können das Projekt jederzeit speichern, Lazarus schließen oder ein anderes Projekt öffnen. Wenn Sie das Projekt wieder öffnen, sogar auf einem anderen Computer, werden alle Ihre Haltepunkte, Lesezeichen, geöffneten Dateien, Cursorpositionen, Sprunghistorie, ... wieder hergestellt.
38	38
39	39		### Quelltext-Editor
40	40
41	41		Nahezu alle Tasten und Tastenkürzel (short cuts) können unter 'Einstellungen -\> Editoreinstellungen -\> Tastaturbelegung' festgelegt werden.
42	42
43	43		Die Lazarus IDE besitzt eine Menge von Werkzeugen für Quelltexte. Viele von ihnen sehen aus und arbeiten sehr ähnlich wie Delphi. Aber es gibt einen wichtigen Unterschied: Lazarus benutzt nicht den Compiler, um Code-Informationen zu erhalten. Es analysiert die Quelltexte direkt. Dies hat eine Menge von bedeutenden Vorteilen:
44	44
45	45		Der Quelltext-Editor berücksichtigt Kommentare. Für Delphi sind die Kommentare in den Quellen einfach nur Leerzeichen im Code. Kein Code-Werkzeug funktioniert dort und wenn neuer Code automatisch eingefügt wird, dann wandern Ihre Kommentare. Unter Lazarus können Sie eine 'find declaration' sogar für Code in den Kommentaren erstellen. Obwohl dies nicht komplett zuverlässig ist, funktioniert es oftmals. Und wenn neuer Code eingefügt ist, dann benutzt die IDE einige heuristische Methoden, um Kommentare und Code zusammen zu halten. Zum Beispiel: Es wird die Zeile "c: char; // comment" nicht aufgeteilt.
46	46
47	47		Delphi's "Code Completion" (Strg+Space) wird "Bezeichner-Vervollständigung" genannt unter Lazarus. Der Lazarus Begriff "Codevervollständigung" ist ein Werkzeug, das automatische "Klassenvervollständigung" (das gleiche wie unter Delphi), "Local Variable Completion" und "Event Assignment Completion" kombiniert. Alle von ihnen werden mit Strg+Shift+C aufgerufen und die IDE ermittelt über die Cursorposition, was gemeint ist.
48	48
49	49		#### Beispiel für Local Variable Completion
50	50
51	51		Nehmen wir an, dass Sie gerade eine neue Methode erzeugt haben und die Anweisung lautet "i:=3;"
52	52
53	53		``` pascal
54	54		procedure TForm1.DoSomething;
55	55		begin
56	56		i := 3;
57	57		end;
58	58		```
59	59
60	60		Positionieren Sie den Cursor über dem Bezeichner "i" und drücken Sie `Strg`+`Shift`+`C` und Sie erhalten:
61	61
62	62		``` pascal
63	63		procedure TForm1.DoSomething;
64	64		var i: Integer;
65	65		begin
66	66		i := 3;
67	67		end;
68	68		```
69	69
70	70		#### Beispiel für Event Assignment Completion
71	71
72	72		Ein nettes Feature des Objektinspektors ist die automatische Erzeugung von Methoden. Das selbe können Sie im Quelltext-Editor erhalten.\
73	73		Zum Beispiel:
74	74
75	75		``` pascal
76	76		Button1.OnClick:=
77	77		```
78	78
79	79		Positionieren Sie den Cursor hinter dem Zuweisungsoperator ":=" und drücken Sie `Strg`+`Shift`+`C`.
80	80
81	81		#### Beispiel für Procedure Call Completion
82	82
83	83		Angenommen Sie haben gerade folgende Anweisung geschrieben: "DoSomething(Width);"
84	84
85	85		``` pascal
86	86		procedure SomeProcedure;
87	87		var
88	88		Width: integer;
89	89		begin
90	90		Width:=3;
91	91		DoSomething(Width);
92	92		end;
93	93		```
94	94
95	95		Positionieren Sie den Cursor über dem Bezeichner "DoSomething", drücken Sie `Strg`+`Shift`+`C` und Sie erhalten:
96	96
97	97		``` pascal
98	98		procedure DoSomething(aWidth: LongInt);
99	99		begin
100	100
101	101		end;
102	102
103	103		procedure SomeProcedure;
104	104		var
105	105		Width: integer;
106	106		begin
107	107		Width:=3;
108	108		DoSomething(Width);
109	109		end;
110	110		```
111	111
112	112		#### "Wortvervollständigung" Strg+W
113	113
114	114		Sie arbeitet ähnlich wie die "Bezeichner-Vervollständigung", aber sie funktioniert nicht nur mit Pascal-Bezeichnern, sondern mit allen Wörtern. Sie lässt Sie aus allen Wörter in allen geöffneten Dateien wählen, die mit dem selben Buchstaben beginnen.
115	115
116	116		#### Unterstützung von Include-Dateien
117	117
118	118		Delphi unterstützt diese nicht, und daher haben Sie wahrscheinlich noch nicht viele Include-Dateien erstellt. Aber Include-Dateien haben einen großen Vorteil: Sie machen es möglich, plattform-unabhängigen Code zu schreiben ohne Ihren Code durch IFDEFs unübersichtlich zu machen. Zum Beispiel: Method jumping, Class Completion, find declaration, .. arbeiten alle mit Include-Dateien.
119	119
120	120		Es gibt viele Optionen für die Code Features.
121	121
122	122		### Designer
123	123
124	124		\- Richtlinien
125	125
126	126		#### Objektinspektor
127	127
128	128		In den Delphi und Lazarus IDE's wird der Objektinspektor benutzt, um Komponenteneigenschaften zu editieren und Ereignisse zuzuweisen etc. Die folgenden Zeilen zeigen einige kleinere Unterschiede, auf die man achten muss:
129	129
130	130		1. Seit Delphi5 gibt es im Objektinspektor einen Objekt-Treeview, der zum Navigieren und Auswählen von Objekten unter Darstellung ihrer Hierarchie genutzt werden kann und so wahlweise die Dropdown-Liste des Objektinspektors ersetzt. In Lazarus ist dieser Treeview fester Bestandteil des Objektinspektors und er ersetzt die Dropdown-Liste völlig. Die Anzeige kann über das Kontextmenü "Komponentenbaum anzeigen" aktiviert bzw. deaktiviert werden.
131	131		2. In Delphi wird ein Doppelklick auf ein leeres Ereignis automatisch eines erzeugen und den Quelltext-Editor an dieser Position öffnen, in Lazarus gibt es alternativ dazu eine Schaltfläche auf der rechten Seite der ausgewählten Drop-down-Liste, die diese Aktion ebenfalls ausführt.
132	132		3. In Delphi müssen Sie den Namen eines Ereignisses in der Editierzeile manuell löschen, um Anhänge zu entfernen. In Lazarus können Sie mittels Drop-down "keine" auswählen.
133	133		4. Ähnlich wie bei Ereignissen, wird ein Doppelklick auf normale Eigenschaften wie 'boolean' nicht den Wert ändern. Sie müssen ihn aus einer Drop-down-Liste wählen. Und um solche mit einem zugeordneten Editorformular zu öffnen, müssen Sie auf den '...'-Button rechts vom Edit/Drop-down klicken.
134	134
135	135		#### Packages
136	136
137	137		F: Kann Lazarus Delphi-Packages installieren und verwenden?
138	138
139	139		A: Nein, weil diese auf die "Delphi Compiler Magie" angewiesen sind.
140	140
141	141		F: Brauchen wir speziell für Lazarus erstellte Packages?
142	142
143	143		A: Ja. Erzeugen Sie ein neues Package, speichern Sie es im Package-Quellen-Verzeichnis (normalerweise das selbe Verzeichnis wie das der .dpk Datei), fügen Sie die LCL als benötigtes Paket und schließlich die .pas Dateien selbst hinzu. Sie können es installieren oder es ab jetzt in ihren Projekten verwenden. Es gibt einige Unterschiede zwischen Lazarus- und Delphi-Packages, daher lesen Sie bitte
144	144
145	145		\- die docs/Packages.txt in den Lazarus Quellen.
146	146
147	147		### VCL -\> LCL
148	148
149	149		Obwohl die VCL und die LCL beide meist den selben Zwecken dienen - dem einer objekt-orientierten Komponenten-Hierarchie ausgerichtet auf Rapid Application Development - sind sie nicht identisch. Während zum Beispiel die VCL viele nicht-visuelle Komponenten enthält, versucht die LCL nur visuelle Komponenten zu liefern, während die meisten nicht-visuellen Komponenten (wie zum Beispiel db access) von der FCL zur Verfügung gestellt werden, die in [[Free Pascal/de\|Free Pascal]] enthalten ist.
150	150
151	151		Zusätzlich mögen viele Bedienelemente, die in der VCL enthalten sind, nicht in der LCL existieren, oder umgekehrt. Sogar wenn Bedienelemente in beiden existieren, sind VCL und LCL keine echten Klone. Und deshalb müssen Änderungen gemacht werden in Anwendungen, Komponenten und Bedienelementen, wenn sie portiert werden.
152	152
153	153		Das Folgende ist eine unvollständige Beschreibung der wichtigsten Unterschiede oder Inkompatibilitäten zwischen Delphi und Lazarus für Delphi-Benutzer. Es behandelt hauptsächlich die Unterschiede der VCL von D4, teilweise aber auch D5, D6, oder D7, mit der gegenwärtigen LCL, wie sie im SVN vorliegt. Insoweit können Unterschiede zu den von Ihnen verwendeten Versionen von Delphi und LCL bestehen. Sollten Ihnen Unterschiede oder Ungenauigkeiten zwischen dem Folgenden und der aktuellen LCL oder Ihrem Delphi auffallen, dann bitten wir Sie, den vorliegenden Text entsprechend zu modifizieren oder neue Abschnitte anzufügen. Wir möchten diese Beschreibung so umfassend und aktuell wie möglich für alle Lazarus-User zur Verfügung stellen.
154	154
155	155		#### TControl.Font/TControl.ParentFont
156	156
157	157		In der VCL ist es ziemlich einfach und normal, einen spezifischen Schriftart-Namen und Schriftart-Eigenschaften wie 'fett' und 'kursiv' für die Bedienelemente zu benutzen. In aller Regel werden diese Voreinstellungen auch entsprechend verwendet. Im laufenden Programm können sich diese Einstellungen von den Vorgaben von Windows unterscheiden. Ferner wird die TControl.ParentFont Eigenschaft mitgeliefert, die sicher stellt, dass ein Bedienelement immer der Schriftart seiner parent's folgt.
158	158
159	159		Dies trifft in der LCL nicht immer zu. Die LCL als cross-Plattform/cross-Interface hingegen, benutzt das Widget-Toolset, das aktuell auf dem benutztem Betriebssystem verwendet wird. Wenn ihr Desktop also gerade das GTK Interface benutzt, so wird LCL immer die Themes und spezifischen Schriftarten für Schaltflächen des GTK Widget-Toolset benutzen.
160	160
161	161		Das bedeutet, dass die meisten LCL Bedienelemente dem Desktop-Design des Zielrechners entsprechen werden. Das 'Look and feel' Ihrer Programmoberfläche kann sich also auf verschiedenen Zielrechnern auch entsprechend der Desktop-Einstellungen ändern.
162	162
163	163		#### Bedienelemente ziehen und andocken
164	164
165	165		In der VCL implementieren die meisten (Win-)Bedienelemente Methoden und Callback-Funktionen für die Handhabung des Ziehens (dragging) und Andockens von Bedienelementen, z.B. Ziehen eines Bedienelements von einem Panel und Andocken an einem anderen Panel zur Laufzeit.
166	166
167	167		Diese Funktionalität ist in der LCL derzeit noch nicht implementiert/beendet. Sie befindet sich gegenwärtig im Anfangsstadium der Planung und stellt schon einen Teil der Kompatibilität für diesen Verhalten bereit, wenn auch nicht in exakt der selben Art und Weise.
168	168
169	169		Das bedeutet derzeit, dass kein Bedienelement die folgenden TControl Funktionen, Prozeduren, Eigenschaften oder Ereignisse erben/benutzen wird -
170	170
171	171		``` pascal
172	172		Protected
173	173		function GetDockEdge(MousePos: TPoint): TAlign;
174	174		function GetDragImages: TDragImageList;
175	175		function GetFloating: Boolean;
176	176		function GetFloatingDockSiteClass: TWinControlClass;
177	177		procedure DoEndDrag(Target:TObject); X, Y: Integer);
178	178		procedure DockTrackNoTarget(Source: TDragDockObject; X, Y: Integer);
179	179		procedure DoEndDock(Target: TObject; X, Y: Integer);
180	180		procedure DoDock(NewDockSite: TWinControl; var ARect: TRect);
181	181		procedure DoStartDock(var DragObject: TDragObject);
182	182		procedure DragCanceled;
183	183		procedure DragOver(Source: TObject; X, Y: Integer; State: TDragState;
184	184		var Accept: Boolean);
185	185		procedure DoEndDrag(Target: TObject; X, Y: Integer);
186	186		procedure DoStartDrag(var DragObject: TDragObject);
187	187		procedure DrawDragDockImage(DragDockObject: TDragDockObject);
188	188		procedure EraseDragDockImage(DragDockObject: TDragDockObject);
189	189		procedure PositionDockRect(DragDockObject: TDragDockObject);
190	190		procedure SetDragMode(Value: TDragMode);
191	191		property DragKind: TDragKind;
192	192		property DragCursor: TCursor;
193	193		property DragMode: TDragMode;
194	194		property OnDragDrop: TDragDropEvent;
195	195		property OnDragOver: TDragOverEvent;
196	196		property OnEndDock: TEndDragEvent;
197	197		property OnEndDrag: TEndDragEvent;
198	198		property OnStartDock: TStartDockEvent;
199	199		property OnStartDrag: TStartDragEvent;
200	200		public
201	201		function Dragging: Boolean;
202	202		function ManualDock(NewDockSite: TWinControl; DropControl: TControl;
203	203		ControlSide: TAlign): Boolean;
204	204		function ManualFloat(ScreenPos: TRect): Boolean;
205	205		function ReplaceDockedControl(Control: TControl; NewDockSite: TWinControl;
206	206		DropControl: TControl; ControlSide: TAlign): Boolean;
207	207		procedure BeginDrag(Immediate: Boolean; Threshold: Integer);
208	208		procedure Dock(NewDockSite: TWinControl; ARect: TRect);
209	209		procedure DragDrop(Source: TObject; X, Y: Integer);
210	210		procedure EndDrag(Drop: Boolean);
211	211		property DockOrientation: TDockOrientation;
212	212		property Floating: Boolean;
213	213		property FloatingDockSiteClass: TWinControlClass;
214	214		property HostDockSite: TWinControl;
215	215		property LRDockWidth: Integer;
216	216		property TBDockHeight: Integer;
217	217		property UndockHeight: Integer;
218	218		property UndockWidth: Integer;
219	219		```
220	220
221	221		dass die folgenden Klassen nicht existieren/nicht verwendet werden können -
222	222
223	223		``` pascal
224	224		TDragImageList = class(TCustomImageList)
225	225		TDockZone = class
226	226		TDockTree = class(TInterfacedObject, IDockManager)
227	227		TDragObject = class(TObject)
228	228		TBaseDragControlObject = class(TDragObject)
229	229		TDragControlObject = class(TBaseDragControlObject)
230	230		TDragDockObject = class(TBaseDragControlObject)
231	231		```
232	232
233	233		und dass die folgenden Funktionen auch nicht benutzbar/inkompatibel sind -
234	234
235	235		``` pascal
236	236		function FindDragTarget(const Pos: TPoint;
237	237		AllowDisabled: Boolean) : TControl;
238	238		procedure CancelDrag;
239	239		function IsDragObject(sender: TObject): Boolean;
240	240		```
241	241
242	242		Der Start des Docking-Managers wird hier beschrieben: [[Anchor Docking]]
243	243
244	244		#### TEdit/TCustomEdit
245	245
246	246		Die Edit-Bedienelemente, die grundsätzlich gleich in der LCL wie in der VCL funktionieren, besitzen einige Besonderheiten, die bei einer Konvertierung beachtet werden sollten -
247	247
248	248		1. Wegen Restriktionen in den Interfaces, arbeitet TEdit.PasswordChar noch nicht mit allen Interfaces (obwohl es mit der Zeit möglich sein wird), anstelle von TCustomEdit.EchoMode sollte emPassword benutzt werden, falls der Text verborgen werden muss.
249	249		2. On Drag/Dock Ereignisse sind noch nicht implementiert. Für mehr Informationen schauen Sie bitte im vorherigen Abschnitt Bedienelemente ziehen und andocken nach.
250	250		3. Font-Eigenschaften werden üblicherweise für die Interface-Konsistenz ignoriert, für eine detaillierte Beschreibung schauen Sie bitte TControl.Font/TControl.ParentFont an.
251	251
252	252		#### TDBImage
253	253
254	254		Delphi und Lazarus haben beide ein TDBImage-Steuerelement, das Bilder anzeigt, die in einem Datenbankfeld gespeichert sind. Zusätzlich speichert Lazarus Informationen über den Bildtyp in dem Datenbankfeld vor den eigentlichen Bilddaten. Siehe die Prozedur TDBImage.UpdateData Dies bedeutet, dass die Implementationen von Delphi und Lazarus nicht kompatibel zueinander sind.
255	255
256	256		Anmerkung: Die aktuelle Entwicklerversion (r40924, April 2013) Lazarus trunk hat Änderungen implementiert, die ein Delphi-kompatibles Verhalten gestatten. Bitte sehen Sie [[Lazarus 1.2.0 release notes\|Lazarus_1.2.0_release_notes#TDBImage]] für Details.
257	257
258	258		### (optional) TSplitter -\> TPairSplitter
259	259
260	260		Bitte verbessern Sie mich
261	261
262	262		Es gibt jetzt ein [[TSplitter/de\|TSplitter]] Bedienelement in der LCL, so dass kein Bedarf zum Konvertieren besteht.
263	263
264	264		Nichtsdestoweniger, wenn Sie es doch wollen, hier ist es beschrieben:
265	265
266	266		Das Folgende basiert lose auf den Fragen von Vincent Snijders in der Mailingliste und Antworten von [Andrew Johnson](http://lazarus-ccr.sourceforge.net/index.php?wiki=AndrewJohnson):
267	267
268	268		Das in Delphi enthaltene "Splitting"-Control, das zwischen zwei Komponenten platziert werden kann, um dem einen oder anderen mehr Platz zu geben, wird in der VCL durch einen TSplitter realisiert. Dieses wird oft benutzt, beispielsweise in Delphi zwischen dem angedockten Codeexplorer und dem Quelltextfenster.
269	269
270	270		In der LCL gibt es dafür allerdings ein eigenes Control, den TPairSplitter, das den selben Zweck erfüllt, wie der TSplitter, allerdings zu diesem nicht kompatibel ist. Es sind also, wenn Sie Ihr Programm von einem TSplitter auf einen TPairsplitter ändern wollen, einige Anpassungen nötig.
271	271
272	272		Was sind nun genau die Unterschiede?
273	273
274	274		Der größte Unterschied ist, dass ein TSplitter keine "Kinder" besitzt. Stattdessen wird es zwischen zwei Controls positioniert, die mittels Align ausgerichtet werden. So erlaubt er während der Laufzeit die dynamische Größenanpassung dieser Controls. Um dies zu ermöglichen, muss links und rechts ein mittels Align ausgerichtetes Control vorhanden sein. (Beispielsweise ein links-ausgerichtetes Panel + ein links-ausgerichteter TSplitter + ein client-ausgerichtetes Panel).
275	275
276	276		In der LCL ist der TPairSplitter ein spezielles Control mit zwei Panels. Er kann nur nützlich werden, wenn die zu verändernden Controls auf beiden Panels liegen. Er vergrößert bzw. verkleinert also die beiden Panels, unabhängig davon, ob sie Komponenten enthalten oder nicht.
277	277
278	278		Der andere entscheidende Unterschied ist, dass der TSplitter der VCL seine Position relativ zu den anderen Komponenten verändert, abhängig von seiner Split-Position.
279	279
280	280		In der LCL dagegen besitzt der TPairSplitter durch die Panels eine absolute Position, wie andere Controls auch, die sich nach den Eigenschaften top und left richtet. So verändert sich die Position nicht automatisch, wenn die Split-Position verändert wird. Ist dies erwünscht, ist es nötig, einen entsprechenden Callback zu setzen und die entsprechenden Einstellungen zu setzen.
281	281
282	282		Beispielsweise befindet sich in einem verticalen TPairSplitter eine Komponente mit alClient. Soll diese automatisch bei Größenänderungen des Formulars im Verhältnis angepasst werden, ist es nötig, im OnResize-Ereignis des Formulars die neue Position zu setzen:
283	283
284		-	~~` PairSplitter.Position := PairSplitter.Width - PairSplitter.Position; `~~
	284	+	``` pascal
	285	+	PairSplitter.Position := PairSplitter.Width - PairSplitter.Position;
	286	+	```
285	287
286	288		Wie kann ich nun existierenden Code, der TSplitter verwendet, zu TPairSplitter konvertieren?
287	289
288	290		Wenn der Splitter und die Bedienelemente in einer effektiven Funktion (wie form oncreate) erzeugt wurden, sollte die Konvertierung nicht zu schwierig sein, hauptsächlich Reorganisieren des Codes, um die Bedienelemente in der Reihenfolge der neuen Hierarchie zu erzeugen und die Vorgänger der Nachfolgerbedienelemente zu setzen, um in die left/top und right/bottom Eigenschaften des PairSplitter aufzuteilen. Ein Beispiel für die Änderungen ist -
289	291
290	292		VCL
291	293
292	294		LCL
293	295
294	296		``` pascal
295	297		var
296	298		BottomPanel: TPanel;
297	299		VerticalSplitter: TSplitter;
298	300		LeftPanel: TPanel;
299	301		HorizontalSplitter: TSplitter;
300	302		MainPanel: TPanel;
301	303
302	304		begin
303	305		BottomPanel:= TPanel.Create(Self);
304	306		with (BottomPanel) do
305	307		begin
306	308		Parent:= Self;
307	309		Height:= 75;
308	310		Align:= alBottom;
309	311		end;
310	312
311	313		VerticalSplitter:= TSplitter.Create(Self);
312	314		with (VerticalSplitter) do
313	315		begin
314	316		Parent:= Self;
315	317		Align:= alBottom;
316	318		end;
317	319
318	320		HorizontalSplitter:= TSplitter.Create(Self);
319	321		with (HorizontalSplitter) do
320	322		begin
321	323		Parent:= Self;
322	324		align:= alLeft;
323	325		end;
324	326
325	327		LeftPanel:= TPanel.Create(Self);
326	328		with (LeftPanel) do
327	329		begin
328	330		Parent:= Self;
329	331		Width:= 125;
330	332		Align:= alLeft;
331	333		end;
332	334
333	335		MainPanel:= TPanel.Create(Self);
334	336		with (MainPanel) do
335	337		begin
336	338		Parent:= Self;
337	339		Align:= alClient;
338	340		Caption:= 'Hello';
339	341		end;
340	342		end;
341	343		```
342	344
343	345		``` pascal
344	346		var
345	347		BottomPanel: TPanel;
346	348		VerticalSplitter: TPairSplitter;
347	349		LeftPanel: TPanel;
348	350		HorizontalSplitter: TPairSplitter;
349	351		MainPanel: TPanel;
350	352
351	353		begin
352	354		VerticalSplitter:= TPairSplitter.Create(Self);
353	355		with (VerticalSplitter) do
354	356		begin
355	357		Parent:= Self;
356	358		Align:= alClient;
357	359		Width:= Self.Width;
358	360		Height:= Self.Height;
359	361		SplitterType:= pstVertical;
360	362		Position:= Height - 75;
361	363		Sides[0].Width:= Width;
362	364		Sides[0].Height:= Position;
363	365		end;
364	366
365	367		HorizontalSplitter:= TPairSplitter.Create(Self);
366	368		with (HorizontalSplitter) do
367	369		begin
368	370		Parent:= VerticalSplitter.Sides[0];
369	371		Width:= Self.Width;
370	372		Height:= VerticalSplitter.Position;
371	373		align:= alClient;
372	374		SplitterType:= pstHorizontal;
373	375		Position:= 125;
374	376		end;
375	377
376	378		LeftPanel:= TPanel.Create(Self);
377	379		with (LeftPanel) do
378	380		begin
379	381		Parent:= HorizontalSplitter.Sides[0];
380	382		Align:= alClient;
381	383		end;
382	384
383	385		MainPanel:= TPanel.Create(Self);
384	386		with (MainPanel) do
385	387		begin
386	388		Parent:= HorizontalSplitter.Sides[1];
387	389		Align:= alClient;
388	390		Caption:= 'Hello';
389	391		end;
390	392
391	393		BottomPanel:= TPanel.Create(Self);
392	394		with (BottomPanel) do
393	395		begin
394	396		Parent:= VerticalSplitter.Sides[1];
395	397		Align:= alClient;
396	398		end;
397	399		end;
398	400		```
399	401
400	402		Wie man sieht, ist es ziemlich konsistent mit den meisten Kontrollhierarchien. Wenn Sie mit DFM vertraut sind, sollten die notwendigen Änderungen für eine DFM -\> LFM Konversion offensichtlich sein, da sie die selbe Art von Änderungen in Parent/Owner darstellen.
401	403
402	404		Das obige Beispiel würde in etwa so aussehen -
403	405
404	406		Delphi DFM
405	407
406	408		(weitere Werte wurden entfernt)
407	409
408	410		Lazarus LFM
409	411
410	412		(width, height, etc. entfernt)
411	413
412		-	~~``` pascal~~
	414	+	``` lfm
413	415		object VerticalSplitter: TSplitter
414	416		Height = 3
415	417		Cursor = crVSplit
416	418		Align = alBottom
417	419		end
418	420		object HorizontalSplitter: TSplitter
419	421		Width = 3
420	422		Align = alLeft
421	423		end
422	424		object BottomPanel: TPanel
423	425		Height = 75
424	426		Align = alBottom
425	427		end
426	428		object LeftPanel: TPanel
427	429		Width = 125
428	430		Align = alLeft
429	431		end
430	432		object MainPanel: TPanel
431	433		Align = alClient
432	434		end
433	435		```
434	436
435		-	~~``` pascal~~
	437	+	``` lfm
436	438		object VerticalSplitter: TPairSplitter
437	439		Align = alClient
438	440		SplitterType = pstVertical
439	441		Position = 225
440	442		Height = 300
441	443		Width = 400
442	444		object Pairsplitterside1: TPairSplitterIde
443	445		object HorizontalSplitter: TPairSplitter
444	446		Align = alClient
445	447		Position = 125
446	448		object Pairsplitterside3: TPairSplitterIde
447	449		Width = 125
448	450		object LeftPanel: TPanel
449	451		Align = alClient
450	452		Width = 125
451	453		end
452	454		end
453	455		object Pairsplitterside4: TPairSplitterIde
454	456		object MainPanel: TPanel
455	457		Align = alClient
456	458		end
457	459		end
458	460		end
459	461		end
460	462		object Pairsplitterside2: TPairSplitterIde
461	463		object BottomPanel: TPanel
462	464		Align = alClient
463	465		Height = 75
464	466		end
465	467		end
466	468		end
467	469		```
468	470
469	471		### TCustomTreeView/TTreeView
470	472
471	473		Beide, VCL und die LCL, bieten eine TCustomTreeView/TTreeView Komponente, die für in Bäumen strukturierte Datenlisten mit mehrfachen Knoten und erweiterter Auswahl sowie für Bilderlisten benutzt wird. Und obwohl einige Features vergleichbar sind, sind nicht alle Eigenschaften völlig kompatibel. Hauptsächliche Unterschiede sind folgende -
472	474
473	475		Unvollständige Liste (sollte aktualisiert werden, um die TCustomTreeView-Markierungsfunktionen und geschützten Methoden zu enthalten)
474	476
475	477		1. Die LCL bietet TCustomTreeView.Options, eine Reihe von Optionen, die im Bedienelement eingestellt werden können, um sein Verhalten und Erscheinungbild ändern. Diese Optionen sind :
476	478		- tvoAllowMultiselect - enables multi node select mode, equivalent to enabling TCustomTreeView.MultiSelect in the D6 VCL
477	479		- tvoAutoExpand - Auto Expand nodes, equivalent to enabling TCustomTreeView.AutoExpand
478	480		- tvoAutoInsertMark - Update the Drag preview on mouse move.
479	481		- tvoAutoItemHeight - Passt die Item Höhen automatisch an.
480	482		- tvoHideSelection - Markiert das gewählte Item nicht.
481	483		- tvoHotTrack - use Hot Tracking, equivalent to enabling TCustomTreeview.HotTrack
482	484		- tvoKeepCollapsedNodes - When shrinking/folding nodes, keep the child nodes
483	485		- tvoReadOnly - make Treeview read only, equivalent to enabling TCustomTreeview.ReadOnly
484	486		- tvoRightClickSelect - allow using Mouse Right Clicks to select nodes, equivalent to enabling TCustomTreeView.RightClickSelect
485	487		- tvoRowSelect - Erlaubt das Auswählen von Zeilen, entsprechend der Ermöglichung von TCustomTreeView.RowSelect
486	488		- tvoShowButtons - Zeigt Schaltflächen, entsprechend der Ermöglichung von TCustomTreeView.ShowButtons
487	489		- tvoShowLines - show node lines, equivalent to enabling TCustomTreeView.ShowLines
488	490		- tvoShowRoot - show root note, equivalent to enabling TCustomTreeView.ShowRoot
489	491		- tvoShowSeparators - zeigt Begrenzungszeichen
490	492		- tvoToolTips - show tooltips for individual nodes
491	493		2. Die LCL bietet zusätzliche Eigenschaften:
492	494		- TCustomTreeView.OnSelectionChange Ereignis
493	495		- TCustomTreeView.DefaultItems, für die Standardanzahl von Items
494	496		- TCustomTreeView.ExpandSignType to determine sign used on expandable/collapsible nodes
495	497		3. Obwohl die meisten On Drag/Dock Ereignisse in der LCL verfügbar sind, funktionieren sie nicht. Für mehr Informationen lesen Ssie bitte den früheren Abschnitt über 'Bedienelemente ziehen und andocken'.
496	498
497	499		### Nachrichten / Ereignisse
498	500
499	501		Die Reihenfolge und Häufigkeit von Nachrichten (Messages) und Ereignissen (Events) (OnShow, OnActivate, OnEnter, ...) unterscheiden sich von der VCL und hängen vom [[Widgetset]] ab. Die LCL stellt eine Untermenge von WinAPI-ähnlichen Nachrichten zur Verfügung, um das Portieren von Delphi-Komponenten zu erleichtern, aber fast alle LCL-Nachrichten arbeiten etwas anders als die VCL/WinAPI Gegenstücke. Der größte Teil des Delphi Codes, der WinAPI-Nachrichten benutzt, benutzt sie auch deshalb, weil der VCL ein Feature fehlt oder die VCL zu langsam ist. Solcher Code funktioniert unter der LCL selten genau so und muss sorgfältig und von Hand überprüft werden. Deshalb heißen LCL Nachrichten zum Beispiel LM_SIZE (aus der Unit lmessages) und nicht WM_SIZE.
500	502
501	503		Anmerkung über den Umgang mit benutzerdefinierten Nachrichten! Seit der Version 0.9.26 (Dezember 2008), unterscheidet sich der Umgang mit benutzerdefinierten WinAPI-Nachrichten (z.B. WM_HOTKEY, WM_SYSCOMMAND) von der Art, wie Delphi diese Nachrichten behandelt. Derzeit können Sie diese nicht mittels der Direktive message oder durch Überschreiben der WndProc-Methode des Formulars ansprechen. Der einzige Weg dazu besteht darin, im Formular selbst einen Hook auf Windows windowproc anzulegen. Lesen Sie hier weiter: [[Win32/64 Interface\|Processing non-user messages in your window]]
502	504
503	505		## Siehe auch
504	506
505	507		- [[Code Conversion Guide\|Code Conversion Guide (from Delphi & Kylix)]]
506	508		- [[Compile With Delphi]]
507	509
508	510		---
509	511		From the Free Pascal wiki, page "Lazarus For Delphi Users/de", as it stood on 2020-02-18 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