locked
WPF events firing after VS shutdown RRS feed

  • Question

  • Hi,

     

    I have a VS package that offers a custom editor.  That editor hosts a WPF control.  Within that WPF control, I make use of the PreviewLostKeyboardFocus event.  The problem I'm running into is if I make a change in a control whose PreviewLostKeyboardFocus event is wired and immediately click on the X to close VS, then PreviewLostKeyboardFocus event is fired, but only after VS has started its shutdown operation.  I noticed that if I override QueryClose in my package, a breakpoint there is hit before a breakpoint in my PreviewLostKeyboardFocus event handler.  The result is that logic that I wish to have fired upon leave of the field does not occur in this scenario.

     

    Any suggestions on what I can do to ensure that my WPF event are always fired before VS shutdown?

    Thanks,

    Notre

    Friday, October 7, 2011 6:38 PM

Answers

  • Thanks for the info re: the VS message loop.  That would explain why Application.DoEvents doesn't help.

     

    Yeah, text boxes are the main type of controls that use LostFocus for databinding.  And yes, you are right that I could use PropertyChanged instead, but that would change the semantics of when data is committed (obviously) and change application behaviour.

     

    I made a change in my application such that I use standard data binding (based on LostFocus) for text box controls and modified a custom control from using PreviewLostKeyboardFocus to instead use LostKeyboardFocus.  In addition, I changed the logic such that on TextChanged event of any textboxbase control, I make the document marked as dirty (but don't commit changes to databinding until leave occurs).  So far, this combination of changes seems to be working okay, based on my testing.

    Thanks for you help,

    Notre

    Wednesday, October 12, 2011 10:21 PM

All replies

  • The core problem is that VS is not a WPF application 'all the way down'.  Specifically we run the message loop (in native code), not WPF.  We are likely getting/reacting to a WM_NCLBUTTONDOWN or similar message and doing some processing (i.e. starting the shutdown sequence) before ever passing the message (or subsequent) messages along to WPF.

    Focus is a nightmare in VS due to the mixing of UI frameworks (Win32, WPF, WinForms) and I would STRONGLY suggest not tying your behaviors to focus change events as you will see issues like this that are unavoidable (since VS has 'contracts' around when certain things occur that long predate any WPF usage in VS, so we can't simply give preference to WPF seeing/processing messages as it could cause things to happen 'out of order' from what previously working components (Win32/WinForms) were expecting).

    Ryan

    Sunday, October 9, 2011 7:52 PM
  • Hi Ryan,

     

    I understand and appreciate your explanation and warning.  (I'm also getting a sense of deja vu, that you might've warned me before on this :) ). 

     

    If I don't rely on focus (and events like 'leave'), what then can I tie my logic to?  Much databinding in standard controls (WPF, as well as WinForms, I think) occurs on leave of a field.  If databinding finishes after shutdown has started, I lose data :(

     

    Thinking that perhaps the message loop was in native code, I threw in a Application.DoEvents() call in my package's QueryClose handler, but that didn't help.

     

    Thanks,

    Notre


    • Edited by Notre Tuesday, October 11, 2011 6:56 PM
    Tuesday, October 11, 2011 5:38 PM
  • I don't think Application.DoEvents would do any good, it is WinForms, we run the message loop not WinForms.  Best case scenario it would try and push pending messages through, but that may or may not work depending on what we would normally do in our own message loop (it is far more complex than simply Translate/Dispatch).

    When you say databinding relies on lost focus, afaik that is true only for bindings to things like text boxes, and you can change that using an UpdateSourceTrigger on the binding of PropertyChanged, instead of LostFocus, for instance.

    Ryan

    Wednesday, October 12, 2011 9:58 PM
  • Thanks for the info re: the VS message loop.  That would explain why Application.DoEvents doesn't help.

     

    Yeah, text boxes are the main type of controls that use LostFocus for databinding.  And yes, you are right that I could use PropertyChanged instead, but that would change the semantics of when data is committed (obviously) and change application behaviour.

     

    I made a change in my application such that I use standard data binding (based on LostFocus) for text box controls and modified a custom control from using PreviewLostKeyboardFocus to instead use LostKeyboardFocus.  In addition, I changed the logic such that on TextChanged event of any textboxbase control, I make the document marked as dirty (but don't commit changes to databinding until leave occurs).  So far, this combination of changes seems to be working okay, based on my testing.

    Thanks for you help,

    Notre

    Wednesday, October 12, 2011 10:21 PM