Lazarus For Delphi Users/ko: what changed

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

Old	New		Line
1	1		이 문서는 라자루스에 흥미를 가지는 델파이 유저를 위한 것입니다. 이문서는 둘 사이의 차이점에 대해 설명합니다.
2	2
3	3		## 델파이 -\> 라자루스
4	4
5	5		Lazarus is an Rapid Application Development (RAD) tool like Delphi. That means it comes with a visual component library and an IDE. The Lazarus component library (LCL) is very similar to Delphi's VCL. Most units, classes and properties have the same name and functionality. This makes porting easy. But Lazarus is not an 'open source Delphi clone'. So don't expect 100% compatibility.
6	6
7	7		### 큰 차이점
8	8
9	9		Lazarus is completely open source, is written platform independent and uses the mighty [[Free Pascal]] compiler (FPC). FPC runs on more than 15 platforms. But not all packages and libs are ported, so Lazarus currently runs on Linux (i386, x86_64), FreeBSD (i386), Mac OS X (powerpc, i386) and Windows (i386, x86_64).
10	10
11	11		리자루스는 완전하지 않지만 그러기 위해서 이문서를 꾸준히 향상시킨다. 우리는 항상 새로운 개발자들, 패키지제작자들, 이식자들, 문서작성자들... 을 위해 검색한다.
12	12
13	13		### 첫번째 언제 델파이 프로젝트를 컨버팅 할지 생각하는 것입니다.
14	14
15	15		Having opened Lazarus, you should go to to Tools and then 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.
16	16
17	17		### 유니코드 지원
18	18
19	19		델파이 2007버전 전까지는 유니코드를 지원하지 못했습니다, 그래서 윈도우 ANSI encoding을 사용했습니다.
20	20
21	21		델파이 2009버전에서는 UTF-16 문자열을 지원합니다.
22	22
23	23		라자루스는 온전히 유니코드를 지원하고 UTF-8 문자열을 사용합니다. 더 자세한 정보는 [[LCL Unicode Support\|LCL Unicode Support를]] 참조하세요.
24	24
25	25		## Delphi IDE -\> Lazarus IDE
26	26
27	27		### 프로젝트들
28	28
29	29		The main file of a Delphi application is the .dpr file. The main file of a Lazarus project is the .lpi file (Lazarus Project Information). A .dpr file is the program main source and the Delphi IDE stores some information about the compiler switches and units. A Lazarus application also has a .lpr file, which is also the main source file. But all other information is stored in the .lpi file. So, the important file is the .lpi file.
30	30
31	31		For example:
32	32
33	33		Delphi stores the paths of the units in the .dpr file. For instance: unit1 in 'path/Unit1.pas'. These 'in' paths are Delphi specific and are not read by the Lazarus IDE. Don't use them. Use instead the compiler options unit paths.
34	34
35	35		Delphi stores compiler options in the .dpr file. For instance {\$APPTYPE CONSOLE}. These are ignored by the Lazarus IDE. Don't use them. Use instead the compiler options.
36	36
37	37		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". This means, the current editor settings are also stored in the .lpi file and are restored when you reopen the project. For example: You are debugging an application, 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 history, ... are restored.
38	38
39	39		### 소스 에디터
40	40
41	41		Nearly all keys and short cuts can be defined in Tools -\> Options -\> Editor -\> Key Mappings
42	42
43	43		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:
44	44
45	45		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".
46	46
47	47		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.
48	48
49	49		#### 지역변수 완성 예제
50	50
51	51		"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		"i" 뒤에 커서를 이동한 뒤 `Ctrl`+`Shift`+`C` 누름:
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		#### 이벤트 할당 완성 예
71	71
72	72		A nice feature of the object inspector is to auto create methods. You can get the source editor to create the events too.\
73	73		예시:
74	74
75	75		``` pascal
76	76		Button1.OnClick:=
77	77		```
78	78
79	79		":=" 뒤로 커서를 이동 한 뒤 `Ctrl`+`Shift`+`C` 누름.
80	80
81	81		#### 프로시저 호출 완성 예
82	82
83	83		Assume you just wrote the statement "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		"DoSomething" 뒤 커서 이동후 `Ctrl`+`Shift`+`C` 누름
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		#### "Word Completion" Ctrl+W
113	113
114	114		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.
115	115
116	116		#### 인크루드 파일들의 지원
117	117
118	118		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.
119	119
120	120		There are many options for the code features.
121	121
122	122		### 디자이너
123	123
124	124		\- Guidelines
125	125
126	126		#### 오브젝트 인스펙터
127	127
128	128		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 :
129	129
130	130		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"
131	131		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.
132	132		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)".
133	133		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
134	134
135	135		#### 패키지
136	136
137	137		리자루스 설치 후 델파이 패키지를 사용 할수 있나요?
138	138
139	139		아니요, 왜냐하면 그것들은 델파이 컴파일러를 요구하기때문입니다.
140	140
141	141		우리는 특별히 리자루스를 위해 만들어진 것들을 필요합니까?
142	142
143	143		Yes. 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 differences between Lazarus and Delphi packages, so please read
144	144
145	145		\- 문서 / 라자루스 소스에 Packages.txt을 참조하십시오.
146	146
147	147		### VCL -\> LCL
148	148
149	149		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]] .
150	150
151	151		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.
152	152
153	153		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.
154	154
155	155		#### TControl.Font/TControl.ParentFont
156	156
157	157		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.
158	158
159	159		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.
160	160
161	161		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.
162	162
163	163		#### Control Dragging/Docking
164	164
165	165		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.
166	166
167	167		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.
168	168
169	169		This currently means that no Control will inherit/use the following TControl functions, procedures, properties, or events -
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		that the following classes do not exist/are unusable -
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		and that the following functions are also unusable/incompatible -
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		도킹 매니져의 설명은 여기에: [[Anchor Docking]]
243	243
244	244		#### TEdit/TCustomEdit
245	245
246	246		The Edit controls, while functioning essentialy the same in the LCL as the VCL, do have some issues to be aware of in converting -
247	247
248	248		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.
249	249		2. On Drag/Dock Events are not yet implemented. For more information please see earlier section on Control Dragging/Docking.
250	250		3. Font Properties are usually ignored for interface consistancy, for detailed explanation as too why please see TControl.Font/TControl.ParentFont
251	251
252	252		#### TDBImage
253	253
254	254		Delphi and Lazarus both have a TDBImage control that shows images stored in a database field. However, Lazarus stores information about the image type in the database field before the actual image data. See procedure TDBImage.UpdateData This means that the Delphi and Lazarus implementations are not compatible.
255	255
256	256		Note: current (r40924, April 2013) Lazarus trunk 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.
257	257
258	258		### (optional) TSplitter -\> TPairSplitter
259	259
260	260		Please Improve Me
261	261
262	262		There is now a TSplitter control in the LCL, so no need to convert it.
263	263
264	264		Nevertheless, if you want, here it is explained:
265	265
266	266		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):
267	267
268	268		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.
269	269
270	270		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.
271	271
272	272		So what exactly are the differences?
273	273
274	274		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.
275	275
276	276		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.
277	277
278	278		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,
279	279
280	280		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.
281	281
282	282		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 :
283	283
284		-	~~`PairSplitter.Position := PairSplitter.Width - PairSplitter.Position; `~~
	284	+	``` pascal
	285	+	PairSplitter.Position := PairSplitter.Width - PairSplitter.Position;
	286	+	```
285	287
286	288		So how can I convert existing code using TSplitter to the TPairSplitter?
287	289
288	290		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 -
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		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.
401	403
402	404		So the above example would be something like -
403	405
404	406		Delphi DFM
405	407
406	408		(extraneous values removed)
407	409
408	410		Lazarus LFM
409	411
410	412		(most width, height, etc. removed)
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		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 -
472	474
473	475		Incomplete list, also update to include TCustomTreeView Mark functions and protected methods
474	476
475	477		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 :
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 - Adjust the item heights automatically.
480	482		- tvoHideSelection - Do not mark the selected item.
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 - allow selecting rows, equivalent to enabling TCustomTreeView.RowSelect
486	488		- tvoShowButtons - show buttons, equivalent to enabling 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 - show seperators
490	492		- tvoToolTips - show tooltips for individual nodes
491	493		2. The LCL provides additional properties:
492	494		- TCustomTreeView.OnSelectionChange event
493	495		- TCustomTreeView.DefaultItems, for the default number of Items
494	496		- TCustomTreeView.ExpandSignType to determine sign used on expandable/collapsible nodes
495	497		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.
496	498
497	499		### Messages / Events
498	500
499	501		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).
500	502
501	503		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]]
502	504
503	505		## See Also
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/ko", 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