Figure 127

When an error occurs during debugging, your first thought is likely to be "What just happened?" But how do you reproduce that error? As indicated in Figure 1-27, the IntelliTrace window tracks the steps you have taken — in this case showing that I had used the Run Code button a second time since the steps shown in Figure 1-26. By providing a historical trail, IntelliTrace enables you to reproduce a given set of steps through your application. You can also filter the various messages either by message type or by thread.

The ability to select these past break points and review the state of variables and classes in your running application can be a powerful tool for tracking down runtime issues. The historical debugging capabilities are unfortunately only available in Visual Studio 2010 Ultimate, but they take the power of the Visual Studio debugger to a new level.

However, even if you don't have the power of historical debugging, the Visual Studio debugger is a powerful development ally. It is, arguably, more important than any of the other developer productivity features of Visual Studio. With the execution sitting on this breakpoint, it is possible to control every aspect of your running code. Hovering over the property Count, as shown in Figure 1-28, Visual Studio provides a debug ToolTip showing you the current value of this property. This "hover over" feature works on any variable in your local environment and is a great way to get a feel for the different values without needing to go to another window.

Windows such as Locals and Autos display similar information about your variables, and you can use these to update those properties while the application is running. However, you'll note that the image in Figure 1-28 includes a small pin symbol. Using this you can keep the status window for this variable open in your Code view. This was done in Figure 1-29, and now as I step past the line where my breakpoint was set, the information in the window is updated to show the new value of Count. Visual Studio has just allowed you to create a custom watch window to reflect the value of Count.

