David DeWinter

In this post I’ll be building on the principles of my last post with dynamic menu development in Visual Studio, so if you haven’t read that post please go back and check it out!

If you remember from last time, we were able to create a dynamic menu command without any lines of procedural code (other than those generated by the wizard). The result was a menu command that showed itself only when no solution was loaded in Visual Studio. Immediately a solution was loaded, the menu command disappeared. The limitations of this approach are that you’re reliant on built-in UI contexts, such as UICONTEXT_NoSolution. However, what I needed for my DBML Fixup project was a way to add menu commands when right clicking on .dbml files (LINQ to SQL Classes) in the Solution Explorer. The built-in UI contexts that we reviewed in the previous post are not enough to give us this functionality. In this tutorial, I take you through step-by-step on how to add this feature to your VS packages. We have to do a bit of digging though, so let’s get started!

The first thing we need to do is to create a new a menu command using our existing solution. Because we don’t have the wizard to help us this time, we’ll have to create our menu command from scratch.

Step 1: Creating the New Command

Our first step is to create the GUID:ID pair that Visual Studio will use to identify our new menu command. The GUID represents a set of commands (or command set) exposed by this package; one of these was created by the package wizard when the solution was generated. However, for this part of the tutorial, we’ll go ahead and create a new command set in the Guids.cs file. (We can get a new GUID from the Tools > Create GUID menu item.) Afterwards, my Guids.cs file looks like this:

Pardon the unoriginal name of "CmdSetPart2." The next step is to add an ID that maps to the specific menu command we are going to add. This can be changed in the PkgCmdID.cs file in our project. Here I will add the cmdidQueryStatusCommand with a value of 257:

So that was fairly simple, but obviously we haven’t registered it with Visual Studio, so there’s no way the Visual Studio shell will know about this menu command. To do so, we need to make some amendments to the .vsct file. The first of these changes is to identify the new menu command GUID and ID pair in the Symbols section, so that we can reference it elsewhere. This is also easy to do and requires a few lines of XML, which can be added as any first-level child of the Symbols node:

As you can see, this information is based directly off the two previous steps. The "guidDynamicMenuDevelopmentCmdSetPart2" command set has the same GUID as in our GuidList class, and the "cmdidQueryStatus" menu command ID has the same value as in the PkgCmdIDList class.

Our objective is to show this menu command when we right click on DBML files in the designer; this means we’ll need to create a new Group element whose parent is the Solution Explorer’s context menu. Then we’ll need to create a Button element to put in that Group, which represents the menu command itself. This doesn’t seem like such a problem, until you try to define the Group’s parent…

What goes in the place of the question marks? Well, we might be able to find it in one of the copious header files that sits in the Visual Studio SDK’s VisualStudioIntegration\Common\Inc directory, but I’m willing to bet that there’s a faster way. And it turns out there is. Looking at Dr. eX’s blog entry on VSIPLogging reveals that a simple registry key will allow you see to the GUID:ID pair of almost any menu command in Visual Studio, including those developed by third parties. Changing this setting in the registry and relaunching Visual Studio allows us to check what the GUID and the ID we need are; as it turns out, holding the Ctrl+Shift keys down and right clicking on a project item in the Solution Explorer gives us the information we need:

We can use this information to fill in the Parent’s details, but we’ll need to register the GUID and CmdID in the GuidSymbols element in our .vsct file first.

The Button element isn’t too exciting by comparison; in fact it doesn’t differ much from the Button element from the last tutorial. I include it here for reference:

OK, that’s it for the .vsct edits. Notice that our Button element still has the "DynamicVisibility" flag, but we have not specified a visibility constraint; this is because we will handle the changes ourselves in procedural code. The final thing we have to do to finish the "plumbing" work by creating our menu command and an event handler to handle its invocation. I’ll add this code in the DynamicMenuDevelopmentPackage.cs file in the Initialize method. If you navigate there, you’ll see the wizard-generated code for the first menu command. It’s only a few lines of code to hook everything together with our second menu command:

One thing to note here is that in contrast to the first menu command, we are creating an OleMenuCommand, not a regular MenuCommand. The reasons will become apparent later, but for now, let’s press F5 to see what we’ve got. Open an existing solution (or create a new one if it’s easier to do so) and right click on a project item (not a folder, project, or solution node, though) and you will see our "Query Status" command:

Step 2: Making It Dynamic

As expected, though, it shows up regardless of the selected item in the project, so we haven’t reached the end yet! Going back to the code in DynamicMenuDevelopmentPackage, we discover a use for the OleMenuCommand vs. the MenuCommand. The OleMenuCommand exposes an event called BeforeQueryStatus, which is raised right before Visual Studio asks what the state of a particular menu item is. In this case, it’s a perfect place to edit the state of our menu command based on the current selection in the Solution Explorer. Adding the following event handler to the BeforeQueryStatus event of that OleMenuCommand helps us achieve our desired goal:

I won’t explain all the code here, but the gist is that we are getting the name of the current selection, checking if it ends with the ".dbml" extension, and dynamically setting the visibility on our menu command based on that result. Unfortunately, this is still not enough to correctly implement our dynamic menu command, due to the fact that Visual Studio loads packages on demand. To make a long story short, the code that we just wrote to handle dynamic menu item visibility will be called only when the package is loaded, and the package is loaded only when some UI element exposed by the package is clicked, which invokes some piece of code in the underlying package. This does not really help us when all the package exposes is two menu commands!

This is a problem that I encountered recently, and consequently I am open to any suggestions. My solution has been to put the ProvideAutoLoadAttribute on the class, which tells Visual Studio to load the package automatically when it encounters a certain UI context. In this circumstance, the context "UICONTEXT_SolutionExists" (defined in vsshlids.h) suits our purposes perfectly. We’ll have to specify the GUID itself instead of its alias, however, like this:

And that’s it! Press F5 and open a solution to see for yourself. The "Query Status" command will appear only when right-clicking on .dbml files in the Solution Explorer.

Associated Solution

Other Articles in the Series

• Part 1 - Using UI Contexts
• Part 3 - Custom UI Contexts

This entry was posted on Saturday, March 22nd, 2008 at 9:20 pm and is filed under DBML Fixup, VSX, Visual Studio 2008. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.