ch10.htm

delphi自学的好教材！特别适合刚刚起步学习delphi的人员！同样对使用者具有参考价值！

	buttons. 
<HR>


</BLOCKQUOTE>

<P>The Evaluate/Modify dialog box works similarly to the Watch List or the Debug
Inspector. If you click a variable in the source code and choose Evaluate/Modify
from the Code Editor context menu, the variable will be evaluated. If you want to
enter a value not currently showing in the source code, you can choose Run|Evaluate/Modify
from the main menu and then type a variable name to evaluate.</P>
<P>The Expression field is used to enter the variable name or expression you want
to evaluate. When you click the Evaluate button (or press Enter), the expression
will be evaluated and the result displayed in the Result field.</P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>NOTE:</strong> The Evaluate/Modify dialog box can be used as a quickie calculator.
	You can enter hex or decimal numbers (or a combination) in a mathematical formula
	and have the result evaluated. For example, if you type 
	<PRE>$400 - 256</PRE>

</BLOCKQUOTE>

<PRE></PRE>


<BLOCKQUOTE>
	<P>in the Evaluate field and press Enter, the result, 768, is displayed in the Result
	field.<BR>
	</P>

	<P>You can also enter logical expressions in the Evaluate field and have the result
	shown in the Result field. For example, if you enter 
	<PRE>20 * 20 = 400</PRE>

</BLOCKQUOTE>

<PRE></PRE>


<BLOCKQUOTE>
	<P>the Result field would show True. The program must be stopped at a breakpoint
	for the Evaluate/Modify dialog box to function. 
<HR>


</BLOCKQUOTE>

<P>If you want to change a variable's value, enter a new value for the variable in
the New Value field and click the Modify button. The variable's value will be changed
to the new value entered. When you click the Run button to restart the program (or
continue stepping), the new value will be used.</P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>NOTE:</strong> The Evaluate/Modify dialog box doesn't update automatically when
	you step through your code, as do the Watch List and Debug Inspector. If your code
	modifies the variable in the Evaluate/Modify dialog box, you must click the Evaluate
	button again to see the results. This aspect of the Evaluate/Modify dialog box has
	one primary benefit; stepping through code is quicker because the debugger doesn't
	have to evaluate the expression each time you step (as it does for the Watch List
	and Debug Inspector). A typical interaction with this dialog box would be to evaluate
	a variable or expression and then immediately close the Evaluate/Modify dialog box.
	
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading20"></A>The Call Stack Window</H3>
<P>While your program is running, you can view the call stack to inspect any functions
or procedures your program called. From the main menu, choose View|Debug Windows|Call
Stack to display the Call Stack window. This window displays a list of the functions
and procedures called by your program and the order in which they were called. The
most recently called function or procedure is at the top of the window.</P>
<P>Double-clicking a method name in the Call Stack window takes you to the source
code line for that method if the method is in your program. In case of functions
or procedures for which there is no source code (VCL methods, for example), the Call
Stack window contains just an address and the name of the module where the procedure
is located. Double-clicking a listed function or procedure without source code will
display the CPU window (the CPU window is discussed in the next section).</P>
<P>Viewing the call stack is most helpful after a Windows Access Violation error.
By viewing the call stack, you can see where your program was just before the error
occurred. Knowing where your program was just before it crashed is often the first
step in determining what went wrong.</P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>TIP:</strong> If the call stack list contains seemingly nonsensical information,
	it could be that the call stack was corrupted. A corrupted call stack is usually
	an indicator of a stack overflow or a memory overwrite. A stack overflow isn't as
	likely to occur in a 32-bit program as in a 16-bit program, but it still can happen.
	
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading21"></A>The CPU Window</H3>
<P>Officially speaking, the CPU window is new to Delphi 4. You could get the CPU
window in previous versions of Delphi, but only if you knew the magical Registry
entry. The CPU window is now officially part of Delphi and can be found on the main
menu under View|Debug Windows|CPU (Ctrl+Alt+C on the keyboard).</P>
<P>The CPU window enables you to view your program at the assembly instruction level.
Using this view, you can step into or over instructions one assembly instruction
at a time. You can also run the program to a certain assembly instruction just as
you can run the program to a certain source line with the regular debugger. The CPU
window has five panes: the disassembly pane, the register pane, the flags pane, the
raw stack pane, and the dump pane.</P>
<P>Each pane has a context menu associated with it. The context menus provide all
the functions necessary to use that pane. To be used effectively, the CPU window
requires a knowledge of assembly language. Obviously, the CPU window is an advanced
debugging feature.</P>
<P>
<H3><A NAME="Heading22"></A>The Go to Address Command</H3>
<P>The Go to Address command is also an advanced debugging tool. When your program
crashes, Windows displays an error message showing the address of the violation.
You can use the Go to Address command to attempt to find out where in your program
the crash occurred. When you get an Access Violation error message from Windows,
you see a dialog box similar to the one shown in Figure 10.9.</P>
<P><A HREF="javascript:popUp('28671009.gif')"><B>FIGURE 10.9.</B></A><B> </B><I>A
Windows message box reporting an access violation.</I></P>

