The six traps that Delphi beginners should be careful

Beginners of delphii, for a variety of reasons, many of the concepts in the delphii can not be well understood, and thus brought many problems, or the development of the program stability is not good, a will be able to run, a will not run; or encountered a problem for a long time without its solution, Also mistakenly thought is delphii own bug, and so on these, has wasted our massive time, the energy, also has affected our development efficiency.

So how can we avoid these mistakes, as little detours? The author engaged in Delphii development for many years, the following will be my experience to summarize the introduction to everyone, hope to help beginners delphii friends.

Problem one: The concept of the class is not in place, program development can not be flexibly used. Take a look at the following program:

unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, shellApi;
type
TForm1 = class(TForm)
Button1: TButton;
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form1: TForm1;
implementation
uses CommonUni;

When you create a new program in Delphii and then add a button, you get the following procedure. This should be quite familiar with a program, but also this procedure, so many people in the development of a long time, can not be very good understanding. The program can be divided into three parts: the first part, the cell header (before to type), the second part (from type to end), defines a form class inherited from Tform, which contains a member of the Tbuttton type. The last part (Var to the end of the section) defines a TFORM1 type of variable. The problem is here, and many people mistakenly think that this last paragraph is also part of the form class, which is often written in the form class, form1.caption = ' form title ', causing the program to run without the desired result. In fact, the last part is the definition of the form class, they are only in the same unit, so the code should write: self.caption = ' form title ';

Question two: Write the code that releases the object in the Close event of the form, causing access to violation ... of errors.

The closing (close) of a form and the destructor of the form (destory) are different in system processing, when a form is closed, the form is actually hidden, the resources it occupies are not freed from memory, and we can access the data in the form , and when the form responds to the Destory event, the form is not only hidden, but also the system resources that it occupies are released. So, if a form closes, we also want to visit the objects inside, and we should write the free code of these objects in the form (Destory) event.

Question three: Use string and shortstring data types indiscriminately.

The string type differs from the shortstring type, and, by default (depending on the $h switch), if you define a variable to be of type string, it is processed into a ansistring type. This type is dynamically allocated memory, ending with null, with a maximum length of 4G, while the maximum length of shortstring cannot exceed 255 characters. Because Ansistring is a life-time self-management type of data, which means that this type of data requires more overhead, so in program development, Shortstring can meet the requirements, try to use it to improve the speed of the program.

Problem four: When data type conversion is handled improperly, the most mistakes are the conversion of character type to digital/floating-point type.

When converting a character data to an integral type, we often write I: = Strtoint (Aedit.text); On the surface of this sentence, there is no problem, the use of functions, the format of the wording, are correct. There is one situation we have not considered, if the user in the Aedit text box input is not the number of text, what will happen? Will the call succeed again? Obviously not, the system will certainly pop up an English error, so that our users are overwhelmed. The correct wording is: I: = Strtointdef (aedit.text, 0); This way, when the conversion is unsuccessful, the second argument is assigned to I. Similar functions include strtoint64def,strtofloatdef and so on.

Question five: The question of unit references. Using that function, you must refer to the cell where the function resides.

For example, in the development of the program we need to use an API function Extracticonex (from the program or file to get an icon), then the first in its uses to join the unit SHELLAPI, otherwise it can not be compiled. There are many similar cases where we often use help documents to find the functions we need, but when the program compiles, it doesn't work. It is because there is no reference to the cell in the uses that contains the function. This problem is made by the most beginners and should be paid more attention to.

Problem Six: Avoid circular references, as much as possible through a third unit. If it is unavoidable, you should refer to it in different locations. The so-called circular reference is that unit a refers to Unit B, and in turn, Unit B refers to unit A, which produces loops. We also look at the above section of the program, there is a uses statement under the interface, and under implementation, there is a uses statement. If the loop is indeed unavoidable, then the reference in unit A should be written in the first uses statement, and the reference in unit B should be written in the second uses statement.