Unit files

Delphi's Object Pascal language supports separately compiled modules of code called units. Using units promotes structured, reusable code across projects. The most common units in Delphi projects are form units, which contain the event handlers and other code for the forms used in Delphi projects. But units don't have to have forms associated with them. You can create and save a unit as a standalone file that any project can use. For example, you can write your own procedures, functions, DLLs, and components, and put their source code in a separate unit file that has no associated form.

If you open and save a default new project, the project directory initially contains one unit source-code file (unit1.pas) and its associated form file (unit1.dfm or unit1.xfm).

Caution: Do not add more than one form into a single unit file. The associated form file (.dfm or .xfm) can only describe a single form.

When you compile or run the project or perform a syntax check on the project, Delphi's compiler produces an intermediate output file on disk from each unit's source code. By default the compiled version of each unit is stored in a separate binary-format file with the same name as the unit file, but with the extension .dcu (Delphi compiled unit). You should never need to open these binary files, and you do not need to distribute them with the completed project. The compiled-unit format is specific to the Delphi compiler, and enables rapid compiling and linking.

Note: As an option, you can choose to have the compiler generate standard Intel object files (with the extension .obj) for greater compatibility with other compilers, but this greatly reduces the speed of compiling and linking your project. It should have no effect on the quality of the final generated code, however.

Unit files for forms

Most unit files you'll work with will probably be associated with forms. Whenever you create a new form, Delphi creates the corresponding unit file with the following code. The default unit identifier is incremented (Unit2, Unit3, and so on) for each new form.

unit Unit1; { unit identifier }

interface

uses { uses clause }

SysUtils, Windows, Messages, Classes, Graphics, Controls,

Forms, Dialogs;

type

TForm1 = class(TForm) { class declaration }

private

{ Private declarations }

public

{ Public declarations }

end;

var

Form1: TForm1; { instance declaration }

implementation

{$R *.DFM} { compiler directive to link form file }

end.

The type declaration (or class declaration) part introduces the form as a class. A class is simply an object, which you will recognize if you are familiar with previous versions of Borland Pascal products, or another object-oriented programming language.

The default type declaration makes the new form a descendant of the generic form class, TForm. This means it contains all the behaviors and characteristics of a TForm object.

The variable declaration declares your form as an instance of the class TForm1.

The $R compiler directive links the TForm's binary form file. This adds the form file(s) in your project to the compiled executable.

Caution: Do not remove the {$R *.dfm} or {$R *.xfm} directive from a form unit file. Doing so will result in code that will never work correctly.

Unit files for procedures and functions

You can write custom procedures or functions within a unit that's associated with a form. However, if you want to reuse the routines that you write, it's better to create a separate unit to contain those routines. By creating standalone units that have no associated forms, you can easily make your procedures and functions available to other projects.

To create a unit file not associated with a form:

Choose File|New|Unit.

It is not necessary to have a project open unless you want the new unit to be part of a project.

See Programs and units for more information about units. Units are also used when you create new components, as described in the online book called Creating custom components.