Mastering The Art of Debugging in C BuilderArticle 2 - Watching It Closely
Master C Builder's Included Art
Second article - close observation
(1)
1. Preparing before debugging executable
2. Engineering options
3. Set breakpoints and break into the executable
4. Look at the value stored in the variable
5. Use Watches (observation)
6. Using Inspectors (inspector)
7. Using Evaluate / Modify (seeking value / modification)
8. Stepping through, over and arrone
9. STEpping type
10. STEPPING Note
11. Other tips
Okay, (again, child preparation) Now start tracking, the search is still hiding in the code in the code after the previous effort, that is, start tracking the BUG / exception labeled in the previous article code. The first is the preparation phase.
Debugging the preparation before executing
Before we start debugging executable programs, we need to ensure that some of the correctness of settings in most cases. I will pick a pass and briefly explain why you must do it. (If you are interested in some things, press the help button, there will be many more detailed content). Go now, open the Project | Options option first.
Engineering options
First we stopped at the "Compiler" tag. You only need to simply click on the "Full Debug" button, and the significant settings we need will have set it. Set "Code Optimization" to "None". Do you always tell the compiler: All things have been done, just generate the machine code. Not to improve other intelligent optimizations in order to improve a little running speed. (Of course, after everything is completed, you can open this item.) This benefit is great to reduce the difficulty of our debugging. Because the code in the program is the same as our writing, it is not optimized by the compiler. In the "debugging" panel, select "DEBUG INFORMATION" (click) and must be set to "Line Number Information". I also recommend an item to select "Disable Inline Expansions". Inline expansion is very good to the published code, but it is best to turn off this item when debugging, he will only make you more headache.
Then it is "Pascal" tag, especially when connecting the Pascal unit in your engineering or uses a PASCAL-based VCL control (if you own its PASCAL source code, the compiler will automatically use the settings in this section to recompile). Here you must disable the "Optimization" optimization option, and then I usually select all the options of the "Debugging" section (hook).
Next is the "Linker" tag, we need to select "Create Debug Information". "Use Dynamic RTL" (using dynamic RTL) and "Don't generate State Files" are the troublesome options. I usually use status files (this allows incremental links, but will generate a 4-fold-to-executable or larger file in the compilation directory), which will increase the speed of the link. It is an argument that uses Dynamic RTL itself, there are still many discussions and opposition. The next is a "Directories / Conditionals" tab. Here we want to set the value of "Directories / Conditionals". We will always set this to $ (bcb) / source / vcl, but if you have any other components attached, it usually adds their paths to be a good idea (path and path "; "Separate or you can set them with a dialog box that pops up.
Finally, it is also the most important setting is on the "Packages" tab. According to all the proven debugging experiences you must disable "Build With Runtime Packages" (with runtime package compilation). The reason for this is that the package itself does not include and cannot contain debug information. Doing so, it may be advisable to track the standard VCL code, such as how to see how the parameter x in the VCL function y acts. But most of you, you will find that the debugger will return your vast "symptom" to VCL, although "cause" in your source code (or in other components (this is already all all Has happened to people)). Once you have released your official version, you can decide whether to use the package. (Translator Note: The essence of the package is a special DLL, without running a package (static) compile, allowing your program to run independently.), But when debugging, please disable it. Press the OK button, we are ready. The next dialog is just once, but it is best to check if we are here in the following settings. Ok, open "Tools | Debugger Options ...".
The "Integrated Debugging" option for the dialog box is the key. Confident is a hook already hooked. Press the OK button to prepare to compile the executable. I recommend re-coming once a complete compilation (select Project | Build All) if you have modified your settings (especially after changing the "Building with packages). This will ensure that all of our program units are compiled as we want.
Set breakpoints and break into the executable
Like any other debugger you have ever seen, C Builder provides powerful breakpoint settings. Basically, the breakpoint refers to a point in the code, and the program is executed to stop (unlike the exit, this is just the suspension of the suspension) and will control the control to the debugger. Setting up a breakpoint is quite easy. Simply click on the gray tank area on the left side of the program code you want to set, you will see a red point, this line will also become red. The program will be suspended to run to this, and the control is charged to the debugger.
You may ask if I don't want to stop every time? Of course, it is also easy to do, depending on what the standard of your suspension program is? (Translator Note: Conditional breakpoint). Right click on the breakpoint (red point) and select "BREAKPOINT Properties" on the pop-up menu. There can be two types of attributes "condition" and "pass count". Condition is too convenient. You can use if () statements to enter almost any condition. However, please keep in mind all the variables in the conditions, it should be visible to this breakpoint. The conditional attribute is not compiled into the execution program, but when the program is running to the breakpoint, it is checked. The condition is true, stop, otherwise let the program continue to run. Another attribute "pass count" is also easy to understand. The breakpoint will be stopped after passing pass at PASS COUNT. In combination with these two properties, you can set a very stringent breakpoint when debugging your code. Another thing to keep in mind that when you have an abnormality in the debugger, it will appear in the form of breakpoints on the line code that produces an abnormality. This situation is easy to manufacture. Once you get an abnormal steps you should do, I will demonstrate how to retroactive and track the real cause of abnormal occurrence in the stack (such as the small piece of code that causes an exception).
Another prompt to keep in mind is that when you run your program, there is a breakpoint on the left side of the code window. All illegal breakpoints will become a yellow small fork in the red dot, and this line of code will turn black. The legal breakpoint turns into a green hook in the red dot. When running, you can set up / modify any point, and the breakpoint takes effect immediately without recompilation.
Check the value stored in the variable
Once your program stops in your breakpoint, what should I do? One thing you want to do and you must do, that is to check the true value of the various variables stored in your program. This part of the content involves a lot, you must insist and endure these boring things. Fortunately, when you finish these, you will have some new understanding of the most powerful features of the debugger. There are many ways to view the value of the variable, mainly to be determined according to your purpose. I will always finish them from the Local Variables (local variable) of the current function.
It is not too much to look at the local variable. Simply click on "View | Debug Windows | Local Variables" or pressing Ctrl-Alt-L to pop up a window, showing the local variable of the current function. The variables in the window will be updated with the update of the function body that you do next to or the backtrack.
Use Watches (observation)
The next step You can check the variables in the program by setting a variable watch (variable observation). Just as its name, a variable is observed and the value is displayed in a variable watch window (click "View | Debug Windows | Watches" or press CTRL-ALT-W). You can add an observation through two ways, the first is to highlight the variables or expressions you want to observe in the code window (yes! It can understand and evaluate the vast majority of simple expressions, such as (i * J) 05 or SomeVector [i] .name) and right click, select "Debug | Add Watch At Cursor" or press CTRL-F5, it will be added to the observation window. If necessary, open the observation window at the same time
You can also add it by double-clicking on the blank viewing window. At this time, you will pop up the Watch dialog, the meaning of the "Expression" domain does not need to say, but in several fields I want to explain, they are equally convenient. "Repeat Count" is used to observe an array variable (such as a Blah [50) array). You'll want to set the Expression (Expression) to the name of the array (this example is Blah). "Repeat Count" is set to the number of elements of the array (50 in this example). Each element of the array is then displayed (eg Blah [0], Blah [1], Blah [2] ...).
"DIGITS" is used to set the number of decimal digits that display decimal floating point. The following list is used to force the display type of the setting variable (the unsigned long integer is displayed as a hexadecimal format). There is also something to specifically explain that if you use the mouse in the Watch window, "Break When Change" option will appear on the pop-up menu, which will set a breakpoint on the variable, in this variable The program will be suspended when changing.
Use Inspectors (patrol)
The patrol variable is a third way to view the data in the variable. It is also almost the best way to observe the full class of data. There are two ways to patrol a variable. The first is in the Local Variable Window, double-click a variable, will pop up "Debug Inspector" window, which shows all "data" (variables) (data (variable) (data (variable) (data (variable) )), "Methods" (Method (Function)) and "Properties". If this is a simple data, the name of this variable and the value are displayed. (Translator Note: If it is an array? Really good!)
You will notice that the debug inspector is very like a Property Editor (Property Editor). Of course, more important is that in fact you can change these values in real time when running! ! ! Be careful! The result of removing bad values will make you can't say sadness. This ability of the patrol can be used to quickly test (assuming) Game level (translator Note: FPE, GM) instead of compilation - run - modify - compile - run loops.
(Example Patrol Form1) On the Properties page, you will see that some properties don't have the value it doesn't display, but it is displayed {read =, write =}. If these values can be assigned, when you click this area, you will notice a "?" Button appears on the right side of the property. Clicking this button will perform the appropriate function to attempt to retrieve the value of the property. We can give this example - just raise the properties of Form1 MdichildCount. Click on the property value area of MdichildCoun, press "?" Buttons, wow, 0 (the specified value of non-MDI program). The powerful ability to debug inspector is not here. The appropriate area of the patrol member variable Double-click to open the patrol window of the member variable and provide the same capabilities as you start opening the window. Another useful feature of the patrol window is the ability to inherit from objects. This can be done by selecting "Descend" by right-click on the appropriate area. The result of inheritance is a new variable. You will notice that the variable name in the top of the lower pull-down List box has been replaced with a new variable name. You can switch the patrol variables directly in ListBox. This makes it possible to quickly switch in different parts of the object, and will not let large and small patrol windows disrupt your workspace.
One thing to keep in mind is that if you leave the function, or leave the scope of the variable, the debug patrol will lose track of the variable. If you need to look again, please reset the inspector. However, if you run in the code of the current function, the inspector will be automatically refreshed.
Copyright statement:
On the domestic website, there are many contents about C Builder, but more software, components are mainly. Most of the forum can not be satisfactory, very empty. The book is expensive, but the content is too expensive. For beginners who are insufficient, self-study is not enough, so they want to do our best.
All materials in the article come from foreign websites. Because E text is inconvenient, turn into Chinese. Because English and computers are not very good, the mistakes in the text are inevitable. If you feel useful, I plan to continue to collect some useful things.
If you have any comments and suggestions, please allow mailto: cker@sina.com
You can copy, distribute, download this document free. However, you may not take it, change this article, or use this article to see any form of interest.
Pacific
2001.2
