locked
Isolated Shell - change in behavior for "CloseAllButThis" RRS feed

  • Question

  • Environment:
    VSX-2010 isolated shell, custom project system using MPF

    Scenario:
    Our original code using VSX-2008 would trap and handle user command "CloseAllButThis" when it originates from the tab on a custom editor.

    It would come in on a HierarchyNode under the command:
            VSConstants.VSStd2KCmdID.CloseAllButThis.

    However - with our shell migrated to VSX-2010, our handler for "CloseAllButThis" is never called.

    The framework does all the work and all we see are the individual windows closing.

    Needless to say, this is not what we want (we have special semantics, which is why we handled this command in the first place).

    I'm been putting breakpoints and logging in all the likely suspects (any other IOleCommandTarget.Exec and QueryStatus) with no luck.

    Before I go to the trouble of disabling the command totally (using the "No_CloseAllButThisCommand" in the vsct stuff) then implementing my own menu item with the same name... 

    Has anybody seen this??
    And - anybody have an idea how else I can capture the command before the framework does its default handling?

    Thanks,
    Reed Shilts


    Thursday, December 16, 2010 8:25 PM

Answers

  • Well, I dug into it.  Something even simpler, the window manager is passing itself in as the context menu command target to IVsUIShell::ShowContextMenu.  It wasn't doing this in 2008.  I am filing a bug but I don't know how it will be resolved (I am kind of guessing 'Won't Fix', but that isn't up to me).

    Ryan

    • Marked as answer by Reed Shilts Monday, December 20, 2010 2:20 PM
    Thursday, December 16, 2010 11:37 PM

All replies

  • Without digging into it it is very hard to say what has changed.  The fact that your hierarchy node was getting the command before is somewhat strange to me, but I am assuming it was doing so because it was the active hierarchy in the selection context and either the document frame had not yet been activated or was not handling the command.  It may be the fact that the document frame gets activate slightly earlier (i.e. on right click) and this is causing it to be ahead of your active hierarchy node in the command routing.  But that is just speculation.  One way to entirely sidestep these nasty activation issues is to use IVsRegisterPriorityCommandTarget.

    Ryan

    Thursday, December 16, 2010 10:38 PM
  • Well, I dug into it.  Something even simpler, the window manager is passing itself in as the context menu command target to IVsUIShell::ShowContextMenu.  It wasn't doing this in 2008.  I am filing a bug but I don't know how it will be resolved (I am kind of guessing 'Won't Fix', but that isn't up to me).

    Ryan

    • Marked as answer by Reed Shilts Monday, December 20, 2010 2:20 PM
    Thursday, December 16, 2010 11:37 PM
  • Hi Ryan,

    Thanks for confirming this change in behavior.
    It looks like I'm stuck with totally removing the VS implementation and providing my own.....

    Regards,
    Reed Shilts

    Monday, December 20, 2010 2:23 PM
  • Or use IVsRegisterPriorityCommandTarget, that target will appear ahead of the 'injected' window manager command target thus you will get your callbacks via that target as you did in 2008.

    Ryan

    Monday, December 20, 2010 5:22 PM