<P>When you see this error message, write down the address at which the violation
occurred and then choose Debug|Go to Address from the Code Editor context menu to
display the Goto Address dialog box. Enter the address you just wrote down in the
Address field of the Goto Address dialog box.</P>
<P>When you click OK, the debugger will attempt to find the source code line where
the error occurred. If the error occurred in your code, the cursor will be placed
on the line that generated the error. If the error occurred somewhere outside your
code, you will get a message box saying that the address could not be found. As I
said, this is an advanced debugging tool and one that you might never use.</P>
<P>
<H2><A NAME="Heading23"></A>Stepping Through Your Code</H2>
<P>Stepping through code is one of the most basic debugging operations, yet it still
needs to be mentioned here. Sometimes you fail to see the forest for the trees. (Just
as sometimes authors of programming books fail to include the obvious!) Reviewing
the basics from time to time can reveal something you were not previously aware of.
<PRE></PRE>
<H3><A NAME="Heading24"></A>Debugging Gutter Symbols</H3>
<P>Before beginning this section, I'll say a few words about the symbols that appear
in the Code Editor gutter during a debugging session. In the section &quot;Setting
and Clearing Breakpoints,&quot; I told you that a red circle appears in the gutter
when you set a breakpoint on a code line. I also said that a green arrow glyph indicates
the execution point when you are stepping through code.</P>
<P>One point I didn't mention, though, is the little blue dots that appear in the
gutter next to certain code lines. These dots indicate lines in your source code
that actually generate assembly code. Figure 10.10 shows the Code Editor with the
debugger stopped at a breakpoint. It shows the small dots that indicate generated
code, the arrow glyph indicating the execution point, and the breakpoint glyph as
well. The check mark on the breakpoint glyph indicates that the breakpoint was checked
and was determined to be a valid breakpoint.</P>
<P><A HREF="javascript:popUp('28671010.gif')"><B>FIGURE 10.10.</B></A><B> </B><I>The
Code Editor showing gutter symbols.</I></P>

<P>Take a closer look at Figure 10.10. Notice that the small dots only appear next
to certain code lines. Lines without the dots don't generate any compiled code. Take
these lines, for example:</P>
<P>
<PRE>var
  S : string;
  X : Integer;
