this is a great tutorial. But i have a doubt. I have changed the the location of the commands to the menu tables of Server Explorer. And now the problem, how can i get the selected node in MenuItemCallback?

thank you very much

First, thanks for the article – it’s been very informative! I was trying to implement a toolbar that would only enable commands when a specific window was open, and since your “BeforeQueryStatus” from Part 2 worked so well for my menu items I tried again. The problem that I discovered is that toolbar buttons don’t fire the BeforeQueryStatus event, so you can not disable them that way. I went back to looking at the VisibilityItem and custom Context approach that you outlined here and I think I discovered how to avoid the problem that Kilpatrick described above (losing control when you add it to the IMenuCommandService).

Instead of using the IMenuCommandService and “Adding” commands to it, you can implement the IOleCommandTarget interface on your package class itself. Doing that doesn’t invalidate your contexts and the IDE will continue to enable/disable your commands when the context changes. (The toolbar buttons will not disappear, but menu commands do!)

To implement this interface, you only need to add two methods as outlined here:
int IOleCommandTarget.Exec(ref Guid pguidCmdGroup, uint nCmdID, uint nCmdexecopt, IntPtr pvaIn, IntPtr pvaOut)
{
//If it’s not your GUID, then say so.
if (pguidCmdGroup != GuidList.guidDynamicMenuDevelopmentCmdSetPart2)
{
return (int)Constants.OLECMDERR_E_UNKNOWNGROUP;
}
//If it’s not one of your comamnds, then say so.
if (nCmdID != PkgCmdIDList.cmdidCustomUIContext)
{
return (int)Constants.OLECMDERR_E_NOTSUPPORTED;
}
//This returns an error if someone requests “Help” for this command, but you have not implemented it.
if (nCmdexecopt == (uint)OLECMDEXECOPT.OLECMDEXECOPT_SHOWHELP)
{
return (int)Constants.OLECMDERR_E_NOHELP;
}
if (nCmdID == PkgCmdIDList.cmdidCustomUIContext)
{
//Add your code here to handle the command
}
return VSConstants.S_OK;
}

int IOleCommandTarget.QueryStatus(ref Guid pguidCmdGroup, uint cCmds, OLECMD[] prgCmds, IntPtr pCmdText)
{
//If it’s not your GUID, then say so.
if (pguidCmdGroup != GuidList.guidDynamicMenuDevelopmentCmdSetPart2)
{
return (int)Constants.OLECMDERR_E_UNKNOWNGROUP;
}
//If it’s not one of your comamnds, then say so.
if (prgCmds[0].cmdID != PkgCmdIDList.cmdidCustomUIContext)
{
return (int)Constants.OLECMDERR_E_NOTSUPPORTED;
}
//Additional code can be added here to more finely control the display
//See OLECMDF enumeration for more details.
return VSConstants.S_OK;
}

(NOTE: The IOleCommandTarget. prefix is added to the methods because the Package already implements IOleCommandTarget, but this forces the package to override that implementation.)

Now you can remove all references to the IMenuCommandService and the code associated with “Adding” your commands from the package initialization.

Thanks again for the great article, and I hope this helps!

Also, just my 2 cents, but I don’t think launching a dialog is a great experience for the end user in this case.

I would like to ask for your help about how can I override the command when the user clicks an item/file in the solution explorer.

For example:

the user click the Sample.vb code file then a dialog will be opened.

Thank you,
Gil Ballesca.

Thanks for the clarification and it looks like you’re right. When I implement the technique in Part 2 the command will be dynamic and I can also hook it up to a callback event. It’s a shame that I couldn’t use the technique as defined in Part 3. This would’ve worked well when dynamically displaying commands and menus based on the same criteria. Although I’m sure that I will find a way of doing the same using the technique in Part 2.

Thanks for the speedy reply as well!

Cheers!
Craig Wilson

Yes I do. Perhaps this info from the docs can help:

The VisibilityItem element determines the static visibility of commands and toolbars. Each entry identifies a command or menu and an associated command user interface (UI) context. The visibility is first controlled by the Visual Studio integrated development environment (IDE) without loading the VSPackage.

After your VSPackage is loaded, the IDE relies on your commands to determine their visibility instead of the static visibility defined in VisibilityItem. In an unmanaged VSPackage, implement QueryStatus; in a managed VSPackage, handle the BeforeQueryStatus event.

http://msdn.microsoft.com/en-us/library/bb491710.aspx

Looks as though we’ll have to use the technique in Part 2 for true dynamic menus…

Regards,
David

In addition to your response to Manish’s question. When I add the command to the IMenuCommandService (to handle the commands ‘click’ event’) the dynamic showing and hiding of the command ceases to function (it’s always displayed regardless). Do you experience this as well?

Cheers!
Kilpatrick