Object Pascal is a high-level, compiled, strongly typed language that supports structured and object-oriented design. Its benefits include easy-to-read code, quick compilation, and the use of multiple unit files for modular programming.

Object Pascal has special features that support Borland's component framework and RAD environment. For the most part, descriptions and examples in this manual assume that you are using Object Pascal to develop applications using Borland development tools such as Delphi or Kylix.

Program organization

Programs are usually divided into source-code modules called units. Each program begins with a heading, which specifies a name for the program. The 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, Object Pascal programs do not require makefiles, header files, or preprocessor "include" directives. (The Project Manager generates a makefile each time a project is loaded in the IDE, but saves these files only for project groups that include more than one project.)

For further discussion of program structure and dependencies, see Chapter 3, "Programs and units".

Pascal source files

The compiler expects to find Pascal 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)

Unit source files contain most of the code in an application. Each application has a single project file and several unit files; the project file—which corresponds to the "main" program file in traditional Pascal—organizes the unit files into an application. Borland development tools automatically maintain a project file for each application.

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

Package source files are similar to project files, but they are used to construct special dynamically linkable libraries called packages. For more information about packages, see Chapter 9, "Libraries and packages".

Other files used to build applications

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

  • form files, which end with the .dfm (Delphi) or .xfm (Kylix) extension,
  • resource files, which end with the .res extension, and
  • project options files, which end with the .dof (Delphi) or .kof (Kylix) extension.

A form file is either a text file or a compiled resource file that can contain bitmaps, strings, and so forth. Each form file represents a single form, which usually corresponds to a window or dialog box in an application. The IDE allows you to view and edit form files as text, and to save form files as either text or binary. Although the default behavior is to save form files as text, they are usually not edited manually; it is more common to use Borland's visual design tools for this purpose. Each project has at least one form, and each form has an associated unit (.pas) file that, by default, has the same name as the form file.

In addition to form files, each project uses a resource (.res) file to hold the bitmap for the application's icon. By default, this file has the same name as the project (.dpr) file. To change an application's icon, use the Project Options dialog.

A project options (.dof or .kof) file contains compiler and linker settings, search directories, 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 or .desk) 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.

Compiler-generated files

The first time you build an application or a standard dynamic-link library, the compiler produces a compiled unit .dcu (Windows) .dcu/.dpu (Linux) file for each new unit used in your project; all the .dcu (Windows) .dcu/.dpu (Linux) files in your project are then linked to create a single executable or shared library file. The first time you build a package, the compiler produces a .dcu (Windows) .dpu (Linux) file for each new unit contained in the package, and then creates both a .dcp and a package file. (For more information about libraries and packages, see Chapter 9.) 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 rebuild a project, individual units are not recompiled unless their source (.pas) files have changed since the last compilation, or their .dcu (Windows) .dcu/ .dpu (Linux) files cannot be found, or you explicitly tell the compiler to reprocess them. 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.

Example programs

The examples that follow illustrate basic features of Object Pascal programming. The examples show simple Object Pascal applications that cannot be compiled from the IDE; but you can compile them from the command line.

A simple console application

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

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. (Object Pascal 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

On Delphi: DCC32 Greeting

On Kylix: dcc Greeting on the command line. 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 Borland development tools. First, it is a console application. Borland development tools are typically 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 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 methods defined in unit files.

A more complicated example

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 Unitl; begin

PrintMessage('Hello World!'); end.

The first line declares a program called Greeting, which, once again, is a console application. The uses Unitl; clause tells the compiler that Greeting includes a unit called Unit1. Finally, the program calls the PrintMessage procedure, passing to it the string "Hello World!" Where does the PrintMessage procedure come from? It's defined in Unit1. Here's the source code for Unit1, which you can save in a file called Unitl.pas:

unit Unitl; interface procedure PrintMessage(msg: string); implementation procedure PrintMessage(msg: string); begin

Writeln(msg); end;


Unit1 defines a procedure called PrintMessage that takes a single string as an argument and sends the string to the standard output. (In Pascal, 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

On Delphi: DCC32 Greeting On Kylix: dcc Greeting

There's 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!"

A native application

Our next example is an application built using VCL or CLX 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 Object Pascal. In addition to multiple units, the program uses classes and objects, which are discussed in Chapter 7, "Classes and objects".

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

program Greeting; { comments are enclosed in braces }


Forms, {change the unit name to QForms on Linux} Unitl in 'Unitl.pas' { the unit for Forml }, Unit2 in 'Unit2.pas' { the unit for Form2 };

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


{ calls to Application } Application.Initialize; Application.CreateForm(TForm1, Forml); Application.CreateForm(TForm2, Form2); Application.Run; end.

Once again, our program is called Greeting. It uses three units: Forms, which is part of VCL and CLX; 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 Unitl; interface uses { these units are part of the Visual Component Library (VCL) } Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;

On Linux, the uses clause looks like this: uses { these units are part of CLX } SysUtils, Types, Classes, QGraphics, QControls, QForms, QDialogs;


TForml = class(TForm) Buttonl: TButton;

procedure Button1Click(Sender: TObject); end;

Forml: TForml; implementation uses Unit2; { this is where Form2 is defined }

{$R *.dfm} { this directive links Unitl's form file }

procedure TForm1.Button1Click(Sender: TObject); begin

Form2.ShowModal; end;


Unit1 creates a class named TForm1 (derived from TForm) and an instance of this class, Form1. TForm1 includes a button—Button1, an instance of TButton—and a procedure named TForm1.Button1Click that is called at runtime whenever the user presses Button1. TForm1.Button1Click hides Form1 and it displays Form2 (the call to Form2.ShowModal). Form2 is defined in Unit2:

unit Unit2;

interface uses

Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls;

On Linux, the uses clause looks like this: uses { these units are part of CLX } SysUtils, Types, Classes, QGraphics, QControls, QForms, QDialogs;


TForm2 = class(TForm) Labell: TLabel; CancelButton: TButton;

procedure CancelButtonClick(Sender: TObject); procedure FormClose(Sender: TObject; var Action: TCloseAction); end;

Form2: TForm2; implementation uses Unitl; {$R *.dfm}

procedure TForm2.CancelButtonClick(Sender: TObject); begin

Form2.Close; 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 (Labell, an instance of TLabel). You can't see this from the source code, but Labell displays a caption that reads "Hello world!" The caption is defined in Form2's form file, Unit2.dfm.

Unit2 defines one procedure. TForm2.CancelButtonClick is called at runtime whenever the user presses CancelButton; it closes Form2. This procedure (along with Unitl's TForml.ButtonlClick) is known as 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 (.dfm on Windows .xfm on Linux) files for Forml and Form2.

When the Greeting program starts, Forml 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 Forml, Forml disappears and is replaced by Form2, which displays the "Hello world!" greeting. When the user closes Form2 (by pressing CancelButton or the Close button on the title bar), Forml reappears.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment