Hi Rick,

I apologize for the late response. Things have been a bit busy around here
lately. You're suspicions are correct. There isn't a 100%

guarantee that you're going to get the right context menu in this instance.
At least not with the DTE automation interfaces.

As I mentioned in that earlier post Carlos mentioned, the DTE automation
model does allow for keying off the CommandBar name, but

those names are not unique. Using the CmdBrowser addin sample from

http://www.microsoft.com/downloads/details.aspx?FamilyId=79C7E038-8768-4E1E-
87AE-5BBBE3886DE8&displaylang=en, and you'll see multiple

commandbars with the same name. This is a known problem that the dev team
is working on correcting in some fashion for the next

release. But currently, we're stuck having to find all the CommandBars and
then guess which one is the right one based on the

commands it contains. And that isn't necessarily an exact mechanism for
retrieving the particular CommandBar you're looking for.

Especially given that people can reconfigure the commandbars.

The context menu you mentioned in your last post is actually implemented by
the HTML Editor package and is defined in that package's

embedded .CTO resource with the following guid:id pair:

  {D7E8C5E1-BDB8-11D0-9C88-0000F8040A53}:49

The only way to retrieve the menu (aka CommandBar) by way of this unique
identifier is with the IVsProfferCommands.FindCommandBar

method. You can retrieve this interface from your addin by way of code
similar to the following:

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

using Extensibility;
using EnvDTE;
using EnvDTE80;
using Microsoft.VisualStudio.CommandBars;

// note, you need to reference the Microsoft.VisualStudio.OLE.Interop.dll
// assembly, which contains the IServiceProvider we need to Query for the
// IVsProfferCommands service.
using IOleServiceProvider =
Microsoft.VisualStudio.OLE.Interop.IServiceProvider;

namespace GetCmdBar
{
  public class Connect : IDTExtensibility2
  {
     public Connect()
     {
     }

     public void OnConnection(object app, ext_ConnectMode mode, object
inst, ref Array custom)
     {
        _applicationObject = (DTE2)app;
        _addInInstance = (AddIn)inst;

        // retrieve IVsProfferComands via DTE's IServiceProvider
        IOleServiceProvider sp = (IOleServiceProvider)app;
        Guid guidSvc = new
Guid(typeof(IVsProfferCommands).GUID.ToString());
        IntPtr service;
        sp.QueryService(ref guidSvc, ref guidSvc, out service);
        IVsProfferCommands vsProfferCmds =
(IVsProfferCommands)Marshal.GetObjectForIUnknown(service);
        Marshal.Release(service);

        // retrieve the specific command bar we're looking for
        // (CMDSETID_HtmEdGrp:IDMX_HTM_DESIGN_TABLE)
        Guid guidCmdGroup = new
Guid("{D7E8C5E1-BDB8-11D0-9C88-0000F8040A53}");
        uint menuID = 49;

        CommandBar cmdBarTableContext =
(CommandBar)vsProfferCmds.FindCommandBar(IntPtr.Zero, ref guidCmdGroup,
menuID);
        Debug.WriteLine(cmdBarTableContext.Name);
     }

     public void OnDisconnection(ext_DisconnectMode disconnectMode, ref
Array custom) {}
     public void OnAddInsUpdate(ref Array custom) {}
     public void OnStartupComplete(ref Array custom) {}
     public void OnBeginShutdown(ref Array custom) {}
       
     private DTE2 _applicationObject;
     private AddIn _addInInstance;
  }
}

As a side note with respect to identifying the guid:id pair that a package
uses to create it's commandbars. Paul Harrington came up

novel way to help identify the guid:id pair by way of the IDE's Export
Settings feature. Martin Tracy's recently blogged about this

techinque at
http://blogs.msdn.com/martintracy/archive/2006/05/23/604927.aspx.
Hopefully, we'll have an even better solution come VS

2005 SP1, and Orcas, by way of a simple logging feature Paul enabled in the
core IDE sources a couple weeks back.

Sincerely,
Ed Dore [MSFT]

This post is 'AS IS' with no warranties, and confers no rights.