Do you have ideas for a workaround for this Known bug in Visual Studio 2010's addIn model?

When developing AddIns for Visual Studio 2010 the following line fails:

CommandBarEvents handler = (EnvDTE.开发者_JAVA技巧CommandBarEvents)m_VSStudio.DTE.Events.get_CommandBarEvents(popup);

Update: Forgot to tell that m_VSStudio is of the type DTE2

Where popup is of the type CommandBarPopup (for the type CommandBarControl it works though)

The line fails with this Exception:

System.Runtime.InteropServices.COMException (0x80020003): Member not found. (Exception from HRESULT: 0x80020003 (DISP_E_MEMBERNOTFOUND))

The exact same line worked in Visual Studio 2008.

The purpose of the line is to get a handler which handles clickevents, when one clicks the Popup.

After som searching I found this link: http://connect.microsoft.com/VisualStudio/feedback/details/524335/events-get-commandbarevents-exception-on-submenus-reproducible-bug-addin

Which basicly states that it is a known bug, which will not be fixed, because there is a workaround. But unfortunately it does not state the workaround :(

I would be extremely pleased if anybody has a great idea for a workaround ?

The reason why I want to listen to the click events is because I want to show or hide the submenuitems (CommandBarControl) given some condition, when one clicks a menu (CommandBarPopup).

So a workaround that uses something else than the click event would also be appreciated.

---

Jesper and I talked about this in e-mail. What he was trying to do was ensure that members of a popup menu that he created were in the proper state right before they were shown. He was using the Click even on CommandBarPopup (which was deprecated in 2010 in the move to WPF) to have a way of knowing when he needed to do the state updating. I mentioned the preferred method for doing this (even in 2008) would be to implement IDtCommandtarget on his AddIn class. The VS shell will call this method when it needs to find the status of commands. It will call this method at all the 'regular' times it updates command state (i.e. on idle if needed, right before showing a menu, etc..). Moving to this method works for his scenario and seems to solve his problem.

Ryan

---

It is unfortunate that the phrase 'our e-mail correspondance' and 'you found a workaround' was put in a public bug with no indication of what the work around was. I suspect the person was trying to do something quite different from you (even if he was using the same event mechanism to hook in), so perhaps we found a better way to do what he needed. I can't think of any easy way to do what you are doing, though if I understood why you were trying to do what you are doing (i.e. are you hiding your own commands? The commands of other people? To what end?) then perhaps we could think of something. Feel free to mail me directly, address is rmolden AT microsoft DOT com, sorry for the inconvienence. We can also follow up here with any work around we find so it will be captured by the internet rememberance machine for all time.