Searching for Breakpoints in Microsoft Visual Studio 2010

Introduction

I wrote my first BASIC code in 1978. I first got paid for writing a little code in 1987. This is a fact. In this business that means I have some perspective, some experience, and know a lot of things that aren’t that useful anymore. Just like everyone else in this business I have to keep learning.

The perspective part reminds me that there was a time when breakpoints could be added by inserting a call to interrupt 3, a low level system service. Perspective reminds me that we haven’t always had integrated development environments, and we had to use make files and command line compilers. Perspective also reminds me that debugging used to require a lot of extra code, print statements, and meticulously reading and auditing code manually. Old school debugging was a big, expensive, time consuming, pain in the butt. Then, we had integrated development environments, IDEs. The first IDE I used was for Turbo Pascal from Borland. (Remember Borland?) The next two languages and products I used routinely included an IDE for C++ and a very early version of Visual Basic for DOS. Programming environments progressively make software development easier.

Microsoft Visual Studio 2010 permits setting all manner of breakpoints with subsidiary settings. In large projects you can end up with a large number of breakpoints, finding and managing them can be a chore if you manually search through breakpoints. In this article I will quickly review several of the kinds of breakpoints and subsidiary settings you can make in Microsoft Visual Studio 2010 and then explore the features that support managing those breakpoints effectively.

Editing Breakpoints

The quickest way to set a breakpoint is to place the cursor in the Microsoft Visual Studio editor window and press F9 (or choose the Debug|Toggle Breakpoint menu item). A lot of the time just having a breakpoint at a certain location helps me find a bug. It is when things are going seriously wrong that a simple breakpoint might not be enough.

To review, when you set a breakpoint a red graphical dot is placed in the margin adjacent to the line where the breakpoint has been sent. If you right-click on the graphical red dot a breakpoint context menu is displayed. The easiest way to access advanced breakpoint options is through this context menu.

Setting Hit Count

One of the techniques I used to use is to add the keyword Stop where I needed a breakpoint. Stop was an earlier version of the breakpoint. If a break was needed based on a condition then some conditional code was manually added and the Stop was called when the condition was met. With Stop the Stop traveled with the code, but you had to manually manage Stop statements by commenting them out or removing them when you were finished. Further Stops cannot be set on a function or a memory address, making Stop a weak choice. Avoid using the Stop statement in general.

Suppose you have an iterative call or loop statement and you are getting an error. You don’t want to manually step through every iteration or call manually, especially if you suspect the error is occurring later in the iteration process. By using the Hit Count option you can set a breakpoint to break when a specific number of iterations have happened. The code in Listing 1 demonstrates a simple for loop with a breakpoint set when the hit count is 25 (see Figure 1).

  Private Sub HitCount()
    For i As Integer = 1 To 50
      Console.WriteLine("{0}: Break on 25", i)
    Next
  End Sub

Listing 1: A simple for loop with 50 iterations.



Figure 1: Adjust a breakpoint to break when that line of code is hit a certain number of times

To set the hit count breakpoint place the cursor on the line you’d like to break on. Right-click the breakpoint icon, click Hit Count, and select the desired option when the breakpoint is hit. You can choose from the following options: “break always”, “break when the hit count is equal to”, “break when the hit count is a multiple of”, or select “break when the hit count is greater than or equal to”. In the edit field enter the numeric value for the hit count option, and click OK. If you want to reset the current hit count click Reset before you close the dialog.

When you close the dialog the red graphical image will be replaced with a red graphical image with a + symbol in the center of the icon. The plus sign represents that the breakpoint has additional information associated with it.

If you want to see (or manage) all of the breakpoints in your project select Debug|Windows|Breakpoints to open the Breakpoints window. In Figure 2 you can see the break just set–it’s the first one–with the Condition and Hit Count information visible in the window.



Figure 2: The hit count breakpoint shows up in the breakpoints window, including the information relevant to the breakpoint

Defining a Breakpoint Condition

Going forward let’s agree that you can right-click on a breakpoint and access breakpoint options.

To set a condition just as you would use conditional code, click the Condition context menu item and write the condition–see Figure 3. In the code in Listing 2 File.Exists is used as a conditional test and Not File.Exists is used in the Breakpoint condition dialog to break only when the file doesn’t exist.



Figure 3: A breakpoint condition breaks when the condition is met or the condition has changed based on which radio option you select


  Private Sub BreakpointCondition()
    If File.Exists("dummy.txt") Then

      Dim info As FileInfo = New FileInfo("dummy.txt")
      Console.WriteLine(info.FullName)

    End If
  End Sub

Listing 2: Code that contains a conditional check for the existence of a file.

More by Author

Must Read