Poor Man's Features

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:

1. Choose the “Tools.Macros.Macros Explorer...” menu item.
2. 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“.
3. Expand “MyMacros”, right click on “Module1“ and choose “Edit“.
4. 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.
5. Copy and paste the macros that appear at the end of this posting into the definition of Module1.
6. Now, switch back to the orginal VS IDE you started in and open the command window (View.Other Windows.Command Window).
7. 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
8. 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)
9. Disable one or more of your new breakpoints and type the following into the command window.
   • tagbps MyGroupOfBps1
10. Now enable/disable a different set of breakpoints in the breakpoint window and type the following command:
    • tagbps MyGroupOfBps2
11. 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

        Next

    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