Visual Studio and .NET Framework Home
Problems with ContextUIGUIDs and vsCommandDisabledFlagsValue in EnvDTE.Commands.AddNamedCommand
Carlos J. Quintero
as Won't Fix
5/11/2007 4:09:52 AM
User(s) can reproduce this bug
The EnvDTE.Commands.AddNamedCommand method does not honor ContextUIGUIDs and vsCommandDisabledFlagsValue. In fact, it does it in the reverse way. First, see the MSDN docs:
As the documentation states, if the add-in is not loaded, the ContextUIGUIDs and vsCommandDisabledFlagsValue parameters are used to know the state of the command (once loaded, the QueryStatus method will be used instead). If a ContextUIGUIDs is used and it is active, then the command should be enabled. If it is not active, then the command could be disabled or invisible and the programmer can specify it using the vsCommandDisabledFlagsValue. We will see that the AddNamedCommand does not behave as documented.
Visual Studio 2005 (All Products and Editions) Service Pack 1
Windows XP Professional
Operating System Language
Steps to Reproduce
Create a Visual Studio 2005 add-in using VB.NET ensuring during the wizard steps that:
- you DO check the checkbox that asks you whether to create a menu in the "Tools" menu, so your add-in receive the ext_ConnectMode.ext_cm_UISetup flag in the OnConnection method.
- you DON'T check that the add-in loads on startup.
Replace the code of the connect.vb file by the one attached.
The add-in creates two commands and buttons in the Standard toolbar. They should be enabled only when a solution is loaded in the IDE. Otherwise, one of them should be disabled and the other invisible.
Notice that the add-in is never loaded so we don't use QueryStatus.
When you debug the add-in project in a second IDE, the buttons are always disabled, whether there is a solution loaded or not.
The buttons should be enabled if a solution is loaded. If not, one of them should be disabled and the other invisible. There are two bugs here:
1) The "Disabled" button works as expected (enabled if solution loaded, disabled otherwise) if you specify STATUS_ENABLED for the vsCommandDisabledFlagsValue parameter of its AddNamedCommand call, instead of STATUS_DISABLED. However, this is wrong according to the docs (and the common sense), because the vsCommandDisabledFlagsValue is intended to tell the state of the command (disabled or invisible) if the context UI is not meet, not the other way around.
2) The invisible state is not honored. A similar bug was already acknowledged by MS for the QueryStatus method:
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 5/14/2007 at 5:07 PM
Thanks for reporting this issue. Unfortunately we will not be able to address this issue in Visual Studio codename Orcas due to time constraints.
The Visual Studio IDE Team
on 5/14/2007 at 12:53 AM
Thanks for your feedback. We have reproduced this bug on Visual Studio 2005 SP1, and we are sending this bug to the appropriate group within the VisualStudio Product Team for triage and resolution.
Visual Studio Product Team.
to post a workaround.
Please enter a workaround.
© 2013 Microsoft