Poor Man's Features

Article
01/28/2004

Just like any software development company, the individual teams at Microsoft frequently find themselves needing to cut features for the sake of shipping their product. If we don't do this, an incurable and contageous mood altering phenomenon called needitnowosis develops in one or more disgruntled users but quickly spreads throughout the entire community. The only known treatment for this disease is phewweshippeditcillin_{tm (Microsoft Corp)} .

Many users simply recover from their symptoms for a few years before succombing to the symptoms again. Others, start to recover, only to fall into a worse condition called butwhataboutXfeaturism.

Oh I realize that not everyone has the sophisticated medical background I have, so in laymen's terms, “shipping“ becomes THE FEATURE all users request more than any other. Decisions have to be made as to what stays and goes so that shipping can be our only focus. Some users will wish our product had that feature X that didn't avoid the cut list.

Fortunately, Visual Studio 2003 sports an extensive automation model that can be used to “create“ that feature you might be missing. Of course, having to write more programs to do your development probably isn't at the top of your todo list. So I'd like to provide some useful macros for you to use as is or as a way to get you jump started.

With that, here's my first entry.

Breakpoint Groups

Recently, and internal developer at Microsoft asked if the debugger had any feature that would allow him to easily switch between a set of breakpoints for a single project. Unfortunately, there is no way to easily do that through any sort of user-interface mechanism. It would likely wind up in a feature called Breakpoint Groups that may someday get shipped. But all is not lost. By creating the following macros and aliases, a similar feature can be created. Better yet, if it doesn't quite suit your needs you can modify it to your heart's content.

Add the following two macros to the MyMacros project inside Visual Studio 2003. You can access the MyMacros project by:

Choose the “Tools.Macros.Macros Explorer...” menu item.
If you've never used this capability before you should see a new toolwindow with a treeview in it. There will be two nodes listed under the Macros root node, “MyMacros“ and “Samples“.
Expand “MyMacros”, right click on “Module1“ and choose “Edit“.
A new IDE will open that appears astonishingly like the Visual Studio IDE you're used to. It actually IS running much of the same code but it is limited in that it only supports writing, running and debugging macros. Macros are currently written in VB (but with some finagling you can access the automation model using any language, if it doesn't need to be a macro). The IDE supports everything you'd expect when doing VB development, namely Intellisense. This feature allows even VB newbies to make quick and easy progress.
Copy and paste the macros that appear at the end of this posting into the definition of Module1.
Now, switch back to the orginal VS IDE you started in and open the command window (View.Other Windows.Command Window).
Enter the following two commands into the command window. These aliases give you quick access to these two macros.
- alias tagbps Macros.MyMacros.Module1.TagEnabledBreakpoints
- alias enablebps Macros.MyMacrosModule1.EnableTaggedBreakpoints
You're pretty much ready to group some bps at this point! Set and enable some breakpoints, and open the breakpoints window (Debugger.Windows.Breakpoints)
Disable one or more of your new breakpoints and type the following into the command window.
- tagbps MyGroupOfBps1
Now enable/disable a different set of breakpoints in the breakpoint window and type the following command:
- tagbps MyGroupOfBps2
To enable each breakpoint group, you can just enter one of the following commands whenever you please:
- enablebps MyGroupOfBps1
- enablebps MyGroupOfBps2

Here's the macros! I hope you find these useful. If you make some cool modifications or come up with some other useful macros, feel free to post them here! Oh, remember that “Samples“ node I kinda ignored at step 2? You might want to check it out now too.

Sub TagEnabledBreakpoints(Optional ByRef strTag As String = "Tag1")

Dim bps As EnvDTE.Breakpoints

bps = DTE.Debugger.Breakpoints

If (bps.Count > 0) Then

    Dim bp As EnvDTE.Breakpoint

    For Each bp In bps

        If (bp.Enabled = True) Then

            bp.Tag = strTag

        End If

    Next

Else

    System.Windows.Forms.MessageBox.Show("Can't find any breakpoints to tag")

End If

End Sub

Sub EnableTaggedBreakpoints(Optional ByRef strTag As String = "Tag1")

Dim bps As EnvDTE.Breakpoints

bps = DTE.Debugger.Breakpoints

If (bps.Count > 0) Then

Dim bp As EnvDTE.Breakpoint

For Each bp In bps

If (bp.Tag = strTag) Then

bp.Enabled = True

Else

bp.Enabled = False

End If

Else

System.Windows.Forms.MessageBox.Show("Can't find any breakpoints to enable")

End If

End Sub

Comments

Anonymous
January 30, 2004
Thank you for your article. Your breakpoint group is good idea, but your macro source code doesn't work. In TagEnabledBreakpoints, 'For Each bp In bps' code generates 'QI for IEnumVARIANT failed on the unmanaged server.' message. Why?

Visual Studio .NET 2003/Korean version/I had two break points in my C# project(one is enabled, another is disabled)
Anonymous
January 30, 2004
If I change your code like following, it works! Why??

Dim count As Integer
count = 1

' DO NOT USE For each
' Just use Do While
' Why?
Do While (count <= bps.Count)
bp = bps.Item(count)
count = count + 1
If (bp.Enabled = True) Then
bp.Tag = strTag
End If
Loop
Anonymous
February 01, 2004
That's very interesting, I tried these macros on two different machines each having VS 2003 installed. Both ran through the macros without problem.

So, I'm not sure why it didn't work for you. It could just be a bug on our end... maybe having something to do with the Korean translation of the product. I'll notify our QA people here to try and reproduce the problem.

BTW, the difference between the original method of walking through the bps and your version is that the original ends up returning an IEnumVARIANT interface to the macro engine to walk through the list of BP's. Your version bypasses that method and does a straight lookup of the bp at the index specified using the Item() function. The implementation of Item() is under no obligation to make use of any IEnumXXXX interface.
Anonymous
February 02, 2004
'I'll notify our QA people here to try and reproduce the problem.'

Thank you. If you have any information related in this topic, please leave comment. I am just wondering what's going on. And I will check this article daily. Am I missing something? (I hope, I'm not)
Anonymous
February 03, 2004
Well, QA has spoken. They have tried this scenario on English, Japanese, and finally Korean to find that they cannot reproduce Woo's error.

Woo, Make sure the version listed for the file vsdebug.dll is 7.10.3077.0. You should be able to find that at D:Program FilesMicrosoft Visual Studio .NET 2003Common7PackagesDebugger. If that's the case, then I'm really stumped. It could be that a reinstall of VS could cure the problem if it's some sort of file or registry corruption issue. It would also be interesting to try some of the other collection-type objects to see if this is specific to the breakpoints collection or if it's a general problem.
Anonymous
February 04, 2004
Hmm, my vsdebug.dll version is 7.10.3077.0. Exactly. I will try some of the other collection-type objects and later I will post my results. Thank you.
Anonymous
June 09, 2009
PingBack from http://toenailfungusite.info/story.php?id=9079

Share via

Poor Man's Features

Comments

Additional resources