Re: [lmi] Assertion 'GetEventHandler == this' failed

[Vadim Zeitlin]

On Thu, 16 Feb 2017 13:36:38 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-02-16 01:59, Vadim Zeitlin wrote:
GC> > On Wed, 15 Feb 2017 21:50:40 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> To reproduce:
GC> > GC>   File | New | Census
GC> > GC>   Census | Edit cell
GC> > GC>   change "Withdrawal" so that it holds an empty string
GC> > GC>   OK
GC> > GC>   Census | Add cell
GC> > GC> Now--in the census manager, without opening the tabbed dialog--click
GC> > GC> "Withdrawal" in each row until the ellipsis button shows. (You don't
GC> > GC> have to click the button--just make sure it shows, in both rows.)
GC> > GC> Then
GC> > GC>   File | Exit | No
GC> > GC> 
GC> > GC> I see a messagebox with the following contents (retyped manually
GC> > GC> because 'wine' doesn't seem to let me copy and paste them):
GC> > GC> 
GC> > GC> Assertion 'GetEventHandler == this' failed (any pushed event handlers 
must have been removed).
GC> > GC> [file ../src/common/wincmn.cpp, line 476]
GC> [...]
GC> >  Here is the commit which fixes the problem for me:
GC> 
GC> Committed and pushed. It prevents the problem noted above. However, it
GC> introduces another problem in the same circumstances: hovering over the
GC> ellipsis button causes the ellipsis button to vanish, apparently because
GC> it causes the editor to close.

 Very strange, I do not see this problem with neither MSVC build (with
which I had originally tested my changes, because I thought it wouldn't
matter which compiler is used for them) nor with the official build which I
just retested with 49ce3c03d0af4b7570b08a250ecbf8c305be6da7 (i.e. _without_
your last commit removing the tooltip). Could it be that it's some Wine
weirdness? In native MSW tooltip controls never get focus, so this couldn't
explain why would the editor hide itself.

GC> It also introduces a related problem: if you pop up a tabbed dialog to
GC> edit the cell, then click inside the "Withdrawal" textcontrol, then
GC> hover the mouse over the ellipsis button, the focus changes to the
GC> first control on the tab. Using 'skin.xrc', that first control is a
GC> checkbox, which is duly surrounded with a dotted-line highlight, but,
GC> oddly, there is still a blinking vertical-line caret in the
GC> textcontrol.

 Sorry, this is just yet another bug I introduced in
49ce3c03d0af4b7570b08a250ecbf8c305be6da7 when changing the direction of the
checks in the "if" and here is the fix for it:
---------------------------------- >8 --------------------------------------
commit 6c12995784d8daf6d2a494928979273c1ee00251
Author: Vadim Zeitlin <address@hidden>
Date:   Thu Feb 16 16:21:53 2017 +0100

    Let default focus event handling happen in InputSequenceEntry
    
    Never prevent the native text control from getting the event about the focus
    loss, whatever else we do, because this prevents it from hiding its caret 
when
    this happens and, more generally, puts it in an inconsistent state.

diff --git a/input_sequence_entry.cpp b/input_sequence_entry.cpp
index ec79885..c70697c 100644
--- a/input_sequence_entry.cpp
+++ b/input_sequence_entry.cpp
@@ -1491,6 +1491,10 @@ std::string InputSequenceEntry::field_name() const
 
 void InputSequenceEntry::UponChildKillFocus(wxFocusEvent& event)
 {
+    // Never prevent the default focus event handling from taking place,
+    // whatever else we do with it.
+    event.Skip();
+
     // Check whether the given possibly null window is a child of another one.
     auto const is_child_of = [](wxWindow const* c, wxWindow const* p)
         {
@@ -1507,7 +1511,6 @@ void InputSequenceEntry::UponChildKillFocus(wxFocusEvent& 
event)
         || is_child_of(wxGetTopLevelParent(event.GetWindow()), button_)
         )
         {
-        event.Skip();
         return;
         }
 
---------------------------------- >8 --------------------------------------
 

GC> Maybe we should just get rid of the tooltip.

 FWIW I disagree, I think tooltips are useful and should be used more, not
less, but I don't want to start a discussion about this. Still, if the
latest fix above is sufficient to resolve the problem that you're seeing
under Wine, perhaps you could bd0485e8450dcb7b8e21584630210ae9d0c889ff?

[still speaking about tooltip]
GC> It's needless, and it's problematic because by its nature it grabs
GC> focus

 But this is definitely not true, at least under "genuine" MSW.

 Regards,
VZ