•X> ProVB_VS2010 (Debugglng) - Microsoft Visual Studio [ »= i S MLJi—j

File Edlt View Protect Bulld Debug Team Data Tools Archlteeture Test Analyse Window Help

■ * ij ■ ■ d j ¿1 a j, z s ■ > j *»I«»» a

"W Form l.vb [Design]

IntelliTraco ▼


> ButttxiTot / Click



All Categories | ▼ | All Threads


" <param name=~scndcr"></parani> ' <param name--e"><>'param>


1 &flarch 1

(■) Debugger Breakpoint Hie Button'


' <remarks></reinartcs>

/ User Prompt Displayed "Hello W<


ivate Sub ButtonTest_Click(ByVal sender As System.Object,

KyVtil t- A\ Systrm.Fvi-ritAr-f.s) Htindli's Hul tnr

f User Prompt Clicked "OK"



Gestures Clicked "Run Code" (Butt.


McssyTCumt l f( "Hello World shown " * Count.ToString() i " times.", "Hello World Message Dox",

He 5 sageBoxButtons.UK,

Live Event: Breakpoint Hit Button'



L Solution Explorer

Mp s shjjhHox Itun.l rift »rma 1 i on )

Properties » ?


1 Sub



m i I

lau* - ..<

Im mediate Window - > >:





In 21

Col 0 Ch 0 INS

FiGure 1-28

FiGure 1-29

This isn't the end of it. As you'll note in Figure 1-29, by clicking on the down arrows you see on the right hand side of your new custom watch window, just below the pin, you can add one or more comments to your custom watch window for this value. You also have the option to unpin the initial placement of this window and move it off of your Code view display. Not only that but, the custom watch window is persistent in Debug mode. If you stop debugging and restart, the window is automatically restored and remains available until you choose to close it using the close button.

Next, move your mouse and hover over the parameter sender. This will open a window similar to the one for Count as you review the reference to this object. More important, note the small plus sign on the right-hand side, which if clicked expands the pop-up to show details about the properties of this object. As shown in Figure 1-30, this capability is available even for parameters like sender, which you didn't define. Figure 1-30 also illustrates a key point about looking at variable data. Notice that by expanding the top-level objects you can eventually get to the properties inside those objects. Next to some of those properties, on the right-hand side, is a little magnifying glass icon. That icon tells you that Visual Studio will open the potentially lengthy string value in any one of three visualization windows. When working with complex XML or other complex data, these visualizers offer significant productivity benefits by enabling you to review data.

/> ProVB VS2Q10 (Debugging) - Microsoft Visual Studio

= 3 H


Edit View Project Build Debug Team Data

Tools Architecture Test Analyze Window Help

J d J * U ^ A


■ - / . J -J p

Relcas, 1 jg Q




V'^ H Form l_vb [Design]


IMoftTraat » 9


.y ButtcwiTest 4 Click - 1

m i a o ji

All Categories \ ▼ | AH Threads ▼ 1

" <param namc="sender "></p^C()um 2 ' <param name-"e"></parami -—-'


S«»reh |

y" User Prompt; Displayed "Hello W<


' <remarksx/remarks>

/ User Prompt Clicked "OK"

-lvate buD buttontest_LlieK(,byvai sender As iystem.UDject,

KvVjI i- * sender (Text = "RunCode i-sKulturi, 1

/ G«turn; Clicked Run Cod«" (Butt




5m,WindowsJorms.Button [Text 'Run

Code"] bugger Breakpoint Hit Button'

Triblralt?» JfTabStop iffTabStopIntemal if Tag

True True Nothing



"Run Code"


^TextAJign ^ Text Visualizer * f extlmageReiation xml Visualize J?'0*' „ , HTML Visualizer

MiddleCenter {32} Overlay (0} 13

(ProVR.VSiOmFoiml, Tent: Professional Vfl.NFT)

1(1 1

¡±13? TopLevelControlInter nal iJJif TopMostPa rent if UseCompatibleTextRendering f> UseCompatibleTextRenderingDefault # UseCompati bleTextRenderinglnt "^UseMnemonic


(ProVB_VS2010.Formlr Text: Professional VB.NET)

[ProVB VS2010.Formlt TexC Professional VQ-NCT)





, _ ■


Ln 24 Col Ch?9 INS



Once you are at a breakpoint, you can control your application by leveraging the Debug buttons on the Standard toolbar. These buttons, shown in Figure 1-31, provide several options for managing the flow of your application. From the left are the following buttons: Start Debugging, Break All, Stop Debugging, and three buttons that look like a carriage return next to a set of lines. The first of these, which is the fourth button overall represents stepping into code. The last two buttons represent stepping over and stepping out, respectively. In this case you should use the Step Into or Step Over buttons to move to the next line of code as shown in Figure 1-29.

Step-In tells the debugger to jump to whatever line of code is first within the next method or property you call. Keep in mind that if you pass a property value as a parameter to a method, then the first such line

FIGuRE 1-31

of code is in the Get method of the parameter. Once there, you may want to step out. Stepping out of a method tells the debugger to execute the code in the current method and return you to the line that called the method. Thus, you could step out of the property and then step in again to get into the method you are actually interested in debugging.

Of course, sometimes you don't want to step into a method; this is where the Step-Over button comes in. It enables you to call whatever method(s) are on the current line and step to the next sequential line of code in the method you are currently debugging. The final button, Step-Out, is useful if you know what the code in a method is going to do, but you want to determine which code called the current method. Stepping out takes you directly to the calling code block.

Each of the buttons shown on the debugging toolbar in Figure 1-31 has an accompanying shortcut key for experienced developers who want to move quickly through a series of breakpoints.

Of course, the ability to leverage breakpoints goes beyond what you can do with them at runtime. You can also disable breakpoints that you don't currently want to stop your application flow, and you can move a breakpoint, although it's usually easier to just click and delete the current location, and then click and create a new breakpoint at the new location.

Keeping in mind that Visual Basic 2010 Express Edition does not support the advanced properties of breakpoints, Visual Studio provides additional properties for managing and customizing breakpoints. As shown in Figure 1-32, it's also possible to add specific properties to your breakpoints. The context menu shows several possible options.


More important, it's possible to specify that a given breakpoint should execute only if a certain value is defined (or undefined). In other words, you can make a given breakpoint conditional, and a pop-up window enables you to define this condition. Similarly, if you've ever wanted to stop, for example, on the thirty-seventh iteration of a loop, then you know the pain of repeatedly stopping at a breakpoint inside a loop. Visual Studio enables you to specify that a given breakpoint should only stop your application after a specified number of hits.

The next option is one of the more interesting options if you need to carry out a debug session in a live environment. You can create a breakpoint on the debug version of code and then add a filter that ensures you are the only user to stop on that breakpoint. For example, if you are in an environment where multiple people are working against the same executable, then you can add a breakpoint that won't affect the other users of the application.

Similarly, instead of just stopping at a breakpoint, you can also have the breakpoint execute some other code, possibly even a Visual Studio macro, when the given breakpoint is reached. These actions are rather limited and are not frequently used, but in some situations this capability can be used to your advantage.

Note that breakpoints are saved when a solution is saved by the IDE. There is also a Breakpoints window, which provides a common location for managing breakpoints that you may have set across several different source files.

Finally, at some point you are going to want to debug a process that isn't being started from Visual Studio — for example, if you have an existing website that is hosting a DLL you are interested in debugging. In this case, you can leverage Visual Studio's capability to attach to a running process and debug that DLL. At or near the top (depending on your settings) of the Tools menu in Visual Studio is the Attach to Process option. This menu option opens a dialog showing all of your processes. You could then select the process and have the DLL project you want to debug loaded in Visual Studio. The next time your DLL is called by that process, Visual Studio will recognize the call and hit a breakpoint set in your code.

Was this article helpful?

0 0

Post a comment