</PRE>
<P>Why don't these lines generate code? Because they are variable declarations. How
about this line:</P>
<P>
<PRE>X := 20;
</PRE>
<P>Why is no code generated for this line? Here's that word again: <I>optimization</I>.
The compiler looks ahead and sees that the variable X is never used, so it completely
ignores all references to that variable. Finally, notice these lines:</P>
<P>
<PRE>{$IFNDEF WIN32}
S := `Something's very wrong here...';
{$ENDIF}
</PRE>
<P>The compiler doesn't generate code for the line of source code between the compiler
directives because the symbol WIN32 is defined in a Delphi 4 program. The compiler
$IFNDEF WIN32 directives tell the compiler, &quot;Compile this line of code only
if the target platform is not 32-bit Windows.&quot; Because Delphi 4 is a 32-bit
compiler, this line of code is not compiled. This line of code <I>will</I> be compiled
if this code is compiled in Delphi 1 (a 16-bit environment).</P>
<P>
<H3><A NAME="Heading25"></A>Step Over and Trace Into</H3>
<P>Okay, back to stepping through code. When you stop at a breakpoint, you can do
many things to determine what is going on with your code. You can set up variables
to watch in the Watch List, inspect objects with the Debug Inspector, or view the
call stack. You can also step through your code to watch what happens to your variables
and objects as each code line is executed.</P>
<P>As you continue to step through your code, you will see that the line in your
source code to be executed next is highlighted in blue. If you have the Watch List
and Debug Inspector windows open, they will be updated as each code line is executed.
Any changes to variables or objects will be immediately visible in the watch or inspector
window. The IDE debugger has two primary stepping commands to aid in your debugging
operations: Step Over and Trace Into.</P>
<P>
<H4>Step Over</H4>
<P>Step Over means to execute the next line in the source code and pause on the line
immediately following. Step Over is sort of a misnomer. The name indicates that you
can step over a source line and the line won't be executed. That isn't the case,
however. Step Over means that the current line will be executed and any functions
or procedures called by that source line will be run at full speed. For example,
let's say you set a breakpoint at a line that calls a method in your program. When
you tell the debugger to step over the method, the debugger will execute the method
and stop on the next line. (Contrast this with how Trace Into works, which you'll
learn about in a minute, and it will make more sense.) To use Step Over to step through
your program, you can either press F8 or choose Run|Step Over from the main menu.</P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>NOTE:</strong> As you step through various source code units in your program, the
	Code Editor will automatically load and display the needed source units if they are
	not already open. 
<HR>


</BLOCKQUOTE>

<H4>Trace Into</H4>
<P>The Trace Into command enables you to trace into any functions or procedures that
are encountered as you step through your code. Rather than execute the function or
procedure and return to the next line as Step Over does, Trace Into places the execution
point on the first source code line in the function or procedure being called. You
can then step line-by-line through that function or procedure using Step Over or
Trace Into as necessary. The keyboard shortcut for Trace Into is F7.</P>
<P>After you have inspected variables and done whatever debugging you need to do,
you can again run the program at full speed by clicking the Run button. The program
will function normally until the next breakpoint is encountered.</P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>TIP:</strong> If you have the Professional or Client/Server version of Delphi, you
	can step into the VCL source code. When you encounter a VCL method, Trace Into will
	take you into the VCL source code for that method. You can inspect whatever variables
	you need to see. You must add the path to the VCL source in to the Search path field
	of the Project Options (Directories/ Conditionals page). To enable this option, you
	must do a Build after adding the VCL source directory to the Search path field. Stepping
	into the VCL source is of doubtful benefit to most programmers. Experienced programmers,
	though, will find it useful. 
<HR>


</BLOCKQUOTE>

<H4>Trace To Next Source Line</H4>
<P>Another, less frequently used debugging command is Trace To Next Source Line (Shift+F7
on the keyboard). You will not likely use this command a lot, particularly not until
you get more familiar with debugging and Windows programming in general. Some Windows
API functions use what is termed a <I>callback function</I>. This means that the
Windows function calls one of your own functions to perform some action.</P>
<P>If the execution point is on a Windows API function that uses a callback, using
Trace To Next Source Line will jump the execution point to the first line in the
callback function. The effect is similar to Trace Into, but the specific situation
in which Trace To Next Source Line is used is altogether different. If that doesn't
make sense to you, don't worry about it. It's not important for what you need to
learn today.</P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>NOTE:</strong> When you are stepping through a method, the execution point will
	eventually get to the end statement of the method. If the method you are stepping
	through returns control to Windows when it finishes, pressing F8 when you're on the
	end statement will exit the method and return control to the program being debugged.
	There is no obvious indication that the program is no longer paused because the IDE
	still has focus. This behavior can be confusing the first few times you encounter
	it unless you are aware of what has happened. To switch back to your program, just
	activate it as you would any other program (click its button on the Windows taskbar
	or use Alt+Tab). 
<HR>


</BLOCKQUOTE>

<P>As I said, stepping through your code is a basic debugging technique, but it is
one that you will use constantly while debugging. Of all the keyboard shortcuts available
to you in Delphi, F7 (Trace Into), F8 (Step Over), and F9 (Run) should definitely
be in your arsenal.</P>
<P>
<H2><A NAME="Heading26"></A>Debugging a DLL</H2>
<P>For the most part, debugging a DLL (dynamic link library) is the same as debugging
an executable file. You place breakpoints in the DLL's code and when a breakpoint
is hit, the debugger will pause j