locked
Visual Studio 2010 won't quit RRS feed

  • Question

  • Hello,

    Rarely and after a while of using Visual Studio with my plugin, Visual Studio refuses to quit - Clicking the X close button or using the File->Exit simply do nothing. Every other function of Visual Studio continues working fine.

    It seems that my code isn't being called when that happens (nor should it) and I didn't see any exception (managed or native) occurring when I try to exit.

    I'd appreciate any suggestions to what may cause this behavior.

    Thank you!
    Vitaly

    Sunday, January 22, 2012 12:21 PM

Answers

  • >Please let me know if you see something that that can cause the no-quitting-issue.

    This is wrong:

    public int FQueryTerminate(int fPromptUser)
    {
        return VSConstants.S_OK;
    }

    FQueryTerminate returns a native bool (i.e. an int) which idicates if the application can close or not.  S_OK is 0, a native bool whose value is 0 is like saying false, you can't terminate.  This method needs to return 1 (well, actually any non-zero value).

    That said, doing things like this in VS is generally highly frowned upon. If you want modeless windows make them into actual VS toolwindows, that way they work inside VS without needing this kind of hackery. The Find in Files dialog is a VS toolwindow yet it behaves by default like a modeless window (more or less), except it can be docked, and automated via DTE, etc..

    Your windows don't interact with VS in any way and kind of stick out, along with possibly breaking a lot of things like this. Another thing they likely break is any sort of registered idle tasks, which is a bad thing since code parsing and all kinds of other things happen on idle.

    Ryan

    Wednesday, January 25, 2012 12:29 AM

All replies

  • Does File->Exit still work?  If not it sounds like the shell doesn't believe it is proper to exit.

    In general closing VS is a query that folks can cancel. This opportunity it used to do things like ask if you want to stop debugging (if you are debugging) and ask if you want to save unsaved items.

    If File->Exit works and the window chrome doesn't it sounds like there may be some issue with the windows messages getting to our wndproc. You aren't subclassing the main window are you?  Or installing any kind of wndproc hooks that could be preventing windows messages from getting through?

    Other than that, I have seen issues where components call IVsUIShell::EnabledModeless(FALSE) and never call EnableModeless(TRUE), making the shell think it is in a modal state internally and preventing shutdown.

    Ryan

    Sunday, January 22, 2012 6:04 PM
  • Does File->Exit still work?  If not it sounds like the shell doesn't believe it is proper to exit.

    In general closing VS is a query that folks can cancel. This opportunity it used to do things like ask if you want to stop debugging (if you are debugging) and ask if you want to save unsaved items.

    ...

    Other than that, I have seen issues where components call IVsUIShell::EnabledModeless(FALSE) and never call EnableModeless(TRUE), making the shell think it is in a modal state internally and preventing shutdown.

    Ryan

    Hi Ryan,

    Thanks for the informative reply!

    File->Exit indeed doesn't work, so I guess it very might be a callback, like one you've described. I am pretty sure I don't do it, but just to be able to check: How do I preview & cancel a VS close query?

    Also, I searched and I am not using the EnabledModeless, but I do have quite a few modal windows. Obviously I close them prior trying to close Visual Studio, but perhaps there is some glitch in that area?

    Thanks!
    Vitaly

    Sunday, January 22, 2012 9:48 PM
  • >How do I preview & cancel a VS close query?

    IVsPackage::QueryClose and/or IVsPackage2::get_CanClose, more likely the former, the latter is a newer interface and intended to be used to prevent a forced shutdown. I don't believe MPF derived packages would implement that, though they do implement QueryClose as a virtual method, the default always returns true via the out param.

    >but I do have quite a few modal windows

    How are you displaying modal windows without using EnableModeless?  Are you deriving from a class that does this for you like DialogWindow?

    Ryan

    Monday, January 23, 2012 1:34 AM
  • > IVsPackage::QueryClose and/or IVsPackage2::get_CanClose

    Thanks! I will look into these functions.

    > How are you displaying modal windows without using EnableModeless?

    We are simply deriving from System.Windows.Window (WPF) and using the ShowDialog function. Could it be a problem?

    EDIT: I forgot to mention that for some of our windows (both modal and modaless) we're using ModelessWindow.cs as our base class that we got from the following Connect issue. Could it be the culprit?

    Thanks!
    Vitaly


    Monday, January 23, 2012 11:46 AM
  • >We are simply deriving from System.Windows.Window (WPF) and using the ShowDialog function. Could it be a problem?

    How are you parenting the window? I highly doubt this is actually working as intended, i.e. I doubt VS is modal. Windows, when showing a modal dialog, only disables the parent window. VS can have multiple top level windows (say an undocked (floating) toolwindow or document). If you show a dialog via WPF ShowModal without parenting it I don't believe it will disable anything (or maybe it will disable something like Application.Current.MainWindow), that means your dialog could end up being hidden by another top level window, since said window was not properly disabled. I would look into deriving from DialogWindow in MPF as it knows what it takes to go modal in VS, WPF has no clue in that regard.

    > I forgot to mention that for some of our windows (both modal and modaless) we're using ModelessWindow.cs as our base class that we got from the following Connect issue. Could it be the culprit?

    I don't know who wrote the Connect response and I don't see the 'attached file' they are referring to, so I can't comment on it. Mucking around with IOleComponent can certainly cause things to 'go bad' if you don't do it correctly.

    Ryan

    Monday, January 23, 2012 4:01 PM
  • > If you show a dialog via WPF ShowModal without parenting it I don't believe it will disable anything...

    I see what you mean, we'll try using DialogWindow instead. Thanks!

    > I don't see the 'attached file' they are referring to

    Sorry about that, here is the content of ModelessWindow: https://gist.github.com/4e30e353811d856f3efe
    Please let me know if you see something that that can cause the no-quitting-issue.

    Thanks for your help!
    Vitaly

    Tuesday, January 24, 2012 11:34 AM
  • >Please let me know if you see something that that can cause the no-quitting-issue.

    This is wrong:

    public int FQueryTerminate(int fPromptUser)
    {
        return VSConstants.S_OK;
    }

    FQueryTerminate returns a native bool (i.e. an int) which idicates if the application can close or not.  S_OK is 0, a native bool whose value is 0 is like saying false, you can't terminate.  This method needs to return 1 (well, actually any non-zero value).

    That said, doing things like this in VS is generally highly frowned upon. If you want modeless windows make them into actual VS toolwindows, that way they work inside VS without needing this kind of hackery. The Find in Files dialog is a VS toolwindow yet it behaves by default like a modeless window (more or less), except it can be docked, and automated via DTE, etc..

    Your windows don't interact with VS in any way and kind of stick out, along with possibly breaking a lot of things like this. Another thing they likely break is any sort of registered idle tasks, which is a bad thing since code parsing and all kinds of other things happen on idle.

    Ryan

    Wednesday, January 25, 2012 12:29 AM