Delphi Interface, implementation, uses and other keywords explained in easy language!

The UNIT keyword
A unit file begins with a unit heading, which is followed by the interface, implementation, initialization, and finalization sections. The initialization and finalization sections are optional.

The unit heading starts with a word unit (line 01), followed by a unit (file) name. The unit name (Unit1 in the above source) must match the unit file name on a disk. In a single project all unit names must be unique. You should change the unit's name only by using the File-Save As command from the Delphi IDE main menu. Of course, it is completely up to you to decide how will you name your units. In most cases you'll want your units to have the name similar to the name of the form to which they are linked, like 'MainUnit' for Main form (form with a Name property set to 'Main'). Be sure to give name to units in the early stage of a form design development.

The INTERFACE section
The interface section of a unit starts with the word interface (line 02) and continues until the word implementation (line 17). This section is used to declare any public sections of code that appear in a unit. The entire contents of the interface section, including type, variable and procedure declarations, are visible to any other unit which uses this unit. When any other part of the program looks at a unit, all it sees is the interface section. Everything else is hidden, internal to the unit, part of the implementation. You could say that the interface section contains a list of items in the unit that other units can use.

In most cases the interface section will define several "subsections", you can see that the code for unit1.pas has a uses clause, a type section, and a variable declaration section.

The INTERFACE USES section
If the interface section includes a uses clause, it must appear immediately after the word interface. A uses clause (line 03) lists units used by the unit. In most cases, all necessary units are placed in the interface uses clause when Delphi compiler generates and maintains a units source. The Windows, Messages, SysUtils, etc are all standard Delphi units, required by a program.

As you drop components on a form, the necessary units will be added automatically to the uses clause. For example, if you add a TOpenDialog component on your form (Dialogs page on the component palette), the Dialogs unit will appear in the uses clause because it contains the logic for the TOpenDialog component (and other Dialog components).

In some situations, you'll need to manually add units to interface uses clause. Suppose you are to use the TRegistry object, designed to access the Windows Registry. You cannot drop the TRegistry component on a form, since it does not appear on the component palette - you must manually add the word Registry to the uses list.

The INTERFACE TYPE section
Another part of the interface section is the type section. The form type declaration (or form class declaration) section introduces the form as a class. The code from line 04 to 14 declares the existence and structure of a class called TForm1.

 

A few words on classes and objects
I'm aware that this is not the place to explain OOP in Delphi, but I sense that something must be stated. The basics of object oriented programming in Delphi will be discussed in the next chapter of this course, however some words must be explained now.
A class, or class type, defines a structure consisting of fields, methods, and properties. Instances of a class type are called objects.
For example, in real world, a class PROGRAMMER can have properties like: Years_Of_Experience and Projects_Developed. It can expose methods like: Write_Program and Talk_To_Users. A class is something that does not truly exists. An object: DELPHI PROGRAMMER is a specific instance of a class.

The TForm1 is a class inherited from TForm (line 05).

Each component dropped on a form becomes a field (or variable) of the TForm1 class (lines 06 through 08). For example, Edit1 is a variable of a TEdit type, which you see on the screen when you run the program. When you need to read a value from this particular edit box you use the Edit1 variable, like in 's := Edit1.Text'.

Each event handling procedure for a form events or events for components dropped on a form (form fields) will have its declaration (line 09) in the interface type part.

For an explanation on private and public parts (lines 10 through 14) of a class declaration, please refer to Hiding Data, a part of the Creating Custom Delphi Components - Inside and Out article.

The INTERFACE VAR section
This part (line 15,16) of the interface section is used to declare (create) a Form1 object as an instance of the TForm1 class. If you have created your own data type (with fields, properties and methods) as a part of this unit, you could create a variable of that type in this part of the interface section.

The IMPLEMENTATION section
The implementation section is defined as everything between the implementation word and either the initialization statement or the end of the file (as denoted by the end. keyword).
The implementation is where you write code that performs actions. This section is private to the unit, and can contain both declarations and code. The implementation section of a unit can contain its own uses clause as well.

 

A few words on using another unit (form)
As you will see in the following chapters of this course, a (form) unit can use another unit. Simply put, this means that one form can call another form. Suppose you have a main form (form name: MainForm, unit name: MainFormUnit) in a project with an 'About...' button on it. What you want to do is to show an about box form (form name: AboutForm, unit name: AboutFormUnit) when you click on this button. To be able to do this the MainFormUnit must use the AboutFormUnit, the AboutFormUnit should be placed in the implementation uses clause.
To actually call a method (procedure or function) from MainFormUnit that is declared in the AboutFormUnit, you use the following syntax:
AboutFormUnit.SomeProcedureName(parameters)

Note that the call to a procedure SomeProcedureName consists of a unit name (AboutFormUnit) followed by a period (.) and a procedure name. This fact is very important. If in some stage of the development of your project you decide to save AboutFormUnit under a different name - you will need to change the call to any procedure inside that unit, since the name of the unit will no longer be AboutFormUnit. This is the reason why you should give meaningful name to units in the early stage of form (unit) development.

Anything that appears in a unit's implementation section that is not referenced in the interface is private to that unit. This means that a procedure or function declared and defined (implemented) in the implementation section cannot be called from another unit unless its header is listed in that unit's interface.

The INITIALIZATION and FINALIZATION sections
These two sections are optional; they are not automatically generated when we create a unit. If we want to initialize any data the unit uses, we can add an initialization code to the initialization section of the unit. When an application uses a unit, the code within the unit's initialization part is called before the any other application code runs.

If your unit needs to perform any cleanup when the application terminates, such as freeing any resources allocated in the initialization part; you can add a finalization section to your unit. The finalization section comes after the initialization section, but before the final end.

Other units of a Delphi project
Now, when you have learned about the structure of a Delphi form unit, it's time to see what other units can appear in a project. Every Delphi program has at least two main parts. The first is a project file such as Project1.dpr. You can see the structure of the project file by pointing you mouse to Project|View Source from the Delphi main menu. The second part is one (or more) units attached to forms - the structure of such a unit is discussed through this article. However, units don't have to be associated with forms. A Code Unit contains code that is called from other units in the project. When you start building libraries of useful routines, you will probably store them in a code unit. To add a new code unit to Delphi application choose File-New ... Unit. The structure of a code unit is similar to form unit, it only lacks the type declaration for the "linked" TForm class.

Looking in the past: Code Explorer

In the second chapter of this course you have learned the main parts of the Delphi IDE. When we were discussing the Code Editor window, one part of that window was left unexplained - the Code Explorer. By default, the Code Explorer is docked to the left of the Code editor.

The Code Explorer makes it easy to navigate through your unit source. The Code Explorer contains a tree diagram that shows all the types, classes, properties, methods, global variables, and global routines defined in your unit. It also shows the other units listed in the uses clause.

I use the Code explorer to quickly jump to a procedure or type declaration by simply double-clicking on an item name, like Button1Click.