Code Conversion Guide: what changed

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

Old	New		Line
1	1		This page is about how to port or convert existing Delphi or Kylix code to work with the [[Free Pascal]] Compiler and Lazarus IDE. While Lazarus and the Free Pascal Compiler have aspects in common with Delphi and Kylix, they are not clones. There are a number of library call and convention differences... and in some areas, FPC is enhanced and can be more demanding about correct syntax. Please see the [[Lazarus For Delphi Users]] guide for a description of some of the functional differences.
2	2
3	3		The purpose of this guide is to document some of the specific differences that are frequently encountered during the code conversion process when translating existing code from Delphi to Lazarus.
4	4
5	5		This document was placed into the wiki knowledge-base area so it could be easily extended by anyone who had encountered a unique problem and would like to post it for others to be aware of.
6	6
7	7		## Selecting a component or library for conversion
8	8
9	9		### Where to find code to convert
10	10
11	11		There is a LOT of code available on the net that can be converted for use with FPC and Lazarus. Here is a [[Page Of Code Sites]] that is just a start. Please add to it if you know of any other good locations. TurboPower Software has recently released their entire commercial offering under the MPL. A list of available packages can be found [here](http://sourceforge.net/users/tpsfadmin/).
12	12
13	13		To avoid duplicating effort, packages that have already been converted are listed on the [[Components and Code examples]] page. If you've converted a package or are working on one, please add a note on the [[Current conversion projects]] page.
14	14
15	15		### Licensing
16	16
17	17		Licenses for existing code range from freeware/public domain to restrictive versions that prohibit modification, re-distribution and commercial use. Before converting any package, it's a good idea to examine its licensing and make sure it's going to be compatible with Lazarus and the Free Pascal Compiler. License selection is especially important with components since dropping one on a form can impose an unwanted or incompatible license on an entire application.
18	18
19	19		When converting components, please respect the wishes of the original author and retain all copyright and licensing headers along with email addresses and url's. It's courteous and often useful to inform the author that their component is being converted... especially if the component is under a restrictive license. New interest in an old or forgotten component can sometimes inspire authors to revise their original and overly restrictive licensing.
20	20
21	21		In general, Public Domain (freeware), and the LGPL/MPL are the the most flexible for distributing components. For more information, the [Open Source Definition](http://www.opensource.org/docs/definition.php) is a good place to start. There are also several comparisons available to help clarify how the various types of licenses work and what impact they'll have on code they're linked to. Search for "open source license comparison"
22	22
23	23		### Dependencies
24	24
25	25		Another step before starting to work on a conversion is to verify that the code doesn't have deep dependancies on other packages that might not be available or represent a considerable conversion challenge. Some freeware offerings are bound to or extend proprietary packages that are frequently no longer available or come with inappropriate licenses.
26	26
27	27		### Compiler Issues
28	28
29	29		See:
30	30
31	31		- [Known problems](http://www.freepascal.org/probs.html)
32	32		- [Unfixed bugs](https://gitlab.com/freepascal.org/fpc/source/-/issues)
33	33
34	34		### Platform and OS Issues
35	35
36	36		Lazarus and the Free Pascal Compiler are cross-platform and cross-architecture development tools. In contrast, most existing Delphi code was specifically designed to run on an Intel processor under Win32. If your candidate component has a lot of Win32 specific code, it might be wise to try and find a less platform dependant alternative. But don't let this stop you... it's genuinely amazing what the LCL supports!
37	37
38	38		## Doing the conversion
39	39
40	40		### Setting up the Lazarus environment for a conversion project
41	41
42	42		#### Create a test project
43	43
44	44		- Place code to be converted into a subdirectory (ie: convertdir)
45	45		- Bring up Lazarus
46	46		- File-\>Save All to the convertdir subdirectory. Meaningful names for the Project and default unit are optional.
47	47		- Open the "main" unit to be converted in convertdir
48	48		- Add it to the project: Project-\>Add Active Unit to Project
49	49		- Run Tools-\>Quick Syntax Check or Run Build All to get started.
50	50
51	51		#### Delphi VCL, Kylix CLX Sources in Lazarus
52	52
53	53		When converting Delphi/Kylix sources, it is often useful to do a find declaration to see, what a specific function is doing. The Lazarus IDE can parse the Delphi/Kylix sources. To do this it needs some searchpaths and compiler settings. You can easily setup this in Environment-\>CodeTools Defines Editor-\>Insert Template
54	54
55	55		### Conversion problems and solutions
56	56
57	57		#### Delphi / Kylix file equivalents in Lazarus
58	58
59	59		Delphi / Kylix
60	60
61	61		Description
62	62
63	63		Lazarus
64	64
65	65		Description
66	66
67	67		.pas
68	68
69	69		.dfm/.xfm,
70	70
71	71		.dcu/.dpu,
72	72
73	73		.dpr(main project file),
74	74
75	75		.res,
76	76
77	77		.dof/.kof
78	78
79	79		---
80	80
81	81		---
82	82
83	83		---
84	84
85	85		Delphi Source File, Delphi Form,
86	86
87	87		Delphi Compiled Unit,
88	88
89	89		Delphi Project,
90	90
91	91		Windows Resource File,
92	92
93	93		Delphi Option File
94	94
95	95		.pas, .pp .lfm,
96	96
97	97		.o,
98	98
99	99		.lpr
100	100
101	101		---
102	102
103	103		---
104	104
105	105		.lrs,
106	106
107	107		.lpi(main project file),
108	108
109	109		.ppu
110	110
111	111		Pascal unit file,
112	112
113	113		Form data file,
114	114
115	115		Compiled unit file,
116	116
117	117		Project file,
118	118
119	119		Resource file,
120	120
121	121		Project options file,
122	122
123	123		Lazarus resource file,
124	124
125	125		Lazarus project information file,
126	126
127	127		FPC unit description file
128	128
129	129		So a Delphi .dcu file roughly corresponds to a FPC .o and .ppu together in one file. The .PPU is mostly the header(interface) part, the .o mostly the implementation part. Main exceptions are inlined functions, that in to-be-inlined form are in the .ppu.
130	130
131	131		#### Converting Delphi projects/forms/units to Lazarus
132	132
133	133		Use the Delphi converter in new Lazarus version to convert automatically. It does most of the things explained later on this page. More information here: [[Delphi Converter in Lazarus]]
134	134
135	135		The following text explains the differences between Delphi and Lazarus and how to convert manually.
136	136
137	137		#### Selecting the right compiler mode
138	138
139	139		The [[Free Pascal]] Compiler supports 5 different pascal modes. For example TP for turbo pascal, lets you compile turbo pascal units. There is also a DELPHI compatibility mode that can be set to make existing code easier to convert. Lazarus prefers the OBJFPC mode, which almost equals the DELPHI mode, but is less ambiguous than the Delphi syntax. Here are the important points:
140	140
141	141		The mode can be selected at command line or at the start of the source. Using the command line has the advantage, that you don't need to change the source, but the disadvantage, that others must be told.
142	142
143	143		Most Delphi units can be compiled by the [[Free Pascal]] compiler by adding:
144	144
145	145		``` pascal
146	146		{$IFDEF FPC}
147	147		{$MODE DELPHI}
148	148		{$ENDIF}
149	149		```
150	150
151	151		right after the unit name.
152	152
153	153		For more details about [[Free Pascal]] modes see the [Free Pascal Documentation](http://www.freepascal.org/docs-html/prog/progap4.html#progse62.html)
154	154
155	155		#### Cross-Platform considerations
156	156
157	157		- Inline assembler is always a problem because it will bind the code to the Intel architecture. Some developers do algorithm prototypes in Pascal and ifdef the their optimized assembler. Fortunately TurboPower did this in numerous places with their code. If this is the case with the package you're converting, throw the switch back to Pascal.
158	158		- Don't reference specific memory location like the BIOS data area. Find out what the code needs and try to find a cross platform alternative.
159	159		- Don't do processor specific tricks (like using the Intel TSC) without enclosing your code in an ifdef for the platform the code needs... and providing an alternative for environments that don't have the hardware capability.
160	160		- If you need some OS specific code, then you can use IFDEFs. See below for a list of macros.
161	161
162	162		#### Useful compiler variables / defines / macros
163	163
164	164		To write code, that behaves on different systems differently, you can use the
165	165
166	166		{\$IFDEF Name}
167	167
168	168		directives.
169	169
170	170		- {\$IfDef FPC}
171	171
172	172		This variable is defined, when using the FPC compiler. Useful to write code, that works with FPC and Delphi. For compatibility reasons FPC defines the DELPHI macro in mode Delphi. So you can not use {\$IFNDEF DELPHI}.
173	173
174	174		- {\$IfDef FPC_OBJFPC}
175	175
176	176		This variable is defined when using mode OBJFPC and can be a substitute for {\$IFNDEF Delphi} for e.g. the @ differences
177	177
178	178		- {\$IfDef LCL}
179	179
180	180		This variable is defined, when using the LCL package. Useful to write code, that works with the LCL and Delphi.
181	181
182	182		- {\$IfDef LCLGtk}
183	183
184	184		,
185	185
186	186		{\$IfDef LCLWin32}
187	187
188	188		,
189	189
190	190		{\$IfDef LCLQt}
191	191
192	192		, ...
193	193
194	194		This variable is defined, when using the LCL package and the specific [[Widgetset\|widgetset]] is currently used. Useful to write code, that works with the LCL on a specific platform.
195	195
196	196		- {\$IfDef Unix} // for Linux, BSD, macOS, Solaris
197	197
198	198		,
199	199
200	200		{\$IfDef Win32}
201	201
202	202		,
203	203
204	204		{\$IfDef Linux}
205	205
206	206		// for Linux,
207	207
208	208		{\$IfDef Darwin}
209	209
210	210		// macOS,
211	211
212	212		{\$IfDef WinCE}
213	213
214	214		// for WinCE,...
215	215
216	216		Defined by FPC for the current Target OS. Delphi defines "Linux", "Win32" and "MSWindows". [[Free Pascal]] runs on much more platforms and so it is recommended to use the more general items. For example "Unix" is defined for Linux, FreeBSD, NetBSD and OpenBSD, where Lazarus already runs. Use for code that should work with Delphi and FPC:
217	217
218	218		``` pascal
219	219		{$IFDEF Linux}
220	220		{$DEFINE Unix}
221	221		{$ENDIF}
222	222		```
223	223
224	224		to work around this for Kylix.
225	225
226	226		- {\$IfDef ENDIAN_BIG}
227	227
228	228		This macro is defined on big endian processors such as the PowerPC as used, a.o., in older Apple computers. Their byte order is the reverse of that of Intel compatible processors.
229	229
230	230		- {\$IfDef ENDIAN_BIG}
231	231
232	232		For more details see the [Free Pascal Documentation](http://www.freepascal.org/docs-html/prog/prog.html#QQ2-23-21).
233	233
234	234		#### 32bit / 64 bit support
235	235
236	236		Pointers under 64bit need 8 bytes instead of 4 on 32bit. The 'Integer' type remains for compatibility 32bit. This means you can no longer typecast pointers into integers and back. FPC defines two new types: PtrInt and PtrUInt. PtrInt is a 32bit signed integer on 32 bit platforms and a 64bit signed integer on 64bit platforms. The same for PtrUInt, but unsigned integer instead. Use for code that should work with Delphi and FPC:
237	237
238	238		``` pascal
239	239		{$IFNDEF FPC}
240	240		type
241	241		PtrInt = integer;
242	242		PtrUInt = cardinal;
243	243		{$ENDIF}
244	244		```
245	245
246	246		Replace all integer(SomePointerOrObject) with PtrInt(SomePointerOrObject).
247	247
248	248		For more information see [[Multiplatform Programming Guide]].
249	249
250	250		#### Finding a missing identifier
251	251
252	252		There are differences in how the LCL is organized when compared to the Delphi VCL. If you get a "not found" compiler error about a major class or identifier, the chances are good that it's in a different unit. A complete cross reference can be found by grep'ing lazarus/docs/xml or the lcl subdirectory.
253	253
254	254		For example the commonly used tbutton typically throws an error in Delphi code because it's located in a unit named buttons.pp. The following command finds the correct unit very quickly (in the lazarus source directory):
255	255
256	256		``` bash
257	257		grep -in ' tbutton =' lcl/*
258	258		```
259	259
260	260		#### Major unit differences between Lazarus and Delphi
261	261
262	262		Please add to this topic!
263	263
264	264		- Windows-\>Interfaces, LCLIntf, LCLType, LCLProc, ...)
265	265
266	266		As the LCL is not windows specific, the code that is in the Delphi Windows unit for directly accessing the Win32 API is abstracted into separate interfaces, which can be accessed from the LCLIntf unit. Keep in mind, that Lazarus does not emulate win32, so many functions are missing and some do not work as their win32 counterparts. These functions only exist for Delphi compatibility and should only be used for quick & dirty porting. LCL also breaks out many of the types, so often LCLType is required. LCLProc also contains a few functions which can be useful for lower level handling such as "FreeThenNil" as is in Delphi 5 and higher, "DeleteAmpersands" to remove additional ampersands from a string for controls(& vs && etc). The Interfaces unit needs to be included in the .lpr file to initialize the appropriate widgetset.
267	267
268	268		- Messages-\>LMessages
269	269
270	270		TControl Messages for win32 event callbacks of the format WM_CALLBACK and the structs associated with them are often found in the Messages unit in Delphi. In the LCL these types of messages and there structs are usually found in LMessages, usually with name changes of WM to LM, so for instance WM_MOUSEENTER becomes LM_MOUSEENTER, and TWMMouse becomes TLMMouse.
271	271
272	272		- Graphics, Controls-\>GraphType, GraphMath, Graphics, Controls
273	273
274	274		To simplify some things and break complexity of circles between units, a few types have been abstracted into a shared unit called GraphType, which includes things, which in Delphi are located in Graphics or Controls, for instance the bvNone etc of panels. So sometimes you have to include it. Also a unit which, although incompatible with Delphi, adds other useful functionality is GraphMath, which adds a TFloatPoint for precision, misc routines for dealing with beziers, lines, and arcs, as well as some operator overloading for use with TPoints and TRect, such as for instance Point1 := Point2 + Point3, and comparing two rects like if (rect1 = rect2) then ...
275	275
276	276		- Mask-\>MaskEdit
277	277
278	278		For more intelligent naming considerations, the unit for TMaskEdit is called \[MaskEdit\\|\] instead of the slightly more nebulous Mask as in many versions of Delphi.
279	279
280	280		- StdCtrls-\>StdCtrls,Buttons
281	281
282	282		In many version of Delphi TButton is located in StdCtrls, while TSpeedButton and TBitBtn are in Buttons. For consistency and simplicity the LCL puts all button types in Buttons, which can occasionally break code conversion, so it is always a good idea to include.
283	283
284	284		#### Property and method differences Delphi -\> FPC/LCL
285	285
286	286		- TBitmap contains a canvas in the LCL
287	287		- [[Lazarus Faq\|Lazarus_Faq#Why are TForm.ClientWidth.2FClientHeight the same as TForm.Width.2FHeight]]
288	288
289	289		#### Semantical differences
290	290
291	291		##### Order of parameter evaluation
292	292
293	293		Delphi guarantees that all parameters are evaluated from left to right. FPC makes no such guarantee, and can evaluate parameters in any order it wants in order to generate optimal code.
294	294
295	295		##### Nested procedures/functions as procedural variables
296	296
297	297		Delphi passes the framepointer of the parent procedure always on the stack, and has the caller remove it again. This means that as long as you do not access variables from a parent procedure, you can pass the address of a nested function to another function which then can call it like any other procedural variable.
298	298
299	299		FPC on the other hand always passes the framepointer of the parent procedure as a hidden first parameter according to the current calling convention, which means that if you call a nested procedure like a regular procedural variable, all parameters will be "shifted" one position.
300	300
301	301		In short, do not call nested procedures via procedural variables.
302	302
303	303		##### Ref count release
304	304
305	305		Documented behaviour in both Delphi and FPC is that temporary variables stay allocated till after the statement of last use. (so if an interface is used in a parameter declaration, it is earliest released after that whole procedure/method call statement has finished).
306	306
307	307		However in practice FPC often indeed decreases the refcount the very next statement, while Delphi tends to wait till the end of procedures. Or, in very large procedures, till the end of a large block.
308	308
309	309		Both are valid choices though, and fixating this behaviour would hem in the codegeneration and optimizer too much, and it won't changed.
310	310
311	311		This can occasionally cause apparently working Delphi code that mixes object and interface references to fail, and is a typical case of seemingly working code not being correct and depending on implementation choices. The Delphi documentation doesn't make any such guarantees.
312	312
313	313		#### Syntax differences
314	314
315	315		Please add to this topic!
316	316
317	317		Because of the inherent strictness in FPC, some syntax changes are necessary, even though
318	318
319	319		{\$Mode Delphi}
320	320
321	321		does allow more laziness like Delphi does. For this reason complying as much with the syntax rules of
322	322
323	323		{\$Mode ObjFPC}
324	324
325	325		as possible is highly recommended, even when the codebase is still going to be shared between Delphi and the LCL. Some of these are simply better coding practices, and sometimes because Delphi mode is not entirely accurate, or in a few instances Delphi acceptible code does not function as expected with FPC, even though it might compile. To that end even though not all such are strictly required, the following list of changes should be considered mandatory :
326	326
327	327		##### When assigning an event handling entry point, prefix it with an "@"
328	328
329	329		For instance, you might assign a button [[callback]] manually.
330	330
331		-	~~```~~
	331	+	```text
332	332		With the Delphi code compiled under Lazarus You will get the error message
333	333		"Wrong number of parameters specified for call to "SomeFunction" "
334	334		```
335	335
336	336		Delphi
337	337
338	338		OBJFPC
339	339
340	340		both
341	341
342	342		``` pascal
343	343		begin
344	344		if not Assigned(MyButton.OnClick) then
345	345		MyButton.OnClick:= SomeFunction;
346	346		//@ not required
347	347		//more code...
348	348		end;
349	349		```
350	350
351	351		``` pascal
352	352		begin
353	353		if not Assigned(MyButton.OnClick) then
354	354		MyButton.OnClick:= @SomeFunction;
355	355		//@ IS required
356	356		//more code...
357	357		end;
358	358		```
359	359
360	360		\\|
361	361
362	362		``` pascal
363	363		begin
364	364		if not Assigned(MyButton.OnClick) then
365	365		MyButton.OnClick:= {$IFDEF FPC_OBJFPC}@{$ENDIF}SomeFunction;
366	366		//@ is only required under mode OBJFPC - but not allowed under Delphi
367	367		//more code...
368	368		end;
369	369		```
370	370
371	371		Note that this behavior of the compiler can also be influenced using the CLASSICPROCVARS modeswitch.
372	372
373	373		##### When calling a procedure variable use this syntax: theprocname()
374	374
375	375		In Delphi there is no difference between a function result and a variable, however there is in FPC, so to call a function, even if it has no parameters, you must append parenthesis.
376	376
377	377		``` pascal
378	378		With the Delphi code compiled under Lazarus You will get the error message
379	379		"Incompatible types: got "<procedure variable type of function:DWord;StdCall>" expected "LongWord" "
380	380		```
381	381
382	382		Delphi
383	383
384	384		OBJFPC
385	385
386	386		both
387	387
388	388		``` pascal
389	389		With (SomeObject) do
390	390		begin
391	391		If Assigned(OnMyCallback) then
392	392		OnMyCallback;
393	393		//parenthesis not required
394	394		end;
395	395		```
396	396
397	397		``` pascal
398	398		With (SomeObject) do
399	399		begin
400	400		If Assigned(OnMyCallback) then
401	401		OnMyCallback();
402	402		//parenthesis required
403	403		end;
404	404		```
405	405
406	406		\\|
407	407
408	408		``` pascal
409	409		Simply use the OBJFPC way, with brackets:
410	410
411	411		OnMyCallback();
412	412
413	413		Delphi accepts this, too.
414	414		```
415	415
416	416		##### When accessing values in a pointer to a record you must dereference first
417	417
418	418		In Delphi it is not required to de-reference a pointer to a record to access values within it, it can, in fact, be treated just like the record itself, or any other object. In FPC it must be first de-referenced.
419	419
420		-	~~```~~
	420	+	```text
421	421		With the Delphi code compiled under Lazarus You will get the following messages :
422	422		"Error: Illegal qualifier"
423	423		"Hint: may be pointer dereference is missing"
424	424		```
425	425
426	426		Delphi
427	427
428	428		OBJFPC
429	429
430	430		both
431	431
432	432		``` pascal
433	433		Function GetSomeValue(ARecord: PMyRecord):Integer;
434	434		begin
435	435		If Assigned(ARecord) then
436	436		Result:=ARecord.SomeValue
437	437		else
438	438		Result:=0;
439	439		end;
440	440		```
441	441
442	442		``` pascal
443	443		Function GetSomeValue(ARecord: PMyRecord):Integer;
444	444		begin
445	445		If Assigned(ARecord) then
446	446		Result:=ARecord^.SomeValue
447	447		else
448	448		Result:=0;
449	449		end;
450	450		```
451	451
452	452		\\|
453	453
454	454		``` pascal
455	455		Simply use the OBJFPC way, with ^ :
456	456
457	457		Result:=ARecord^.SomeValue
458	458
459	459		Delphi accepts this, too.
460	460		```
461	461
462	462		Note that the behavior of the compiler with regards to (auto) de-referencing pointers can also be influenced using the AUTODEREF modeswitch.
463	463
464	464		##### When accessing chars of an indexed string Property of an object, it must be enclosed in parentheses
465	465
466	466		With Delphi it is possible to treat a Property exactly like some other const or var, e.g. even up to accessing individual chars of a string directly, while this is not always possible in FPC, specifically for indexed properties. Instead it must be enclosed in parentheses, to make distinct. While this may not always hold true it is probably a good practice to consider anyway. For example
467	467
468	468		Delphi
469	469
470	470		OBJFPC
471	471
472	472		``` pascal
473	473		Type TSomeComponent=class(TComponent)
474	474		//More code...
475	475		Published
476	476		Property MyString:String index 3 read GetMyString;
477	477		//More code...
478	478		End;
479	479
480	480		var
481	481		MyChar:char;
482	482		begin
483	483		If Length(MyString)>2 then
484	484		//no parenthesis needed
485	485		MyChar:= MyString[3];
486	486		//More code...
487	487		end;
488	488		```
489	489
490	490		``` pascal
491	491		Type TSomeComponent=class(TComponent)
492	492		//More code...
493	493		Published
494	494		Property MyString:String index 3 read GetMyString;
495	495		//More code...
496	496		End;
497	497
498	498		var
499	499		MyChar:char;
500	500		begin
501	501		If Length(MyString)>2 then
502	502		//parenthesis sometimes needed
503	503		MyChar:= (MyString)[3];
504	504		//More code...
505	505		end;
506	506		```
507	507
508	508		##### You must typecast pointers to actual type when using with var or function of that type
509	509
510	510		Sometimes in Delphi you will have a null pointer variable representing an object. While it might seem a complex situation, it is oddly quite common especially in large component packs as a method of preventing too many circular includes between objects in different units. In Delphi it is then possible to send this null pointer to a function expecting that object, without bothering to typecast to actual type, in fpc you must typecast.
511	511
512	512		For example -
513	513
514	514		Delphi
515	515
516	516		OBJFPC
517	517
518	518		``` pascal
519	519		Unit 1
520	520		Type
521	521		TSomeObject=class(TComponent)
522	522		//More code...
523	523		End;
524	524
525	525		Procedure DoSomething(Value: TSomeObject);
526	526		Function GetSomeObject: TSomeObject;
527	527
528	528		Unit 2
529	529		Type
530	530		TSomeComponent=class(TComponent)
531	531		//More code...
532	532		Published SomeObject: Pointer;
533	533		//More code...
534	534		End;
535	535
536	536		Application
537	537		var
538	538		MyComponent: TSomeComponent;
539	539		begin
540	540		MyComponent.SomeObject:=GetSomeObject;
541	541		//More code...
542	542		DoSomething(MyComponent.SomeObject);
543	543		end;
544	544		```
545	545
546	546		``` pascal
547	547		Unit 1
548	548		Type
549	549		TSomeObject=class(TComponent)
550	550		//More code...
551	551		End;
552	552
553	553		Procedure DoSomething(Value: TSomeObject);
554	554		Function GetSomeObject: TSomeObject;
555	555
556	556		Unit 2
557	557		Type TSomeComponent=class(TComponent)
558	558		//More code...
559	559		Published SomeObject: Pointer;
560	560		//More code...
561	561		End;
562	562
563	563		Application
564	564		var
565	565		MyComponent: TSomeComponent;
566	566		begin
567	567		MyComponent.SomeObject:=Pointer(GetSomeObject);
568	568		//More code...
569	569		DoSomething(TSomeObject(MyComponent.SomeObject));
570	570		end;
571	571		```
572	572
573	573		#### Resources
574	574
575	575		> Note: The section below may not be necessary. Any recent version of Lazarus directly supports .res files. The Windows Lazarus installer includes a resource compiler which supports .rc files. On *nix, please make sure windres is installed so you can use .rc files. See <http://wiki.lazarus.freepascal.org/Lazarus_Resources#FPC_resources>
576	576
577	577		Delphi resource files are win32 specific and not compatible with Lazarus, so you'll have to recreate and compile them using the lazres tool. Lazres can be found in the lazarus/tools subdirectory. If you've downloaded the Lazarus sources, you'll need to compile it first.
578	578
579	579		- cd lazarus/tools
580	580		- make install
581	581
582	582		To add a resource to your application:
583	583
584	584		- lazres myresource.lrs mypix.xpm anotherpix.xpm
585	585		- Add the LResources unit to your Uses clause
586	586		- Include the .lrs file you created under the initialization block
587	587
588	588		Example:
589	589
590	590		``` pascal
591	591		function TForm1.LoadGlyph(const GlyphName: String): TBitMap;
592	592		begin
593	593		Result:= TPixmap.Create;
594	594		Result.LoadFromLazarusResource(GlyphName);
595	595		end;
596	596		//More code...
597	597		begin
598	598		Speedbutton1.glyph:= LoadGlyph('mypix');
599	599		//More code...
600	600		end;
601	601
602	602		initialization
603	603		{$I unit1.lrs}
604	604		{$I myresource.lrs}
605	605		end.
606	606		```
607	607
608	608		### Another method to convert a Delphi or Kylix project to Lazarus
609	609
610	610		- Rename or copy all .dfm or .xfm files to .lfm (Very old Delphi versions do not produce a text-based .dfm file. The convert utility, if present in the \bin folder can be used to covert the .dfm first))
611	611		- Rename or copy .dpr file to .lpr
612	612		- Make all necessary changes to .lpr file:
613	613
614	614		1. Add {\$mode delphi}{\$H+} or {\$mode objfpc}{H+} directives
615	615		2. Add 'Interfaces' to uses clause
616	616		3. Comment out or delete {\$R *.res} or directive if needed
617	617
618	618		- Make necessary changes to all .pas unit files:
619	619
620	620		1. Add {\$mode delphi}{\$H+} or {\$mode objfpc}{H+} directives
621	621		2. Add 'LResources' - to do: check if this is still needed for any vaguely new Lazarus version
622	622		3. If the form has buttons, add 'Buttons' to uses clause
623	623		4. Comment out or delete {\$R .dfm} or {\$R .xfm} directive
624	624		5. Add 'Initialization' section at the end of each unit file, and add {\$I unitname.lrs} directive in it
625	625
626	626		- Select Project-\>New Project from file
627	627		- Select the .lpr file
628	628		- In the 'Create a new project' window, choose 'Application'
629	629		- Build project and make further necessary corrections to get proper compilation. At this point the .lpi file is generated automaticaly. You may get 'Error reading Form' messages, click on 'Continue Loading' if you do.
630	630		- Save all, and you have a Lazarus project :-)
631	631
632	632		## Getting Help
633	633
634	634		If you encounter a problem during conversion that you just can't solve, there are a wide variety of places to get help.
635	635
636	636		### Documentation
637	637
638	638		For pure Object Pascal and FPC issues
639	639
640	640		The best place to start is the Free Pascal [Documentation](http://www.freepascal.org/docs-html/) by Michaël Van Canneyt and Florian Klämpfl.
641	641
642	642		For more Lazarus oriented problems
643	643
644	644		The Lazarus Project Documentation in the Lazarus-CCR Knowledgebase [[Main Page]] is the next place to look.
645	645
646	646		### Peer support
647	647
648	648		Mailing lists
649	649
650	650		You can post a question on any of the [mailing lists for the Free Pascal Compiler](http://www.freepascal.org/maillist.html) or the [FPC/Lazarus forums](http://forum.lazarus.freepascal.org/index.php?action=forum) where a lot of experts are subscribed.
651	651
652	652		If you have access to IRC:
653	653
654	654		On irc.freenode.net: [\#fpc](irc://irc.freenode.net/fpc) for FPC, or [\#lazarus-ide](irc://irc.freenode.net/lazarus-ide) for Lazarus
655	655
656	656		### Knowledge bases
657	657
658	658		There are some outstanding search and knowledge bases online that can also be a great help for learning new techniques and solving problems:
659	659
660	660		- Tamarack Associates operates a fast \[ <http://codenewsfast.com/> search\] engine specifically for the Borland usenet archives.
661	661		- Mer Systems Inc. provides a similar search [engine](http://www.mers.com/searchsite.html).
662	662		- Another outstanding source of information along with a sitewide [search](http://www.efg2.com/Lab/search.htm) capability is Earl F. Glynn's Computer Lab and Reference [Library](http://www.efg2.com/).
663	663
664	664		## Packaging and Releasing your component
665	665
666	666		### Creating a Lazarus package for your component(s)
667	667
668	668		Creating a package makes installing the code you've converted a much easier process... especially if you're providing more than one component. Mattias Gärtner has written an overview of [[Lazarus Packages]] that should be read before beginning this process.
669	669
670	670		### Documentation
671	671
672	672		The purpose of this site and the wiki format is to make the generation of professional documentation an easy and quick process. The wiki also makes it possible to see the results of your posting immediately and make any changes you'd like in real time.
673	673
674	674		Using the Lazarus-CCR wiki to create nice looking documentation is very easy. If you've never used wiki markup before, you can get familiar with it in the [[Sand Box]] practice area.
675	675
676	676		### Creating a Code Release Page
677	677
678	678		The Code Release Page contains vital information about your component that a potential downloader will need to know, such as license, intended platform, status (alpha, beta, stable...), where to download it, who wrote it, is support available... etc.
679	679
680	680		The following procedure will let you create a Code Release Page with your browser:
681	681
682	682		- Go to the [[Release new component]]
683	683		- Type the name of your component in the textbox and click on Create Article
684	684		- Fill in the template and hit save.
685	685		- Edit the [[Components and Code examples]] page and add the link to your newly created page to the "Released Components" section. Save the modified page.
686	686
687	687		### Submitting the component
688	688
689	689		If you're a release technician on the project, upload your component to the SourceForge File Release System and add it to the list of release packages. Otherwise send it to one of the project administrators (Tom Lisjac or Vincent Snijders) and we'll add it to the repository. Before we upload it to SourceForge, you have to create a Code Release Page to describe your component. You can use the [[Release new component]] page, to start creating such a page.
690	690
691	691		If you think you need to continue to develop on the component, we can also put it into SVN so you'll continue to have access to it. If we get tired from committing your patches, we will give you write access to the SVN, so you can commit your patches yourself. For details see [[Using the Lazarus-ccr SVN repository]].
692	692
693	693		## See also
694	694
695	695		- [[Lazarus For Delphi Users]]
696	696		- [[Delphi language features missing from the Free Pascal Compiler]]
697	697
698	698		---
699	699		From the Free Pascal wiki, page "Code Conversion Guide", as it stood on 2023-11-06 after a change by Bart, 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