What's left of Delphi in Delphi 8?

Problem/Question/Abstract:

What's new in Delphi 8 and what do developers have to consider when migrating from Delphi 7 (or lower) to Delphi 8 (.NET)?

Answer:

The IDE itself differs a lot from previous Delphi versions and looks a bit like Visual Studio .NET. Although the menus have not changed and all "old" shortcuts work, the Object Inspector, the Project Manager and the Component Palette and even the design of the Help did change a lot.

There are two possibilities to create applications with Delphi 8 - VCL Forms Applications and Win Forms Applications. Both create IML (intermediate language code) and are .NET Applications, which means that they can only be deployed on a computer with the .NET framework installed.

VCL Forms Applications

A VCL Forms Applications have - at a first glance - most in common with a normal Delphi application. You will find known VCL components and the structure of your units is very familiar. Borland tries to hide the .NET framework from the programmer as far as it is possible.

The first (visual) point you come across is the References-Node in the Project Manager. It contains the dependencies of your application from existing .NET components.  In an empty project they are by default: System.Data.dll, System.dll,
System.Drawing.dll and System.XML.dll. As soon as you drag a component (e.g. a button) to your form the following references will be added to your project: Borland.Delphi.dll, Borland.Vcl.dll and Borland VclRtl.dll.

This is the first point you come in contact with the .NET framework and its dogma of namespaces. The unit concept of Delphi is represented by the namespace concept of the .NET framework. In Delphi each class is referenced by its file (unit) – in the .NET environment each class is identified by its namespace (a unique string divided by dots). Therefore the dlls are named e.g. Borland.Vcl.dll, which means that from now on dots are allowed in unit names: e.g. unit Borland.Vcl.Forms.

To be able to work with the "old" VCL components Borland moved them (partially) to the .NET framework, wich means that the VCL components are based on pure .NET components (e.g. TPersistent = System.MarshalByRefObject, TObject = System.Object or Exception = System.Exception) whenever it was possible - in all other cases they included Win32 API calls (unmanaged code in the eyes of .NET). But that also means that your VCL applications are platform dependent while pure .NET Applications are not (theoretically).

The next difference is that forms are no longer saved in a .dfm file. In VCL Applications the file has the extension .nfm, in Winforms Applications there is no file - the code for generating the form is within the unit file.

Win Forms Applications

The structure of your units within Win Forms Applications is quite different from those in VCL Forms Applications. The differences start in the uses-clause, where .NET components (namespaces) are referenced. All .NET components start with the namespace System.* whereas namespaces of the Borland VCL components begin with Borland.*.

uses
System.Drawing, System.Collections, System.ComponentModel,
System.Windows.Forms, System.Data;

Additionally there are code segments that are under the control of the form designer, because all information for the design is within the unit (no more in an extra .pas file).
In the type definition:

type
TWinForm = class(System.Windows.Forms.Form)
{$REGION 'Designer controlled code:'}
strict private
Components: System.ComponentModel.Container;
procedure InitializeComponent;
{$ENDREGION}
strict protected
procedure Dispose(Disposing: Boolean); override;
private
{ Private-Deklarationen }
public
constructor Create;
end;

The procedure InitializeComponent holds all information about the visual design of the form. This procedure is called in the constructor of the unit.

procedure TWinForm.InitializeComponent;
begin
Self.Components := System.ComponentModel.Container.Create;
Self.Size := System.Drawing.Size.Create(300, 300);
Self.Text := 'WinForm';
end;

constructor TWinForm.Create;
begin
inherited Create;
InitializeComponent;
//
// TODO: Add own constructor code after the call of InitializeComponent.
//
end;

The .NET framework "renamed" the destructor to Dispose, and there is also code added automatically by the designer to this procedure.

procedure TWinForm.Dispose(Disposing: Boolean);
begin
if Disposing then
begin
if Components <> nil then
Components.Dispose();
end;
inherited Dispose(Disposing);
end;

Examples for differences between VCL Forms Applications and Win Forms Applications

In Win Forms Applications you might have different components from these in VCL Forms Applications. But the differences are quite small because the designer of the .NET framework components and the designer of the VCL components is the same person. Learning how to use the .NET framework merely means learning how to use the components and their properties and events - and that&#8217;s not
very difficult for a Delphi programmer.

E.g. difference of TButton (VCL component) and Button (.NET component)

Button1: TButton;
Button1.Caption := 'Hello World';

Button1: System.Windows.Forms.Button;
Button1.Text := 'Hello World';

An other benefit of Win Forms Applications is that you can have multipe event handlers for one event. The default (designed) event handler is created in the procedure InitializeComponents e.g.:

Self.Button1.Location := System.Drawing.Point.Create(104, 72);
{  ... }
Include(Self.Button1.Click, Self.Button1_Click);

But you can add even more components by calling the Include procedure like:

Include(Button1.Click, Self.MyButtonClick);

The same procedure (Include) is available in VCL Forms Applications, too, but the event handler called with the last Include call is always executed.

General Differences

Migrating from Delphi to the .NET Framework means to lose control over the object lifecycle (the .NET Framework has a garbage collector) and the code execution (you create intermediate language which is compiled at runtime with the JIT). But on the other hand you get new benefits/new features from the .NET Framework itself and you work with the latest Windows technology (the next Windows OS - Longhorn - will be totally based on .NET) - and all Delphi programmers build Windows applications. In my opinion these benefits only take effect if you build Win Forms Application.

Theoretically with VCL Forms Applications it is possible to move existing Delphi applications to the .NET Framework. I don't think that this will work for most applications, for I don't think that there are many applications built with the common Delphi VCL components

Looking at Win Forms components the .NET Framework shows its details. To develop such applications you have to learn using the framework - which is easy for a Delphi programmer - and a few new techniques (e.g. multiple event handlers). You keep your favorite programming language and additional Borland components (microsoft independent data providers e.g. for Interbase or DB2).

Additionally Borland integrated UML support for designing classes named ECO (BoldSoft under Delphi 7). The components for ECO give you the possibility to treat your objects like relational data - e.g. displaying properties of all instances of a class in a grid.

Conclusion

To answer the heading question of this article "What's left of Delphi in Delphi 8?" we must look differently at VCL Applications and Win Forms Applications. With VCL Applications Borland tried to make the move from traditional Windows programming to .NET programming as easy as possible for the developer in providing many known and common components, techniques and structures. So, looking at VCL Forms Applications, I would say that Delphi 8 has much in common with Delphi - on the surface.

Whats left overall is the programming language (object Pascal) and its whole structure, a "microsoft-independent" product and Borland&#8217;s aim of building and providing a wide range of components (like ECO, Component One or providers for other databases).