Delphi Beginners should be careful with the six traps for compiling delphii at night. due to various reasons, delphii's many concepts cannot be well understood, and many problems arise, or the developed program is not stable, can run for a while, can not run for a while; or has encountered a problem for a long time cannot be understood, also mistakenly thought it is delphii own bug, and so on, etc, it wastes a lot of time and energy and affects our development efficiency.
So how can we avoid these mistakes and avoid detours as much as possible? I have been engaged in delphii development for many years. I will summarize my experience and hope to help my new friends of delphii.
Problem 1: The concept of classes is not in place and cannot be used flexibly in program development. See 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; |
Create a new program in delphii and add a button to get the following program. This should be a piece of program that everyone is quite familiar with, but it is also a piece of program that many people cannot understand after a long time of development. The program can be divided into three parts: the first part, the unit header (from the starting position to the type before); the second part (from the type to the end part ), defines a form class inherited from tform, which contains a member of The tbuttton type. The last part (VAR to the end part) defines a variable of the tform1 type. This is where the problem occurs. Many people mistakenly think that the last section is also part of the form class. Such code is often written in this form class, form1.caption = 'form title ', as a result, the program cannot get the expected results. In fact, the last part is basically the definition of the form class. They are only in the same unit, so the code should be written as follows: Self. Caption = 'form title ';
Problem 2: write the code of the released object in the close event of the form, resulting in access violation... .
The close and destory of a form are different in system processing. When a form is closed, the form is actually hidden, the resources it occupies are not released from the memory, so we can still access the data in the form. When the form responds to the destory event, the form is not just hidden, the occupied system resources are also released. Therefore, if a form is closed and we want to access the objects in it, we should write the free code of these objects into the form (destory) event.
Question 3: Use the string and consumer string data types without any difference.
The string type is different from the objective string type. By default (depending on the $ H switch), if you define a variable as the string type, it will be processed into an ansistring type. This type is dynamically allocated memory. It ends with null and has a maximum length of 4 GB, while the maximum length of string cannot exceed 255 characters. Because ansistring is a self-managed data of the lifetime, it means that this type of data requires more system overhead. Therefore, if the objective string can meet the requirements in program development, try to use it to speed up the program.
Problem 4: Improper handling during data type conversion. The most common mistakes are the conversion from the numeric type to the floating point type.
When converting a struct data to an integer, we often write I: = strtoint (aedit. text); on the surface, there is no problem with this sentence. The use of functions and the format are correct. However, we did not consider one case. What would happen if the user did not enter a digital text in the aedit text box? Will the call still be successful? Obviously, no. The system will certainly bring up an English error, which will make our users feel overwhelmed. The correct syntax is: I: = strtointdef (aedit. Text, 0); in this way, when the conversion fails, the second parameter is assigned to I. Similar functions include strtoint64def and strtofloatdef.
Question 5: Unit reference. When using that function, you must reference the unit where the function is located.
For example, if we want to use an API function extracticonex (getting an icon from a program or file) in program development, we need to add the unit shellapi in its uses, otherwise, it cannot be compiled. There are many other similar cases. We often use help documents to find the required functions, but the program compilation fails. Why? This is because the unit where the function is not referenced in uses. This problem is the most common problem for beginners. Pay more attention to it.
Problem 6: Avoid circular reference and implement it through the third unit as much as possible. If it is inevitable, it should be referenced in different locations. Unit A References Unit B, and unit B References Unit A to generate a loop. We also look at the above program. There is a uses statement under the interface, and there is a uses statement under implementation. If the loop is inevitable, you should write the reference in unit A in the first uses statement, and write the reference in Unit B in the second uses statement.
Six traps for beginners of Delphi
