Chapter 7:Porting Delphi components
When you need to port a Delphi application to Lazarus, you will often encounterthe need to port not only Delphi VCL components but a variety ofthird-partyDelphi components, all ofwhich have to be converted to work under Lazarus in across-platform way. For most non-visual components, the conversion work required is not very complicated. However, when you port visual componentsfrom a Windows-only development environment (Delphi) to the new platformsaccessible through Lazarus you will have to undertake considerably more work, particularly for visual components that make direct calls to the Windows API(as most Delphi visual components do). All those calls to the Windows API in thecode you encounter will have to be replaced with platform-independentequivalents. To do that, you have to know how Lazarus components are built.
7.1 The Architecture of Lazarus Components
The LCL offers many components, with very different capabilities. You can use these todevelop applications quickly and easily. In addition to the components shipped withLazarus, there are many third-party components available which extend thefunctionalities ofthe basic Lazarus components. This chapter explains the basic building blocks ofthe LCL, and gives an overview ofthe whole process ofdeveloping customcomponents. This knowledge should make it possible for you to understand how to portthird-party components to Lazarus successfully. The LCL is based on two sets ofhierarchical class trees, which are tightly coupled toeach other. One ofthese sets ofclasses is the platform-independent part–thecomponents on the component palette (such asbelong to this set, and this set isDelphi compatible. The second set ofclasses is the so-called widget-set or,more precisely, the Lazarus interface to the native widget-set. A widget-set is a nativelibrary, for example GTK on Linux, or the WinAPI on Windows. The interface betweenthe platform-independent LCL (, for example) to the GTK native button(called gtk_button) is called the LCL interface.Each LCL interface is named after the underlying widget-set to which it binds.For this reason, the concepts ofthe widget-set and the LCL interface are often used assynonyms.Not all LCL components have a counterpart in the widget-set, and often customcomponents are simply build on top ofthe platform-independent part ofthe LCL.Consequently the platform-independent part will be described first. The relation between the various classes is depicted in Figure 7.1. The various parts ofa Lazarus application are shown. The arrows indicate for each part with which other parts it communicates. The as can be seen, only the LCL Classescommunicate with the widget-set classes. This means that the widget set classes can bereplaced with another widget set, and the application will function without any codechanges.
by Michael Van Canneyt and Mattias Gärtner
Lazarus - the complete guide