Command Button in View.OtherWindows doesn't respect VisibilityConstraint

[pascalgyger]

Hi all
I'm working on an extension that provides several tool windows with their respective commands. I have set the commands to open the tool windows as DynamicVisibility and DefaultInvisible and provided a VisibilityConstraints with a context the hide/show those commands.
I found that this only works as long as I don't Initialize the command in my Package class. When I add the InitializeAsync command, the commands are always shown in the View.OtherWindows menu.

Strangely the same concept works for another set of commands with the same VisibilityConstraints that are added to the context menu in the solution explorer.

So my question is, if there is something specific to the commands that are added to the view menu, which causes the VisibilityConstraints to not work.

This is how my definition of the cmd looks in the VSCommandTable.vsct:

  <Button guid="ToolWindowCommands" id="ShowScreenExplorer" priority="0x0102" type="Button">
    <Parent guid="VSMainMenu" id="View.DevWindowsGroup.OtherWindows.Group3" />
    <Icon guid="ImageCatalogGuid" id="EntityContainer" />
    <CommandFlag>IconIsMoniker</CommandFlag>
    <CommandFlag>DynamicVisibility</CommandFlag>
    <CommandFlag>DefaultInvisible</CommandFlag>
    <Strings>
      <ButtonText>Screen Explorer</ButtonText>
      <LocCanonicalName>.View.ScreenExplorer</LocCanonicalName>
    </Strings>
  </Button>

[StevenRasmussen]

Looks like perhaps the code for the VisibilityContraint didn't make it in your original post?

As I understand it, the VisibilityConstraints are used by VS before the extension is loaded. Once the extension is loaded and the commands are initialized, then you need to handle the BeforeQueryStatus event of the command in order to determine whether the command should be shown or not. IIRC though, there was a way that you could specify to use the VisibilityContraint after the package was loaded as well... but I can't seem to find any documentation around it. I'm sure that someone else here can probably point you in the right direction. Also, are you using the ProvideUIContextRule found here?

[pascalgyger]

Thanks for the reply. Here is the VisibilityConstraint, for completeness, somehow I don't seem to be able to edit this in the original post:
<VisibilityItem guid="ToolWindowCommands" id="ShowScreenExplorer" context="TrioSolutionContext"/>

I guess using the BeforeQueryStatus would be an option, but I tried to use the simple approach with the VisibilityConstraint. I does work for other commands (and will toggle the visibility correctly based on the context), even after the package is fully loaded, so it seems strange that it doesn't work for the view menu entry.
I'm not loading the package based on the ProvideUIContextRule, because I'm actually setting a custom context from within the package (using this approach), but I will check if I could use a ContextRule instead as described in your link.

I'd still be interested to know why my original approach doesn't work.

[StevenRasmussen]

Without seeing all the code it's a bit hard to try and troubleshoot. That being said, I did find the bit of information that I was looking for before. I guess you're supposed to set the OleMenuCommand.Supported = false in order for Visual Studio to use the VisibilityItem for controlling the visibility. @madskristensen mentions why in the following video here. This is all pretty much guesswork on my part because I don't actually use any VisibilityItems in my extensions. I always just handle them manually via the events.

[madskristensen]

Right. Override the InitializeAzync method and set Supported = false on the Command object after calling await base.InitializeAzync.

Sorry, on my phone so I didn't check this

[yannduran]

Maybe this could be added as an optional parameter in the command's InitializeAsync method, so no subclassing etc is required? Being optional, it wouldn't affect anyone's existing code, and those developers who don't need it will never need to see it.

[pascalgyger]

I think that would make sense. The way it has to be done now, is not really easy to discover. With the optional parameter it would be clear immediately that something can be changed there.

[yannduran]

@StevenRasmussen nice catch on Mads talking about it in that video, I was watching at the time it was streamed, but It didn't register in my mind at all.

[StevenRasmussen]

I only remember because when he said it I thought that I should look into it for my own extension... so I made a note in a user story to come back to it 😄