During my presentation about Visual Studio extensibility I found out that a lot of developers are not fully aware of the powers of the break point. I plan to help correct this and demonstrate the wonders of the Visual Studio debugger for all to see.
Generally speaking most developers get along in life by either clicking on the left most column in the editor or hitting F9 to create a break point. This creates a location break point which will cause the debugger to stop on the line of code. Every single time it visits the line.
You can live this way pounding F10 until the bones in your index finger grind themselves down to dust. Or you can take the small step beyond and use the four other break points available to get your job done.
The first one to consider (and my personal favorite) is the conditional break point. As the name implies it causes the debugger to stop if conditions are met. To get this type of breakpoint, first click in the left gutter or hit F9 and then right click on the red dot (or go through the menus if you prefer). A context menu will pop-up offering you several choices. For now go with Condition. In the dialog there is a text box for you to enter the condition. You can have some fun here because you can call functions, create Boolean expression and compare things. For instance you could have a function that returns a bool value that goes out and determines if you are close to the last record in a database. If you are then it returns true (say for the last 5 records or the last name of the record == "Jones"). Or you could just compare two values say Record.LastName == "Jones".
Also pretty cools it that you can set the break point to only break if a variable changes. C++ developers should find this one useful. To demonstrate it, setup the breakpoint for _SomeVariable. When your program starts it is set to false, on a button even you change _SomeVariable to true. When that happens the debugger will break. You still have to set the break point's location to the line that is changing the value but that is pretty minor.
Next up is the Hit Count break point. This one is really is to use in loops, throw down the dot, set the count to whatever value you need and let your code go. The debugger will stop when it has passed the break point however many times you set. This isn't just useful in loops though. If you have a function that should only be called one time, a hit count break point would be pretty useful to catch that second call the blue screens your workstation.
Filter breakpoints (like the abrupt transition?) are used for multithreaded debugging. You can specify which thread you want the breakpoint associated with. I've not played with this one so I'll not shoot my toes off talking about it more.
The last break point - When Hit - is pretty cool. This break point allows you to call a Macro from the break point. Via the dialog you can also have it print out a debug trace statement so you can follow the execution of your code.
I'm also posting a video of this presentation on YouTube. The program is still encoding it so it won't be available until tomorrow (probably). The presentation materials are also going up. If you would like to use them please contact me.