Delphi 6 Tutorials (Chapter 5)

[_I_Play_Chess]

Chapter 5 Page 1 of 2

Understanding the Delphi unit source

Page 1: Delphi Unit source code
----------------------------------------
Welcome to the fifth chapter of the FREE online programming course:
A Beginner’s Guide to Delphi Programming.
Take a closer look at exactly what each keyword means by examining each line of the Delphi form unit source code. Interface, implementation, uses and other keywords explained in easy language!

Understanding the unit source
In the previous chapter you have created your second simple Delphi application without going into details about the Delphi Pascal keywords that appear in each Delphi unit. This time, our task is to take a look at exactly what each keyword means by examining each line of the forms unit source code.

As you know already by now, forms are visible building blocks of all (well, at least 99%) Delphi projects. Each form in a Delphi project has an associated unit. The unit contains the source code for any event handlers attached to the events of the form or the components it contains.

The best way to describe the unit code is to take a look at the source. For the moment refer to the example in the last chapter, especially the unit source. After we have placed a Label, an Edit box and a Button, and added an OnClick event handling procedure for the button, the source code looked like:
-----------------------------------------
// Code writen in BLACK:
01: unit Unit1;

02: interface

03: uses
03: Windows, Messages, SysUtils, Variants, Classes,
03: Graphics, Controls, Forms, Dialogs, StdCtrls;

04: type
05: TForm1 = class(TForm)
//Here the code is writen in GREEN:
06: Edit1: TEdit;
07: Button1: TButton;
08: Label1: TLabel;
09: procedure Button1Click(Sender: TObject);
//Code writen in Black and BLUE:
10: private
11: ** Private declarations }
12: public
13: ** Public declarations }
14: end;

15: var
16: Form1: TForm1;

17: implementation
18: **$R *.dfm}
// Code writen in GREEN:
19: procedure TForm1.Button1Click(Sender: TObject);
// Code writen in RED:
20: var s: string;
//Code in GREEN:
21: begin
// Code writen in RED:
22: s := 'Hello ' + Edit1.Text + ' Delphi welcomes you!';
23: ShowMessage(s);
//Code in GREEN:
24: end;
//In Black;
25: end.

----------------------------------------
We'll now explore and try to figure what each line stands for. First, a note: Delphi units follow a predefined format. For example, the UNIT keyword must be the first line in the source, followed by INTERFACE... This strict format is "predefined" by Delphi, meaning that when you add an empty form to a project, its associated unit source is already created with special keywords and type declaration. When you add a component on a form and write an event handler for it, Delphi will place the corresponding code at the exact location in the unit file.

Note another thing: in the above code, "BLACK" lines appear in the forms unit source the first time you add a form to a project. Lines colored in "GREEN" were added by Delphi when you have placed those three components on a form. Lines in "RED" were added by you in the previous chapter. Whenever you create a new form, Delphi creates the corresponding unit file with the skeleton code marked "BLACK".

The rest of the article will discuss parts of the unit source. Several new words like class, object and similar will be mentioned, do not get frightened if you do not understand what they mean, let's just say that such words are a part of Delphi object oriented programming, we will discuss them in the following chapters more clearly.

[_I_Play_Chess]

Understanding the Delphi unit source

Page 2: 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(coming up in Chapter 8).

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.

To the next chapter: A Beginner's Guide to Delphi Programming
This is the end of the fifth chapter, in the next chapter, you'll learn about the Delphi Pascal - the language of Delphi.

[_I_Play_Chess]

How you like this Chapter?

Any discussion in here?

[_I_Play_Chess]

I meant very INTERESTING .

[r1chard_cran1um]

lesson 5

[_I_Play_Chess]

Nice! One.


Une Bonne!