Programs and units

Units in Delphi applications, or program modules, are well-developed. In fact, a unit is the basis of program modularization, and a class is available only after it. In a Delphi application, each form has a corresponding unit. Use the corresponding tool button or File> New Form menu command to add a New Form to the project. In fact, a New unit is added, that is, the class of the New Form is created.

Unit

Although all forms are defined in cells, the opposite is true. In addition to forms, a unit can also define a series of accessible routines. Select the File> New menu command, and select the Unit icon in the New page of Object Repository. A blank Unit is added to the current project. Unit code partition storage. The code for the blank unit is as follows:

unit Unit1;interfaceimplementationend.

The concept of a unit is relatively simple. The unit name must be the same as the file name and must be unique. A unit includes an interface and an implementation area. The interface area is used to declare what other units can see. The implementation code of the implementation area storage interface and the externally invisible Declaration are implemented. There are also two optional zones, namely the initialization zone and the end zone. The initialization zone stores the initialization code, which is executed when the program is loaded into the memory; and the end zone stores the code executed when the program is terminated.

The overall unit structure is as follows:

unit unitName;interface// other units we need to refer touses  A, B, C;// exported type definitiontype  newType = TypeDefinition;// exported constantsconst  Zero = 0;// global variablesvar  Total: Integer;// list of exported functions and proceduresprocedure MyProc;implementationuses  D, E;// hidden global variablevar  PartialTotal: Integer;// all the exported functions must be codedprocedure MyProc;begin  // ... code of procedure MyProcend;initialization  // optional initialization partfinalization  // optional clean-up codeend.

The uses clause in the interface area header represents the external units to be accessed. These external units define the data types you need to reference, such as the controls used in the custom form.

The uses clause in the implementation area header is used to indicate the units that only implement partial access. If the code of the routine or method needs to reference other units, you should add these units to the implementation area clause, rather than the interface area. The units you reference must be found in the project file directory or set the search path for these units on the Directories/Conditionals page of the Project Options dialog box.

C ++ programmers should know that the uses statements and include commands are different. The uses statement is only used to input the pre-compiled Interface part of the referenced unit. The implementation part of the referenced unit is considered during unit compilation. The referenced unit can be the source code format (PAS) or the compilation format (DCU), but it must be compiled using the same version of Delphi.

You can declare many different elements in the Unit Interface Area, including processes, functions, full variables, and data types. In Delphi applications, data types may be used most frequently. Every time you create a form, Delphi automatically creates a new data type-class in the unit ). In a Delphi unit, you can not only define a form, but also include only processes and functions like a traditional unit. You can also define classes irrelevant to the form and any visual controls.

Unit Workspace

The Pascal unit is the key to encapsulation and visibility. It is likely to be more important than the private and public keywords in the class. (In fact, the private keyword is related to the workspace of the class unit ). A workspace with an identifier (such as a variable, process, function, or data type) refers to a code segment that can access the identifier. The basic principle is that identifiers make sense in their workspace, that is, they only make sense in their declared code blocks. You cannot access these identifiers outside the workspace. For example:

• Local variable: If you declare a variable in a routine or method code block, the variable cannot be accessed outside the unit. The workspace of the identifier is the entire routine that defines the identifier, including the nested routine (unless an identifier of the same name in the nested routine overwrites the external definition ). When a routine is called, its variables are pushed into the stack memory. When the routine ends, the memory in the stack is automatically released.

   

• Hide variables throughout the process: If you declare an identifier in the implementation part of a unit, you cannot use it outside the unit, but you can use it in any code block or process in the unit. When the program starts, it will allocate memory for hidden variables throughout the process. When the program stops memory release, you can assign initial values to it in the unit initialization area.

   

• Full variable: If you declare an identifier in the unit interface, the workspace of the identifier will be extended and can be accessed by any unit that uses it. The memory allocation and lifecycle of these variables are the same as those of the previous variables. The only difference is their visibility.

   

As long as a unit name is listed in the uses clause of a program unit, any identifier declared in the Unit Interface area listed in the program can be accessed. The Form class variables are declared in this way, so you can access the form and its public fields, methods, attributes, and components in other form code. Of course, the programming habit of declaring everything as a global identifier is not good. In addition to obvious memory consumption problems, using full-process variables makes code maintenance and update difficult. In a word, you should try to use as few full variables as possible.

A unit is used as a namespace.

A uses statement is a standard technology used to access other unit workspaces. With this statement, you can access the definition content of other units. If the identifiers declared by two units have the same name, that is to say, you may have two classes or routines with the same name. In this case, you can use the unit name as the prefix to define the type or process name. For example, use Totals. ComputeTotal to access the ComputeTotal process in the Totals unit. However, we recommend that you do not use the same name to indicate two different things in the same program.

However, if you look at the VCL library and Windows files, you will find that some Delphi functions and Windows API functions available in Delphi have the same name, but the parameters are often different. The following uses the Beep process as an example to illustrate this problem.

Create a New Delphi Program, add a button, and write the following code:

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

Execute the program, click the button, and you will hear a short speech. Now move to the uses statement of the unit and put the original code:

uses  Windows, Messages, SysUtils, Classes, ...

Change to the following style.SysUtilsUnit moveWindowsBefore:

uses  SysUtils, Windows, Messages, Classes, ...

If you re-compile the code, you will get a compilation error: "Not enough actual parameters" (the actual parameter is Not enough ). The problem is that the Windows Unit defines another Beep function with two parameters. The definition of the first unit in the uses clause is overwritten by the definition of the subsequent unit. The solution is simple:

procedure TForm1.Button1Click(Sender: TObject);begin  SysUtils.Beep;end;

The above code can be compiled regardless of the unit order in the uses clause. There are very few naming conflicts in Delphi, Because Delphi code is usually placed in class methods. If there are two methods with the same name in different classes, there will be no conflicts, however, a full-process routine may cause a conflict.

Units and programs

Delphi application source code files can be divided into one or more unit files and one program file. Unit files can be considered as level-1 files, it is referenced by the application entity-program file. In theory, in fact, a program file is usually automatically generated and has limited functions. It is used only when the program starts and runs the main form. The code of the program file, or the Delphi project file (DPR), can be edited manually or by using the project manager and its options related to applications and forms.

The structure of a program file is generally much simpler than that of a unit file. The source code of a program file is as follows:

program Project1;uses  Forms,  Unit1 in Unit1.PAS� {Form1DateForm};begin  Application.Initialize;  Application.CreateForm (TForm1, Form1);  Application.Run;end.

As shown in the preceding figure, there is only one uses zone in the file and the main code of the application. The main code contains the begin and end keywords. The uses clause of a program is particularly important because it is used to manage the compilation and connection of an application.

Conclusion

After discussing the structure of the Pascal application in Delphi, this book will go through the last chapter, at least for the moment. You are welcome to email your comments and requirements.

If you want to learn more about the object-oriented content in Delphi Object Pascal, you can refer to my published book "proficient in Delphi 5" (Mastering Delphi 5, Sybex, 1999). For details, visit the website.Http://www.marcocanto.com/You can also download the latest version from this website.