Lazarus For Delphi Users: what changed

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

Old	New		Line
1	1		This writeup is for people who are interested in Lazarus and already know Delphi. It describes the differences between the two.
2	2
3	3		## Delphi -\> Lazarus
4	4
5	5		Lazarus is a Rapid Application Development (RAD) tool like Delphi. That means it comes with a visual component library and an Integrated Development Environment (IDE). The Lazarus component library (LCL) is very similar to Delphi's Visual Component Library (VCL). Most Lazarus units, classes and properties have the same name and functionality as their equivalents in Delphi. This makes porting Delphi applications to Lazarus relatively easy. Even though Lazarus is in many respects an open source Delphi clone, the compatibility is not 100%.
6	6
7	7		### The biggest differences between Lazarus and Delphi
8	8
9	9		- Lazarus is completely open source
10	10		- Lazarus is written in a platform-independent way
11	11		- Lazarus uses the [[Free Pascal]] compiler (FPC)
12	12
13	13		FPC runs on more than 15 platforms (see [[Platform list]]. But not all FPC packages and libraries have been ported to all 15 platforms, so Lazarus currently runs on:
14	14
15	15		- Linux (i386, x86_64)
16	16		- FreeBSD (i386, x86_64)
17	17		- macOS (PowerPC, i386, x86_64, ARM64)
18	18		- Windows (i386, x86_64)
19	19
20	20		> Note: Lazarus is not complete and nor, for that matter, is this text. We are always searching for new developers, packagers, porters, documentation writers...
21	21
22	22		### The first thing to do when converting a Delphi project to Lazarus
23	23
24	24		Having opened Lazarus, you should go to to Tools and then Convert Delphi Project to Lazarus Project (Since Lazarus 1.2.6 the menu structure is Tools -\> Delphi Conversion -\> Convert Delphi Project to Lazarus Project). This won't do everything for you, but nonetheless will take you a good deal of the way. Note that the Lazarus IDE's conversion tools are generally one-way conversions. If you need to retain Delphi compatibility (so you can compile your project with both Delphi and Lazarus) consider converting your files with the [XDev Toolkit](http://wiki.lazarus.freepascal.org/XDev_Toolkit) instead.
25	25
26	26		### Unicode support
27	27
28	28		Versions of Delphi up to Delphi 2007 didn't support Unicode, but used Windows ANSI encoding. Delphi supports Unicode by using UTF-16 encoded strings from the 2009 version.
29	29
30	30		Lazarus on the other hand started its Unicode support earlier and uses UTF-8 encoded strings. For more information see [[LCL Unicode Support]].
31	31
32	32		## Delphi IDE -\> Lazarus IDE
33	33
34	34		### Projects
35	35
36	36		The main file for a Delphi application is its .dpr file. A Delphi .dpr file is both the program main source, and also the file where the Delphi IDE stores information about relevant compiler switches and unit locations.\
37	37		A Lazarus application has a corresponding .lpr file, which is also the principal Pascal source file for the project. However, the main file of a Lazarus project is the .lpi file (Lazarus Project Information), which is created separately together with the .lpr file. All project-specific information (such as compiler switches used, paths to units used etc.) is stored in the .lpi file. So, the important file is the .lpi file. On most platforms, double-clicking on an .lpi file in the system's file explorer will start the Lazarus IDE with that project open.
38	38
39	39		For example:
40	40
41	41		Delphi stores the paths of the project's units in the .dpr file. For instance:
42	42
43		-	~~` unit1 in 'path/Unit1.pas';`~~
	43	+	```text
	44	+	unit1 in 'path/Unit1.pas';
	45	+	```
44	46
45	47		These 'in' paths are Delphi-specific and are not read by the Lazarus IDE. Don't use them. Instead, in the Project Options dialog (Project-\>Project Options...) use the Paths page under Compiler Options to set unit paths where they differ from the project directory path. Note that most unit paths you will need are set automatically by the IDE when any package dependency is added. For instance, all standard Lazarus LCL projects have the LCL added as a dependency by default, and so any new Lazarus LCL project (Project-\>New Project-\>Application) knows all paths to all LCL compiled units without further work on your part.
46	48
47	49		Delphi stores compiler options in the .dpr file. For instance {\$APPTYPE CONSOLE}. These are ignored by the Lazarus IDE. Don't use them. Use the Compiler Options page of the Project Options dialog instead.
48	50
49	51		### No "empty" IDE with Lazarus
50	52
51	53		One important rule: There is always a project. The only way to "close" a project is to exit Lazarus, or open another project. This is because a Lazarus project is also a "session". So session information (e. g. the current editor settings) is also stored in the .lpi file and the Lazarus editor is restored to its last saved state when the project is later reopened. For example: You are debugging an application, and set a lot of breakpoints and bookmarks. You can save the project at any time, close Lazarus or open another project. When you reopen the project (even on another computer) all your breakpoints, bookmarks, open files, cursor positions, jump histories, etc. are restored.
52	54
53	55		### Source Editor
54	56
55	57		Nearly all keys and short cuts can be defined in Tools -\> Options -\> Editor -\> Key Mappings
56	58
57	59		The Lazarus IDE has a lot of tools for sources. Many of them look and work very similar to Delphi. But there is one important difference: Lazarus does not use the compiler to get code information. It parses the sources directly. This has a lot of important advantages:
58	60
59	61		The source editor works with "comments". For Delphi the comments in the source are just space between code. No code feature works there and when new code is auto inserted, your comments will travel. Under Lazarus you can do a find declaration even on code in comments. Although this is not completely reliable, it often works. And when new code is inserted, the IDE uses some heuristics to keep comment and code together. For example: It will not split the line "c: char; // comment".
60	62
61	63		Delphi's "Code Completion" (Ctrl+Space) is called "Identifier Completion" under Lazarus. The Lazarus term "Code Completion" is a feature, combining "Automatic Class Completion" (same as under Delphi), "Local Variable Completion" and "Event Assignment Completion". All of them are invoked by Ctrl+Shift+C and the IDE determines by the cursor position, what is meant.
62	64
63	65		#### Example for Local Variable Completion
64	66
65	67		Assume you just created a new method and wrote the statement "i:=3;"
66	68
67	69		``` pascal
68	70		procedure TForm1.DoSomething;
69	71		begin
70	72		i := 3;
71	73		end;
72	74		```
73	75
74	76		Position the cursor over the identifier "i" and press `Ctrl`+`Shift`+`C` to get:
75	77
76	78		``` pascal
77	79		procedure TForm1.DoSomething;
78	80		var i: Integer;
79	81		begin
80	82		i := 3;
81	83		end;
82	84		```
83	85
84	86		#### Example for Event Assignment Completion
85	87
86	88		A nice feature of the object inspector is to auto create methods. You can get the source editor to create the events too.\
87	89		For example:
88	90
89	91		``` pascal
90	92		Button1.OnClick:=
91	93		```
92	94
93	95		Position the cursor behind the assign operator ":=" and press `Ctrl`+`Shift`+`C` to get:
94	96
95	97		``` pascal
96	98		procedure TForm1.FormCreate(Sender: TObject);
97	99		begin
98	100		Button1.OnClick:=@Button1Click;
99	101		end;
100	102
101	103		procedure TForm1.Button1Click(Sender: TObject);
102	104		begin
103	105
104	106		end;
105	107		```
106	108
107	109		#### Example for Procedure Call Completion
108	110
109	111		Assume you just wrote the statement "DoSomething(Width);"
110	112
111	113		``` pascal
112	114		procedure SomeProcedure;
113	115		var
114	116		Width: integer;
115	117		begin
116	118		Width:=3;
117	119		DoSomething(Width);
118	120		end;
119	121		```
120	122
121	123		Position the cursor over the identifier "DoSomething" and press `Ctrl`+`Shift`+`C` to get:
122	124
123	125		``` pascal
124	126		procedure DoSomething(aWidth: LongInt);
125	127		begin
126	128
127	129		end;
128	130
129	131		procedure SomeProcedure;
130	132		var
131	133		Width: integer;
132	134		begin
133	135		Width:=3;
134	136		DoSomething(Width);
135	137		end;
136	138		```
137	139
138	140		#### "Word Completion" Ctrl+W
139	141
140	142		It works similar to the "Identifier Completion", but it does not work on pascal identifiers, but on all words. It lets you choose of all words in all open files beginning with the same letters.
141	143
142	144		#### Supports Include files
143	145
144	146		Delphi didn't support them, and so you probably haven't created many include files yet. But include files have a big advantage: They make it possible writing platform (in)dependent code without messing your code with IFDEFs. For example: Method jumping, Class Completion, find declaration, .. all work with include files.
145	147
146	148		There are many options for the code features.
147	149
148	150		### Designer
149	151
150	152		\- Guidelines
151	153
152	154		#### Object Inspector
153	155
154	156		In the Delphi and Lazarus IDE's the Object Inspector is used to edit component properties and assign events etc. The following are a few minor differences to note in use :
155	157
156	158		1. Starting in Delphi 5 there is an Object Treeview which can be used to navigate and select objects according to hierarchy in addition to the traditional drop down list in the Object Inspector. In Lazarus this is part of the Object Inspector and is used in place of the default drop-down, you can select to use/not use it from the right click menu with "Show Component Tree"
157	159		2. In Delphi double clicking on a blank event will auto create one and open the Source Editor to that position, in Lazarus there is a button to the right of the selected drop-down which performs this action instead.
158	160		3. In Delphi you must manually delete the name of an event in the edit to remove the attatchement, in Lazarus you can drop down and select "(None)".
159	161		4. Similarly to Events, double clicking regular properties such as boolean will not change the value, you must select it from a drop down. And to open those with an assigned editor form, you must click the '...' button to the right of the edit/drop-down
160	162
161	163		#### Packages
162	164
163	165		Can Lazarus install and use Delphi Packages?
164	166
165	167
166	168		No, because they require Delphi compiler magic.
167	169
168	170		Do we need ones specially made for lazarus?
169	171
170	172
171	173		Yes.
172	174
173	175		Create a new package, save it in the package source directory (normally same directory of the .dpk file), add the LCL as required package and finally add the .pas files. You can install it, or use it in your projects now. There are some [[packages\|differences between Lazarus and Delphi packages]]
174	176
175	177		## VCL -\> LCL
176	178
177	179		While the VCL and the LCL both serve much of the same purpose - of an Object Oriented Component Hierarchy especially geared toward rapid application development, they are not identical. For instance while the VCL provides many non-visual components, the LCL tries to only provide visual, while most non-visual components (such as db access) are provided by the FCL, included with [[Free Pascal]] .
178	180
179	181		Additionally many controls may not exist in the LCL that are in the VCL, or vice versa, or even when controls do exist in both, they are not clones, and changes must be made in applications, components and controls if porting.
180	182
181	183		The following is an attempt to provide fairly complete descriptions of major differences or incompatiblities between the two for the Delphi user. It covers differences primarily with the VCL of D4 especially, though at times D5, D6, or D7 as well; and with the current LCL, as is in CVS. As such it may not always be accurate to the version of Delphi you are used to, or completely match the current LCL you have. If you see inacuracies between the following and the LCL as in CVS, or your Delphi feel free to append and modify so as to keep this as comprehensive as possible for all people.
182	184
183	185		### TControl.Font/TControl.ParentFont
184	186
185	187		In the VCL it is quite common and normal to use a specific font name and font properties such as bold and italics for controls, and expect this value to always be followed. Further is provided the TControl.ParentFont property which ensures that a control will always follow its parent's font. Again the implicit assumption being that these values will always be followed, even regardless of Windows Apearance Settings.
186	188
187	189		This is not always true in the LCL, nor can it be. The LCL being cross-platform/cross-interface in nature prefers to take a balanced aproach, and instead will always try to use native Desktop/Toolkit Apearance or Theme settings on any widgets. For example if using a GTK interface, and the gtk theme supplies a specific font for buttons, then LCL buttons will always try to use this font.
188	190
189	191		This means that most LCL controls do not have the same level of design control that is often expected in the VCL, rather only those custom controls which are Canvas drawn instead of interface allocated can consistantly be modified in this manner regardless of the Interface used.
190	192
191	193		### Control Dragging/Docking
192	194
193	195		In the VCL most (Win)Controls implement methods and [[callback]] functions for handling dragging and docking of controls, eg. dragging a control from one panel, and docking it onto another panel at run time.
194	196
195	197		This functionality is currently unimplemented/unfinished in the LCL, though it is currently in the initial stages of planning, and should eventually support some level of compatibility for this type of behavior, if not in the exact same manner.
196	198
197	199		This currently means that no Control will inherit/use the following TControl functions, procedures, properties, or events -
198	200
199	201		``` pascal
200	202		Protected
201	203		function GetDockEdge(MousePos: TPoint): TAlign;
202	204		function GetDragImages: TDragImageList;
203	205		function GetFloating: Boolean;
204	206		function GetFloatingDockSiteClass: TWinControlClass;
205	207		procedure DoEndDrag(Target:TObject); X, Y: Integer);
206	208		procedure DockTrackNoTarget(Source: TDragDockObject; X, Y: Integer);
207	209		procedure DoEndDock(Target: TObject; X, Y: Integer);
208	210		procedure DoDock(NewDockSite: TWinControl; var ARect: TRect);
209	211		procedure DoStartDock(var DragObject: TDragObject);
210	212		procedure DragCanceled;
211	213		procedure DragOver(Source: TObject; X, Y: Integer; State: TDragState;
212	214		var Accept: Boolean);
213	215		procedure DoEndDrag(Target: TObject; X, Y: Integer);
214	216		procedure DoStartDrag(var DragObject: TDragObject);
215	217		procedure DrawDragDockImage(DragDockObject: TDragDockObject);
216	218		procedure EraseDragDockImage(DragDockObject: TDragDockObject);
217	219		procedure PositionDockRect(DragDockObject: TDragDockObject);
218	220		procedure SetDragMode(Value: TDragMode);
219	221		property DragKind: TDragKind;
220	222		property DragCursor: TCursor;
221	223		property DragMode: TDragMode;
222	224		property OnDragDrop: TDragDropEvent;
223	225		property OnDragOver: TDragOverEvent;
224	226		property OnEndDock: TEndDragEvent;
225	227		property OnEndDrag: TEndDragEvent;
226	228		property OnStartDock: TStartDockEvent;
227	229		property OnStartDrag: TStartDragEvent;
228	230		public
229	231		function Dragging: Boolean;
230	232		function ManualDock(NewDockSite: TWinControl; DropControl: TControl;
231	233		ControlSide: TAlign): Boolean;
232	234		function ManualFloat(ScreenPos: TRect): Boolean;
233	235		function ReplaceDockedControl(Control: TControl; NewDockSite: TWinControl;
234	236		DropControl: TControl; ControlSide: TAlign): Boolean;
235	237		procedure BeginDrag(Immediate: Boolean; Threshold: Integer);
236	238		procedure Dock(NewDockSite: TWinControl; ARect: TRect);
237	239		procedure DragDrop(Source: TObject; X, Y: Integer);
238	240		procedure EndDrag(Drop: Boolean);
239	241		property DockOrientation: TDockOrientation;
240	242		property Floating: Boolean;
241	243		property FloatingDockSiteClass: TWinControlClass;
242	244		property HostDockSite: TWinControl;
243	245		property LRDockWidth: Integer;
244	246		property TBDockHeight: Integer;
245	247		property UndockHeight: Integer;
246	248		property UndockWidth: Integer;
247	249		```
248	250
249	251		that the following classes do not exist/are unusable -
250	252
251	253		``` pascal
252	254		TDragImageList = class(TCustomImageList)
253	255		TDockZone = class
254	256		TDockTree = class(TInterfacedObject, IDockManager)
255	257		TDragObject = class(TObject)
256	258		TBaseDragControlObject = class(TDragObject)
257	259		TDragControlObject = class(TBaseDragControlObject)
258	260		TDragDockObject = class(TBaseDragControlObject)
259	261		```
260	262
261	263		and that the following functions are also unusable/incompatible -
262	264
263	265		``` pascal
264	266		function FindDragTarget(const Pos: TPoint;
265	267		AllowDisabled: Boolean) : TControl;
266	268		procedure CancelDrag;
267	269		function IsDragObject(sender: TObject): Boolean;
268	270		```
269	271
270	272		The start of docking manager is described here: [[Anchor Docking]]
271	273
272	274		### TEdit/TCustomEdit
273	275
274	276		The Edit controls, while functioning essentialy the same in the LCL as the VCL, do have some issues to be aware of in converting -
275	277
276	278		1. Due to restrictions in the Interfaces, TEdit.PasswordChar does not work in all interfaces yet(though in time it may), instead TCustomEdit.EchoMode emPassword should be used in the event text needs to be hidden.
277	279		2. On Drag/Dock Events are not yet implemented. For more information please see earlier section on Control Dragging/Docking.
278	280		3. Font Properties are usually ignored for interface consistancy, for detailed explanation as too why please see TControl.Font/TControl.ParentFont
279	281
280	282		### TDBImage
281	283
282	284		Delphi and Lazarus both have a [[TDBImage]] control that shows images stored in a database field. In current stable versions (1.2.4), Lazarus stores information about the image type in the database field before the actual image data. See procedure TDBImage.UpdateData This means that Delphi and older Lazarus implementations are not compatible.
283	285
284	286		Current stable Lazarus (1.2.0+) has implemented changes that allow Delphi compatible behaviour. Please see [[Lazarus 1.2.0 release notes\|Lazarus_1.2.0_release_notes#TDBImage]] for details on how to activate this.
285	287
286	288		Current Lazarus trunk falls back to Delphi-compatible behaviour on reading Delphi-formatted database fields into TDBImage.
287	289
288	290		### (optional) TSplitter -\> TPairSplitter
289	291
290	292		Please Improve Me
291	293
292	294		There is now a [[TSplitter]] control in the LCL, so no need to convert it.
293	295
294	296		Nevertheless, if you want, here it is explained:
295	297
296	298		The following is loosely based on questions by Vincent Snijders on the mailing list, and responses by [Andrew Johnson](http://lazarus-ccr.sourceforge.net/index.php?wiki=AndrewJohnson):
297	299
298	300		In the VCL, "Splitting" controls, that is a handle which can be dragged between two components to give one more or less space then the other, is accomplished by a TSplitter. This is often seen, for instance in the Delphi IDE between the docked Code Explorer and Source Viewer.
299	301
300	302		The LCL provides its own Control called a TPairSplitter, which serves the same type of purpose, however it is not compatible, so "repairing" broken VCL code or Delphi DFM's will be necessary in the event of porting code, even though much is shared in common between the two.
301	303
302	304		So what exactly are the differences?
303	305
304	306		Well the biggest differences are a VCL TSplitter has no children, instead it is placed between two controls aligned properly, and allows resizing between them at runtime, regardless its own size. It must have two controls aligned on each side to do anything. A simple example would be form with a Left Aligned Panel, a left aligned Splitter, and a second client aligned panel. On run time you could then realign the size given each panel by dragging on the handle provided by this Splitter control.
305	307
306	308		On the LCL hand however, a TPairSplitter is a special kind of control, with two panels, and it can only be usefull if the controls to split are on these panels, but it will still perform a split between those panel whether or not anything is on them. So following the prior example, you would have a form with a TPairSplitter aligned client, and a panel aligned client on its left side, and a panel aligned client on its right side.
307	309
308	310		The other important difference is that in the VCl, since the TSplitter is its own TControl, then the position is kept relative to the other controls on resize, so for instance a client panel will grow while the other panels will not, thus the split position is relative to the alignment of the split controls,
309	311
310	312		In the LCL since the side panels are separate then the TPairSplitter has a Position property which is absolute relative to top or left. so on resize the actual position does not change according to contents, so a callback must be set to ensure the ratio is kept on resize if this is important.
311	313
312	314		For example if the Right side of a vertical split needs to have alClient like behaviour, you need to add a form resize callback which does something like :
313	315
314		-	~~`PairSplitter.Position := PairSplitter.Width - PairSplitter.Position; `~~
	316	+	``` pascal
	317	+	PairSplitter.Position := PairSplitter.Width - PairSplitter.Position;
	318	+	```
315	319
316	320		So how can I convert existing code using TSplitter to the TPairSplitter?
317	321
318	322		If the splitter and controls are created within an actual function(like form oncreate), conversion shouldn't be too difficult, primarily reorganize the code to create the controls in order of new hierarchy and set the parents of the child controls to split to the left/top and right/bottom portions of the PairSplitter. An example of the changes being -
319	323
320	324		VCL
321	325
322	326		LCL
323	327
324	328		``` pascal
325	329		var
326	330		BottomPanel: TPanel;
327	331		VerticalSplitter: TSplitter;
328	332		LeftPanel: TPanel;
329	333		HorizontalSplitter: TSplitter;
330	334		MainPanel: TPanel;
331	335
332	336		begin
333	337		BottomPanel:= TPanel.Create(Self);
334	338		with (BottomPanel) do
335	339		begin
336	340		Parent:= Self;
337	341		Height:= 75;
338	342		Align:= alBottom;
339	343		end;
340	344
341	345		VerticalSplitter:= TSplitter.Create(Self);
342	346		with (VerticalSplitter) do
343	347		begin
344	348		Parent:= Self;
345	349		Align:= alBottom;
346	350		end;
347	351
348	352		HorizontalSplitter:= TSplitter.Create(Self);
349	353		with (HorizontalSplitter) do
350	354		begin
351	355		Parent:= Self;
352	356		align:= alLeft;
353	357		end;
354	358
355	359		LeftPanel:= TPanel.Create(Self);
356	360		with (LeftPanel) do
357	361		begin
358	362		Parent:= Self;
359	363		Width:= 125;
360	364		Align:= alLeft;
361	365		end;
362	366
363	367		MainPanel:= TPanel.Create(Self);
364	368		with (MainPanel) do
365	369		begin
366	370		Parent:= Self;
367	371		Align:= alClient;
368	372		Caption:= 'Hello';
369	373		end;
370	374		end;
371	375		```
372	376
373	377		``` pascal
374	378		var
375	379		BottomPanel: TPanel;
376	380		VerticalSplitter: TPairSplitter;
377	381		LeftPanel: TPanel;
378	382		HorizontalSplitter: TPairSplitter;
379	383		MainPanel: TPanel;
380	384
381	385		begin
382	386		VerticalSplitter:= TPairSplitter.Create(Self);
383	387		with (VerticalSplitter) do
384	388		begin
385	389		Parent:= Self;
386	390		Align:= alClient;
387	391		Width:= Self.Width;
388	392		Height:= Self.Height;
389	393		SplitterType:= pstVertical;
390	394		Position:= Height - 75;
391	395		Sides[0].Width:= Width;
392	396		Sides[0].Height:= Position;
393	397		end;
394	398
395	399		HorizontalSplitter:= TPairSplitter.Create(Self);
396	400		with (HorizontalSplitter) do
397	401		begin
398	402		Parent:= VerticalSplitter.Sides[0];
399	403		Width:= Self.Width;
400	404		Height:= VerticalSplitter.Position;
401	405		align:= alClient;
402	406		SplitterType:= pstHorizontal;
403	407		Position:= 125;
404	408		end;
405	409
406	410		LeftPanel:= TPanel.Create(Self);
407	411		with (LeftPanel) do
408	412		begin
409	413		Parent:= HorizontalSplitter.Sides[0];
410	414		Align:= alClient;
411	415		end;
412	416
413	417		MainPanel:= TPanel.Create(Self);
414	418		with (MainPanel) do
415	419		begin
416	420		Parent:= HorizontalSplitter.Sides[1];
417	421		Align:= alClient;
418	422		Caption:= 'Hello';
419	423		end;
420	424
421	425		BottomPanel:= TPanel.Create(Self);
422	426		with (BottomPanel) do
423	427		begin
424	428		Parent:= VerticalSplitter.Sides[1];
425	429		Align:= alClient;
426	430		end;
427	431		end;
428	432		```
429	433
430	434		So as you can see, farely consistant with most control hierarchy. And if you are familiar with DFM's, the changes needed for DFM-\>LFM conversion should be farely obvious from the above, as they are the same sort of changes in Parent/Owner etc.
431	435
432	436		So the above example would be something like -
433	437
434	438		Delphi DFM
435	439
436	440		(extraneous values removed)
437	441
438	442		Lazarus LFM
439	443
440	444		(most width, height, etc. removed)
441	445
442		-	~~``` pascal~~
	446	+	``` lfm
443	447		object VerticalSplitter: TSplitter
444	448		Height = 3
445	449		Cursor = crVSplit
446	450		Align = alBottom
447	451		end
448	452		object HorizontalSplitter: TSplitter
449	453		Width = 3
450	454		Align = alLeft
451	455		end
452	456		object BottomPanel: TPanel
453	457		Height = 75
454	458		Align = alBottom
455	459		end
456	460		object LeftPanel: TPanel
457	461		Width = 125
458	462		Align = alLeft
459	463		end
460	464		object MainPanel: TPanel
461	465		Align = alClient
462	466		end
463	467		```
464	468
465		-	~~``` pascal~~
	469	+	``` lfm
466	470		object VerticalSplitter: TPairSplitter
467	471		Align = alClient
468	472		SplitterType = pstVertical
469	473		Position = 225
470	474		Height = 300
471	475		Width = 400
472	476		object Pairsplitterside1: TPairSplitterIde
473	477		object HorizontalSplitter: TPairSplitter
474	478		Align = alClient
475	479		Position = 125
476	480		object Pairsplitterside3: TPairSplitterIde
477	481		Width = 125
478	482		object LeftPanel: TPanel
479	483		Align = alClient
480	484		Width = 125
481	485		end
482	486		end
483	487		object Pairsplitterside4: TPairSplitterIde
484	488		object MainPanel: TPanel
485	489		Align = alClient
486	490		end
487	491		end
488	492		end
489	493		end
490	494		object Pairsplitterside2: TPairSplitterIde
491	495		object BottomPanel: TPanel
492	496		Align = alClient
493	497		Height = 75
494	498		end
495	499		end
496	500		end
497	501		```
498	502
499	503		### TCustomTreeView/TTreeView
500	504
501	505		Both VCL and the LCL provide a TCustomTreeView/TTreeView component, used for tree structured lists of data with multiple nodes and advanced selection and Image lists, and while actual features are comparable, not all properties are entirely compatible. Primary differences are as follows -
502	506
503	507		Incomplete list, also update to include TCustomTreeView Mark functions and protected methods
504	508
505	509		1. The LCL provides a TCustomTreeView.Options, a set of options which can be set on the control to change its behaviour and apearance. These options are :
506	510		- tvoAllowMultiselect - enables multi node select mode, equivalent to enabling TCustomTreeView.MultiSelect in the D6 VCL
507	511		- tvoAutoExpand - Auto Expand nodes, equivalent to enabling TCustomTreeView.AutoExpand
508	512		- tvoAutoInsertMark - Update the Drag preview on mouse move.
509	513		- tvoAutoItemHeight - Adjust the item heights automatically.
510	514		- tvoHideSelection - Do not mark the selected item.
511	515		- tvoHotTrack - use Hot Tracking, equivalent to enabling TCustomTreeview.HotTrack
512	516		- tvoKeepCollapsedNodes - When shrinking/folding nodes, keep the child nodes
513	517		- tvoReadOnly - make Treeview read only, equivalent to enabling TCustomTreeview.ReadOnly
514	518		- tvoRightClickSelect - allow using Mouse Right Clicks to select nodes, equivalent to enabling TCustomTreeView.RightClickSelect
515	519		- tvoRowSelect - allow selecting rows, equivalent to enabling TCustomTreeView.RowSelect
516	520		- tvoShowButtons - show buttons, equivalent to enabling TCustomTreeView.ShowButtons
517	521		- tvoShowLines - show node lines, equivalent to enabling TCustomTreeView.ShowLines
518	522		- tvoShowRoot - show root note, equivalent to enabling TCustomTreeView.ShowRoot
519	523		- tvoShowSeparators - show seperators
520	524		- tvoToolTips - show tooltips for individual nodes
521	525		2. The LCL provides additional properties:
522	526		- TCustomTreeView.OnSelectionChange event
523	527		- TCustomTreeView.DefaultItems, for the default number of Items
524	528		- TCustomTreeView.ExpandSignType to determine sign used on expandable/collapsible nodes
525	529		3. While most On Drag/Dock Events are available in the LCL they do not work. For more information please see earlier section on Control Dragging/Docking.
526	530
527	531		### Messages / Events
528	532
529	533		The order and frequency of messages and events (OnShow, OnActivate, OnEnter, ...) differ from the VCL and depend on the [[Widgetset\|widgetset]]. The LCL provides a subset of WinAPI like messages to make porting of Delphi components easier, but almost all LCL messages work a little bit different than the VCL/WinAPI counterpart. The biggest part of Delphi code using WinAPI messages uses them, because the VCL lacks a feature or for speed reasons. Such things will seldom work the same under the LCL, so they must be checked manually. That's why LCL messages are called for example LM_SIZE instead of WM_SIZE (unit lmessages).
530	534
531	535		Note on handling of custom messages! As of version 0.9.26 (December 2008), way of handling custom WinApi messages (e.g. WM_HOTKEY, WM_SYSCOMMAND) differs from the way of handling these messages in Delphi. At the moment you cannot handle them via message directive or via overriding of WndProc method of the form. The only way to handle them in the form is to hook Windows windowproc by yourself. Read more here: [[Win32/64 Interface\|Processing non-user messages in your window]]
532	536
533	537		## See also
534	538
535	539		- [[Delphi language features missing from the Free Pascal Compiler]]
536	540		- [[Code Conversion Guide\|Code Conversion Guide (from Delphi & Kylix)]]
537	541		- [[Compile With Delphi]]
538	542
539	543		---
540	544		From the Free Pascal wiki, page "Lazarus For Delphi Users", as it stood on 2022-05-31 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