Mastering The Art of Debugging in C BuilderArticle 2 - Watching It Closely
Master C Builder's Included Art
The second - close observation (1)
1. Preparation before debugging / deactivation can perform programs
2. Engineering options
3. Set breakpoints and break into the executable
4. Look at the value stored in the variable
5. Use Watches (see)
6. Using Inspectors
7. Using Evaluate / Modify (seeking value / modification)
8. Stepping through, over and arrone
STEPPING TYPES
10. Stepping Notes
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.
Debug / deactivation can perform programs preparation
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 the "Full Debug" button. The other settings we need is already set. Set the code "code optimization" to "None". This is always a good thing. Doctors do ten tell the compiler, all things are done. You just need to generate a machine code, not to improve other intelligent optimization 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 we write, 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 for the released code, but it is best to turn off this item when debugging, he will only make you more headaches.
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" and "Don't generate State Files" (do not generate status files) are options that cause trouble, I usually use status files (this allows incremental links, but will be in the compilation directory Generate a 4-fold-to-execry or a larger file), in turn, this will increase the speed of the link. Using Dynamic RTL itself is an argument, there are 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. Based on all the debugging experiences you have to disable "Build With Runtime Packages" (compiled with runtime package). 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 most "symptoms" 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, which does not run the package (static) compile, allowing your program to get rid of CBUILDER.), 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, when debugging your code, you can set a very stringent breakpoint. 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 / 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 read this, 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 press Ctrl-Alt-L
