Delphi programs are usually divided into source-code modules called units. Most programs begin with a program heading, which specifies a name for the program. The program heading is followed by an optional uses clause, then a block of declarations and statements. The uses clause lists units that are linked into the program; these units, which can be shared by different programs, often have uses clauses of their own. 

The uses clause provides the compiler with information about dependencies among modules. Because this information is stored in the modules themselves, most Delphi language programs do not require makefiles, header files, or preprocessor "include" directives.

The compiler expects to find Delphi source code in files of three kinds:

• Unit source files (which end with the .pas extension)
• Project files (which end with the .dpr extension)
• Package source files (which end with the .dpk extension)

If you are compiling a program from the command line, you can put all your source code into unit (.pas) files. If you use the IDE to build your application, it will produce a project (.dpr) file. 

Package source files are similar to project files, but they are used to construct special dynamically linkable libraries called packages.

In addition to source-code modules, CodeGear products use several non-Pascal files to build applications. These files are maintained automatically by the IDE, and include

• VCL form files (which have a .dfm extension on Win32
• Resource files (which end with .res)
• Project options files (which end with .dof )

In addition to VCL form files, each project uses a resource (.res) file to hold the application's icon and other resources such as strings. By default, this file has the same name as the project (.dpr) file. 

A project options (.dof) file contains compiler and linker settings, search path information, version information, and so forth. Each project has an associated project options file with the same name as the project (.dpr) file. Usually, the options in this file are set from Project Options dialog. 

Various tools in the IDE store data in files of other types. Desktop settings (.dsk) files contain information about the arrangement of windows and other configuration options; desktop settings can be project-specific or environment-wide. These files have no direct effect on compilation.

The first time you build an application or a package, the compiler produces a compiled unit file (.dcu on Win32) for each new unit used in your project; all the .dcu/.dcuil files in your project are then linked to create a single executable or shared package. The first time you build a package, the compiler produces a file for each new unit contained in the package, and then creates both a .dcp and a package file.If you use the GD switch, the linker generates a map file and a .drc file; the .drc file, which contains string resources, can be compiled into a resource file. 

When you build a project, individual units are not recompiled unless their source (.pas) files have changed since the last compilation, their .dcu/.dpu files cannot be found, you explicitly tell the compiler to reprocess them, or the interface of the unit depends on another unit which has been changed. In fact, it is not necessary for a unit's source file to be present at all, as long as the compiler can find the compiled unit file and that unit has no dependencies on other units that have changed.

The examples that follow illustrate basic features of Delphi programming. The examples show simple applications that would not normally be compiled from the IDE; you can compile them from the command line.

The program below is a simple console application that you can compile and run from the command prompt.

program Greeting;
                                                
{$APPTYPE CONSOLE}
    
var 
  MyMessage: string;

begin
  MyMessage := 'Hello world!';
  Writeln(MyMessage);
end.

The first line declares a program called Greeting. The {$APPTYPE CONSOLE} directive tells the compiler that this is a console application, to be run from the command line. The next line declares a variable called MyMessage, which holds a string. (Delphi has genuine string data types.) The program then assigns the string "Hello world!" to the variable MyMessage, and sends the contents of MyMessage to the standard output using the Writeln procedure. (Writeln is defined implicitly in the System unit, which the compiler automatically includes in every application.) 

You can type this program into a file called greeting.pas or greeting.dpr and compile it by entering 

dcc32 greeting 

to produce a Win32 executable. 

The resulting executable prints the message Hello world! 

Aside from its simplicity, this example differs in several important ways from programs that you are likely to write with CodeGear development tools. First, it is a console application. CodeGear development tools are most often used to write applications with graphical interfaces; hence, you would not ordinarily call Writeln. Moreover, the entire example program (save for Writeln) is in a single file. In a typical GUI application, the program heading the first line of the example would be placed in a separate project file that would not contain any of the actual application logic, other than a few calls to routines defined in unit files.

The next example shows a program that is divided into two files: a project file and a unit file. The project file, which you can save as greeting.dpr, looks like this:

program Greeting;
                                        
{$APPTYPE CONSOLE}
                                        
uses 
  Unit1;

        begin
          PrintMessage('Hello World!');
end.

The first line declares a program called greeting, which, once again, is a console application. The uses Unit1; clause tells the compiler that the program greeting depends on a unit called Unit1. Finally, the program calls the PrintMessage procedure, passing to it the string Hello World! The PrintMessage procedure is defined in Unit1. Here is the source code for Unit1, which must be saved in a file called Unit1.pas:

unit Unit1;
                    
interface

procedure PrintMessage(msg: string);

implementation

procedure PrintMessage(msg: string);
begin
   Writeln(msg);
end;

end.

Unit1 defines a procedure called PrintMessage that takes a single string as an argument and sends the string to the standard output. (In Delphi, routines that do not return a value are called procedures. Routines that return a value are called functions.) Notice that PrintMessage is declared twice in Unit1. The first declaration, under the reserved word interface, makes PrintMessage available to other modules (such as greeting) that use Unit1. The second declaration, under the reserved word implementation, actually defines PrintMessage. 

You can now compile Greeting from the command line by entering 

dcc32 greeting 

to produce a Win32 executable 

There is no need to include Unit1 as a command-line argument. When the compiler processes greeting.dpr, it automatically looks for unit files that the greeting program depends on. The resulting executable does the same thing as our first example: it prints the message Hello world!

Our next example is an application built using the Visual Component Library (VCL) components in the IDE. This program uses automatically generated form and resource files, so you won't be able to compile it from the source code alone. But it illustrates important features of the Delphi Language. In addition to multiple units, the program uses classes and objects 

The program includes a project file and two new unit files. First, the project file:

program Greeting;
                                        
        uses 
  Forms, Unit1, Unit2;

        {$R *.res} { This directive links the project's resource file. }

begin
   { Calls to global Application instance }
   Application.Initialize;
   Application.CreateForm(TForm1, Form1);
   Application.CreateForm(TForm2, Form2);
   Application.Run;
end.

Once again, our program is called greeting. It uses three units: Forms, which is part of VCL; Unit1, which is associated with the application's main form (Form1); and Unit2, which is associated with another form (Form2). 

The program makes a series of calls to an object named Application, which is an instance of the TApplication class defined in the Forms unit. (Every project has an automatically generated Application object.) Two of these calls invoke a TApplication method named CreateForm. The first call to CreateForm creates Form1, an instance of the TForm1 class defined in Unit1. The second call to CreateForm creates Form2, an instance of the TForm2 class defined in Unit2. 

Unit1 looks like this:  

unit Unit1;
        
interface

uses SysUtils, Types, Classes, Graphics, Controls, Forms, Dialogs;

type 

TForm1 = class(TForm)
  Button1: TButton;
  procedure Button1Click(Sender: TObject);
end;

var
  Form1: TForm1;

implementation

uses Unit2;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  Form2.ShowModal;
end;

end.

Unit1 creates a class named TForm1 (derived from TForm) and an instance of this class, Form1. TForm1 includes a buttonButton1, an instance of TButton and a procedure named Button1Click that is called when the user presses Button1. Button1Click hides Form1 and it displays Form2 (the call to Form2.ShowModal).

unit Unit2;
                    
interface

uses SysUtils, Types, Classes, Graphics, Controls, Forms, Dialogs;

type
TForm2 = class(TForm)
  Label1: TLabel;
  CancelButton: TButton;
  procedure CancelButtonClick(Sender: TObject);
end;

var
  Form2: TForm2;

implementation

uses Unit1;

{$R *.dfm}

procedure TForm2.CancelButtonClick(Sender: TObject);
begin
   Form2.Close;
end;

end.

Unit2 creates a class named TForm2 and an instance of this class, Form2. TForm2 includes a button (CancelButton, an instance of TButton) and a label (Label1, an instance of TLabel). You can't see this from the source code, but Label1 displays a caption that reads Hello world! The caption is defined in Form2's form file, Unit2.dfm. 

TForm2 declares and defines a method CancelButtonClick which will be invoked at runtime whenever the user presses CancelButton. This procedure (along with Unit1's TForm1.Button1Click) is called an event handler because it responds to events that occur while the program is running. Event handlers are assigned to specific events by the form files for Form1 and Form2. 

When the greeting program starts, Form1 is displayed and Form2 is invisible. (By default, only the first form created in the project file is visible at runtime. This is called the project's main form.) When the user presses the button on Form1, Form2, displays the Hello world! greeting. When the user presses the CancelButton or the Close button on the title bar, Form2 closes.

Programs and Units 

Using Namespaces with Delphi