apd.htm

A very good resource on Visual C++ 6.0 environment. It teaches through step by step approach and fin

<P>
<H3><A NAME="Heading4"></A>Setting Breakpoints</H3>
<P>Probably the simplest way to set a breakpoint is to place the cursor on the line
of code where you would like to pause. Then, toggle a breakpoint by pressing F9 or
by clicking the Insert/Remove Breakpoint button on the Build MiniBar, which looks
like an upraised hand (you're supposed to think &quot;Stop!&quot;). A red dot appears
in the margin to indicate you have placed a breakpoint here, as shown in Figure D.1.</P>
<P><A HREF="javascript:popUp('xduvc01.gif')"><B>FIG. D.1</B></A><B> </B><I>The F9
key toggles a breakpoint on the line containing the cursor.</I></P>
<P>


<BLOCKQUOTE>
	<P>
<HR>
<strong>NOTE:</strong> The application being debugged throughout this appendix is ShowString,
	as built in Chapter 8, &quot;Building a Complete Application: ShowString.&quot;&#160;n
	
<HR>


</BLOCKQUOTE>

<P>Choosing Edit, Breakpoints displays a tabbed dialog box to set simple or conditional
breakpoints. For example, you may want to pause whenever a certain variable's value
changes. Searching through your code for lines that change that variable's value
and setting breakpoints on them all is tiresome. Instead, use the Data tab of the
Breakpoints dialog box, shown in Figure D.2. When the value of the variable changes,
a message box tells you why execution is pausing; then you can look at code and variables,
as described next.</P>
<P>You can also set conditional breakpoints, such as break on this line when i exceeds
100, that spare you from mindlessly clicking Go, Go, Go until you have been through
a loop 100 times.</P>
<P><A HREF="javascript:popUp('xduvc02.gif')"><B>FIG. D.2</B></A><B> </B><I>You can
arrange for execution to pause whenever a variable or expression changes value.</I></P>
<H3><I></I></H3>
<H3><A NAME="Heading5"></A>Examining Variable Values</H3>
<P>When you set a breakpoint and debug the program, everything proceeds normally
until the breakpoint line of code is about to execute. Then Developer Studio comes
up on top of your application, with some extra windows in the display and a yellow
arrow in the red margin dot that indicates your breakpoint, as shown in Figure D.3.
This shows you the line of code that is about to execute.</P>
<P><A HREF="javascript:popUp('xduvc03.gif')"><B>FIG. D.3</B></A><B> </B><I>A yellow
arrow indicates the line of code about to execute.</I></P>
<P>Move the mouse over a variable name, like color or horizcenter. A DataTip appears,
telling you the current value of this variable. You can check as many local variables
as you want like this, then continue executing, and check them again. There are other
ways, though, to examine variable values.</P>
<P>You could click on the variable (or move the cursor to it some other way) and
choose Debug, QuickWatch or click the QuickWatch button (a pair of glasses) on the
toolbar. This brings up the QuickWatch window, which shows you the value of a variable
or expression and lets you add it to the Watch window, if you want. You're probably
wondering why anyone uses this feature now that DataTips will show you a variable's
value without even clicking. DataTips can't handle expressions, even simple ones
like dlg.m_horizcenter, but QuickWatch can, as you see in Figure D.4. You can also
change a variable's value with this dialog box to recover from horrible errors and
see what happens.</P>
<P><A HREF="javascript:popUp('xduvc04.gif')"><B>FIG. D.4</B></A><B> </B><I>The QuickWatch
dialog box evaluates expressions. You add them to the Watch window by clicking Add
Watch.</I></P>
<P>Figure D.5 shows a debug session after running forward a few lines from the original
breakpoint (you'll see how to do this in a moment). The Watch and Variable windows
have been undocked to show more clearly which is which, and two watches have been
added: one for horizcenter and one for dlg.m_horizcenter. The program is paused immediately
after the user clicks OK on the Options dialog, and in this case the user changed
the string, the color, and both kinds of centering.</P>
<P>The Watch window simply shows the values of the two variables that were added
to it. horizcenter is still TRUE (1) because the line of code that sets it has not
yet been executed. dlg.m_horizcenter is FALSE (0) because the user deselected the
check box associated with the member variable. (Dialogs, controls, and associating
controls with member variables are discussed in Chapter 2, &quot;Dialogs and Controls.&quot;)</P>
<P>The Variables window has a lot more information in it, which sometimes makes it
harder to use. The local variable dlg and the pointer to the object for whom this
member function was invoked, this, are both in the Variables window in tree form:
Click on a + to expand the tree and on a - to collapse it. In addition, the return
value from DoModal(), 1, is displayed.</P>
<P>At the top of the Variables window is a drop-down box labeled <I>Context</I>.
Dropping it down shows how control got here: It lists the names of a series of functions.
The top entry is the function in which the line about to be executed is contained,
CShowStringDoc::OnToolsOptions(). The second entry is the function that called this
one, _AfxDispatchCmdMsg(), which dispatches command messages. Chapter 3, &quot;Messages
and Commands,&quot; introduces commands and messages and discusses the way that control
passes to a message-handling function like OnToolsOptions(). Here, the debugger gives
proof of this process right before your eyes.</P>
<P><A HREF="javascript:popUp('xduvc05.gif')"><B>FIG. D.5</B></A><B> </B><I>The Watch
window and the Variable window make it easy to know the values of all your variables.</I></P>
<P>Click on any function name in the drop-down box and the code for that function
is displayed. You can look at variables local to that function, and so on.</P>
<P>The Call Stack window, shown in Figure D.6, is easier to examine than the drop-down
box in the Variables window, and it shows the same information. As well as the function
names, you can see the parameters that were passed to each function. You may notice
the number 32771 recurring in most of the function calls. Choose View, Resource Symbols,
and you'll see that 32771 means ID_TOOLS_OPTIONS, the resource ID associated with
the menu item Tools, Options in ShowString (see Figure D.7).</P>
<P><A HREF="javascript:popUp('xduvc06.gif')"><B>FIG. D.6</B></A><B> </B><I>The Call
Stack window shows how you arrived here.</I></P>
<P>
<H3><A NAME="Heading6"></A>Stepping Through Code</H3>
<P>Double-clicking a function name in the call stack or the context drop-down box
of the Variables window doesn't make any code execute: It simply gives you a chance
to examine the local variables and code of the functions that called the function
now executing. After you've looked at everything you want to look at, it's time to
move on. Although there are items on the Debug menu to Step Over, Step Into, and
so on, most developers use the toolbar buttons or the keyboard shortcuts. The Debug
toolbar can be seen in Figures D.1, D.3, and D.5. Pause your mouse over each button
to see the command it is connected to and a reminder of the keyboard shortcut. For
example, the button showing an arrow going down into a pair of braces is Step Into,
and the shortcut key is F11.</P>
<P><A HREF="javascript:popUp('xduvc07.gif')"><B>FIG. D.7</B></A><B> </B><I>The number
32771 corresponds to ID_TOOLS_OPTIONS.</I></P>
<P>As you move through code, the yellow arrow in the margin moves with you to show
which line is about to execute. Whenever the program is paused, you can add or remove
breakpoints, examine variables, or resume execution. These are the mechanics of debugging.</P>
<P>
<H3><A NAME="Heading7"></A>Edit and Continue</H3>
<P>Most developers are familiar with the cycle of debugging work. You build your
project, you run it, and something unusual happens. You debug for a while to understand
why. You find the bad code, change it, rebuild, rerun, and either find another bug
or convince yourself that the application works. Sometimes you think you've fixed
it, but you haven't. As your project grows, these rebuilds can take a very long time,
and they break the rhythm of your work. It can also take a significant amount of
time to run the application to the trouble spot each time. It's very boring to enter
the same information every time on a dialog box, for example, trying to set up an
error condition.</P>
<P>In version 6.0 of Visual C++, in many cases you can keep right on debugging after
making a code change--without rebuilding and without rerunning. This feature is called
Edit and Continue and is sure to be a major time-saver.</P>
<P>To use Edit and Continue, you should start by confirming that it's enabled both
for the product as a whole and for this specific project. First, choose Tools, Options
and click the Debug tab. Make sure that Debug commands Invoke Edit and Continue is
selected, as in Figure D.8. Second, choose Project, Settings and click the C/C++
tab. In the left pane, make sure you are editing your Debug settings. Ensure that
the Debug Info drop-down box contains Program Database for Edit and Continue. If
not, drop the box down, select this option, as in Figure D.9 (it's last on the list),
and then rebuild the project after exiting the Project Settings dialog. Always check
the project settings when you start a new project, to confirm that Edit and Continue
is enabled.</P>
<P><A HREF="javascript:popUp('xduvc08.gif')"><B>FIG. D.8</B></A><B> </B><I>Enable
Edit And Continue on the Debug tab of the Options dialog.</I></P>
<P><A HREF="javascript:popUp('xduvc09.gif')"><B>FIG. D.9</B></A><B> </B><I>Your project
must generate Edit and Continue information.</I></P>
<P>Now, debug as you always did, but don't automatically click Build after making
a code change: Try to step to the next line. If it's not possible to continue without
a build, you will receive a line of output in the Build tab of the Output window
telling you so and the familiar One or More Files Are out of Date message box offering
you a chance to rebuild your project. If it's possible to continue, you will have
saved a tremendous amount of time.</P>
<P>Most simple code changes, such as changing the condition in an if or for statement
or changing the value to which you set a variable, should work immediately. More
complex changes will require a rebuild. For example, you must rebuild after any one
of these changes:</P>

<UL>
	<LI>Any change to a header file, including changing code in an inline function
	<P>
	<LI>Changing a C++ class definition
	<P>
	<LI>Changing a function prototype
	<P>
	<LI>Changing the code in a global (nonmember) function or a static member function
</UL>

<P>Try it yourself: Imagine that you can't remember why the string originally displayed
by ShowString is black, and you'd like it to be red. You suspect that the OnNewDocument()
function is setting it, so you expand CShowStringDoc in the ClassView and double-click
OnNewDocument(). Then you place a breakpoint (F9) on this line:</P>
<P>
<PRE>string = &quot;Hello, world!&quot;;
</PRE>
<P>Click Go (F5), or choose Build, Start Debug, Go; ShowString will run, create a
new document, and stop at your breakpoint. Change the next line of code to read</P>
<P>
<PRE>color = 1;   //red
</PRE>
<P>Click Go again and wait. Watch your output window and you will see that showstringdoc.cpp
is recompiling. After a short wait, the familiar Hello, world! will appear--in red.
Your changes went into effect immediately.</P>
<P>When you finish your debugging session, it's a good idea to do a build because
the changes used by Edit and Continue may be in memory only and not written out to
your executable file.</P>
<P>
<H3><A NAME="Heading8"></A>Other Debug Windows</H3>
<P>Three debug windows have not yet been mentioned: Memory, Registers, and Disassembly.
These windows provide a level of detail rarely required in ordinary debugging. With
each release of Visual C++, the circumstances under which these windows are needed
dwindle. For example, the Registers window used to be the only way to see the value
just returned from a function call. Now that information is in the Variables window
in a more accessible format.</P>
<P><B>The Memory Window&#160;&#160;</B>This window, shown in Figure D.10, shows you
the hex values in every byte of the memory space from 0x00000000 to 0xFFFFFFFF. It's
a very long list, which makes the dialog box hard to scroll--use the Address box
to enter an address that interests you. Typically, these addresses are copied (through
the Clipboard, not by hand) from the Variables window. It is a handy way to look
through a large array or to track down subtle platform- dependent problems.</P>
<P><A HREF="javascript:popUp('xduvc10.gif')"><B>FIG. D.10</B></A><B> </B><I>You can
examine raw memory, though you'll rarely need to.</I></P>
<P><B>The Registers Window&#160;&#160;</B>If you are debugging at the assembler level,
it might be useful to examine the registers. Figure D.11 shows the Registers window.
This shot was taken at the same point of execution as Figure D.5, and you can see
that the EAX register contains the value 1, which is the return value from DoModal().</P>