Originally I had a few posts planned to go over all the functionality of breakpoints. I’m surprised by how many of my fellow developers don’t understand the full range of abilities that breakpoints in Visual Studio provide. We all use breakpoints and most use conditional breakpoints but few seem to know about all the capabilities. I say, “originally I had a few points planned”, because while researching material for the post I ran across a series from Microsoft that goes over all the functionality of breakpoints. I don’t think I can expand further on what Microsoft has already written.
So without further ado, I would recommend you read,
- Breakpoints in Visual Studio 2013
- Hit Count Breakpoints
- Function Breakpoints
- Filter Breakpoints
- Tracepoints
- Conditional Breakpoints
- Data Breakpoints
To me I think the two must underutilized abilities of breakpoints are Function Breakpoints and Tracepoints.
Function breakpoints is really just putting a whole bunch of breakpoints across all of your code. For instance, referring you back to my series on the TPL and MVVM, I ended up with a bunch of samples all of which override “Run”. Say I wanted to step through all of the run methods to make sure everything is running as I expect? Well,
- just select the “New” dropdown in the breakpoint window
- select “Break at Function”
- enter “Run” as the function
- click “OK”
- click “All”
- click “OK”
and now breakpoints have been created on all the functions that matched that name. Of course a checkbox list is presented so I could individually select points in code rather than select all.
But say I was working on a bunch of UI stuff where there was an expected sequence of events to happen? And say that within that sequence, if I were to put in a regular breakpoint it would throw off the sequence so it no longer worked? Like if I was looking for or comparing mouse points or if the mouse was over another control, or had been moused out of a control? That is the perfect time for Tracepoints. Tracepoints output values to the debug window but optionally won’t actually stop (thus a tracepoint rather then a breakpoint). It’s kind of like putting in “Debug.WriteLine” but a whole lot cleaner, and it won’t accidentally get checked in.
Got any tips on breakpoints not mentioned in the posts above? Let me know.
Thanks,
Brian
