When Kylix was introduced, a new library name was used: CLX (Component Library for X-platform), which divided the components in BaseCLX, DataCLX, VisualCLX, and NetCLX. Using Delphi 6 and 7, we can build visual applications using CLX (VisualCLX is cross-platform for Linux and Win32) or VCL (only on Win32).
Now that Delphi has been ported to the Microsoft .NET Framework, the VCL has been ported to .NET as well. This means that we can not only use native Windows Forms to produce .NET applications with Delphi for .NET, but also VCL for .NET to produce .NET applications. Because VCL for .NET uses the same classes and property/events interfaces that the VCL for Win32 uses, Delphi Win32 projects can be migrated to Delphi for .NET with considerable ease, which will be demonstrated in this paper).
CLX, VCL, and VCL for .NET are similar in terms of class names, property/event names, and their usage. They all use an external stream file to place the property and event assignments: for CLX an .xfm file, for VCL a .dfm file, and for VCL for .NET an .nfm file. In contrast, the Windows Forms projects do not rely on a .nfm file, but assign all property and event handler values in source code (hence the need for code folding in the IDE).
The VCL can be seen as a wrapper around the Win32 API, and the VCL for .NET can be seen as a wrapper around the .NET Framework (or more specifically the Windows Forms classes). The move from VCL to VCL for .NET is fairly painless and involves far less work than the move from the Win32 API to the .NET Framework with Windows Forms. And the future move to Longhorn's XAML (for the new Avalon presentation layer) will also be easier when using VCL than when bound to a native layer such as the Win32 API or Windows Forms. In short, using VCL extends the lifetime of your code.
For more information about VCL, CLX, and Windows Forms, see John Kaster's article at the Borland Developer Network at http://bdnborland.com/article/0,1410,29460,00.html .
Delphi™ 7 language and RTL not available in Delphi™ for Microsoft® .NET
Although the move from VCL to VCL for .NET is fairly painless, several migration issues are related to the differences in the Win32 and .NET platforms. These issues are related to the fact that .NET code is executed by the CLR in a safe, managed way, so all potentially unsafe
Was this article helpful?