Advanced breakpoints

In a previous chapter, we set the first breakpoint and it was good. However, there is actually more to breakpoints than that, at least if you're using Visual Studio. Unfortunately, it seems that Microsoft has disabled these extra debugging features in some of their Express versions, but don't worry: They are certainly nice to have, but you can get by without them. However, for those with access to Visual Studio, here is the most interesting breakpoint related features. You get access to them by setting a breakpoint, right-clicking it with the mouse and then selecting the desired function.

Condition

This option allows you to specify a condition that has to be true or changed, for the breakpoint to be hit. This can be really useful when dealing with more advanced code, where you want the execution to stop only under certain circumstances. For instance, you might have a loop that iterates a bunch of time before the relevant code is reached - in a situation like that, you could simply place a breakpoint and then configure an appropriate condition. Here is a rather boring example, which will show you how it works:

static void Main(string[] args)
{
    for(int i = 0; i < 10; i++)
        Console.WriteLine("i is " + i);
}

Set a breakpoint on the line where we do output to the console. Now run the application - the breakpoint is triggered each time the loop iterates. But perhaps that's not what we want. Maybe we only want it to be hit when i equals 4 (the 5th iteration). Do that by defining a simple condition like this:

i == 4

The breakpoint will now get a little, white plus inside it and when you run the application, it will only break when the i variable equals 4. You can also use the "has changed" option to instruct the debugger to only halt the execution if the result of the above statement has changed, for instance from false to true.

Hit count

With this dialog, you can define an alternative condition, based on the amount of times the breakpoint has been hit. For instance, you can decide that your breakpoint should not halt the execution until it has been hit a certain amount of times. There are various options to control this, depending on what you need, and during debug time, you can check this dialog to see how many times the breakpoint has been hit so far.

When hit...

Using this dialog, you can define alternative behaviour for when your breakpoint is hit. This can come in handy in lots of situations, where you don't want the execution to stop, but simply get a status message printed or a macro activated. It allows you to define a custom message which will be printed, where you can include all kinds of information about the execution. For advanced users, the option to get a specific macro executed when a breakpoint is hit will also be useful.