In the old days of VB5/VB6 extensibility which used the Office commandbars model where there weren’t commands (only CommandBarControls) you had to create buttons (CommandBarButton) directly on commandbars, and you had to use the VBE.Events.CommandBarEvents(CommandBarButton) artifact to get the Click event of a CommandBarButton (you couldn’t even get the Click event using the more natural WithEvents clause).
Somehow this strange artifact got in the extensibility of the new Visual Studio .NET 2002 IDE (likely because it still used the Office commandbar model). However, in Visual Studio you have commands (EnvDTE.Command) and the recommended way is to create CommandBarButtons from commands (Command.AddControl), not directly on commandbars without a command (CommandBar.Controls.Add), and rather than getting a Click event when a CommandBarButton is clicked, you get a method (IDTCommandTarget.Exec) called when the command is executed. So, DTE.Events.CommandBarEvents is no longer necessary. There is still an scenario where you may want to create a CommandBarButton without an underlying command, for example the context menu of a listview of a toolwindow of an add-in, where you want the look and feel of the Visual Studio menus so you use a CommandBarPopup, but you don’t want commands. However, in this scenario you can use the Click event of the CommandBarButton class, without using DTE.Events.CommandBarEvents.
But people were still using DTE.Events.CommandBarEvents for another case: to know when a CommandBarControl which is a CommandBarPopup is clicked just before showing the children CommandBarButtons, presumably to set its state (enabled, disabled, invisible, etc.). Well, it happens that the new WPF-based commandbars of Visual Studio 2010 break that case, and this has caused some inconvenience to some people.This new article documents this problem:
PRB: COMException 0x80020003 getting events from commandbar popup in Visual Studio 2010
Fortunately the remedy is easy: use the IDTCommandTarget.QueryStatus method:
HOWTO: Controlling the state of command in a Visual Studio add-in