Debugging

for RuBoard

In this section we will discuss some of the debugging facilities in Visual Studio. To be able to benefit from debugging at the source code level, you should have built your executable using a Debug configuration, as discussed previously. There are two ways to enter the debugger:

  1. Just-in-Time Debugging. You run normally, and if an exception occurs you will be allowed to enter the debugger. The program has crashed, so you will not be able to run further from here to single step, set breakpoints, and so on. But you will be able to see the value of variables , and you will see the point at which the program failed.

  2. Standard Debugging. You start the program under the debugger. You may set breakpoints, single step, and so on.

Just-in-Time Debugging

Build and run (without debugging) the Bytes program from the previous section, making sure to use the CheckedDebug configuration. This time the program will not run through smoothly to completion, but an exception will be thrown. A "Just-In-Time Debugging" dialog will be shown (see Figure A-11). Click Yes to debug.

Figure A-11. Just-In-Time Debugging dialog is displayed in response to an exception.

graphics/apafig11.gif

Click OK in the "Attach to Process" dialog and then click Break in the "Microsoft Development Environment" dialog. You will now be brought into a window showing the source code where the problem arose, with an arrow pinpointing the location.

To stop debugging you can use the graphics/icon09.gif toolbar button or the menu Debug Stop Debugging.

Standard Debugging

Breakpoints

The way you typically do standard debugging is to set a breakpoint and then run using the debugger. As an example, set a breakpoint at the first line:

 bytes = bytes * 1024; 

The easiest way to set a breakpoint is by clicking in the gray bar to the left of the source code window. You can also set the cursor on the desired line and click the "hand" toolbar button graphics/icon05.gif to toggle a breakpoint (set if not set, and remove if a breakpoint is set). Now you can run under the debugger, and the breakpoint should be hit. A yellow arrow over the red dot of the breakpoint shows where the breakpoint has been hit. See Figure A-12.

Figure A-12. A breakpoint has been hit.

graphics/apafig12.gif

When you are done with a breakpoint, you can remove it by clicking again in the gray bar or by toggling with the hand toolbar button. If you want to remove all breakpoints, you can use the menu Debug Clear All Breakpoints, or you can use the toolbar button graphics/icon06.gif .

Watching Variables

At this point you can inspect variables. The easiest way is to slide the mouse over the variable you are interested in, and the value will be shown as a yellow tool tip. You can also right-click over a variable and choose Quick Watch (or use the eyeglasses toolbar button graphics/icon03.gif ). Figure A-13 shows a typical Quick Watch window. You can also change the value of a variable from this window.

Figure A-13. Quick Watch window shows variable, and you can change it.

graphics/apafig13.gif

When you are stopped in the debugger, you can add a variable to the Watch window by right-clicking over it and choosing Add Watch. The Watch window can show a number of variables, and the Watch window stays open as the program executes. When a variable changes value, the new value is shown in red. Figure A-14 shows the Watch window (note that the display has been changed to hex, as described in the next section).

Figure A-14. Visual Studio Watch window.

graphics/apafig14.gif

Debugger Options

You can change debugger options from the menu Tools Options, and select Debugging from the list. Figure A-15 illustrates setting a hexadecimal display. If you then go back to a Watch window, you will see a hex value such as 0x400 displayed.

Figure A-15. Setting hexadecimal display in Debugging Options.

graphics/apafig15.gif

Single Stepping

When you are stopped in the debugger, you can single step . You can also begin execution by single stepping. There are a number of single step buttons . graphics/icon10.gif The most common are (in the order shown on the toolbar):

  • Step Into

  • Step Over

  • Step Out

There is also a Run to Cursor button graphics/icon11.gif .

With Step Into you will step into a function, if the cursor is positioned on a call to a function. With Step Over you will step to the next line (or statement or instruction, depending on the selection in the dropdown next to the step buttons graphics/icon14.gif ). To illustrate Step Into, build the Bytes\Step2 project, where the multiplication by 1,024 has been replaced by a function call to the static method OneK . Set a breakpoint at the first function call, and then Step Into. The result is illustrated in Figure A-16. Note the red dot at the breakpoint and the yellow arrow in the function.

Figure A-16. Stepping into a function.

graphics/apafig16.gif

When debugging, Visual Studio maintains a Call Stack. In our simple example the Call Stack is just two deep. See Figure A-17.

Figure A-17. The call stack.

graphics/apafig17.gif

for RuBoard


Application Development Using C# and .NET
Application Development Using C# and .NET
ISBN: 013093383X
EAN: 2147483647
Year: 2001
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net