(based on previous post about problems with editing labels inside a
wxListCtrl in a wxDialog).
Testing this a bit more I found that EVT_CHAR_HOOK indeed triggers
on this situation. However, I encountered new problems:
- When processing EVT_CHAR_HOOK I can either choose to:
1 - Skip the event (and the whole dialog closes)
2 - Not skip the event.
With 1, if I skip it, wxDialogCmn does its thing. Not wanted.
With 2, the dialog does not close, but neither does the popup text!
The function wxKeyboardHook then just drops the key event and it never
reaches the edit control. So it stays open.
A 3rd alternative would bo useful:
3 - Stop processing EVT_CHAR_HOOK but _give_ the key event to
the control that has the focus.
On GTK I could get away with manually forwarding the key event
to the popup edit, but on MSW, that doesn't work. The correct thing
to do here is clearly to continue natural processing of the event,
but semantics of event processing / skipping does not allow this.
So... I tried a different alternative. Inside my EVT_CHAR_HOOK I
tested if it was a popup edit ctrl with focus, and then called the
However... that function is broken on MSW. Instead of cancelling
the editing, it clears the popup edit window, and it remains open.
One solution to these problems would be if wxDialogCmn would detect
these cases and do the right thing. I can see two mechanisms for
A - Use GetClassInfo() and detect when a child of either a wxListCtrl
or wxTreeCtrl has focus and WXK_ESCAPE is pressed (a bit limited, but
they would be the most common cases).
B - A window style flag for this case. I'm not sure if wxWANTS_CHARS
could be used, or if that would trigger falsely. Something like
wxWANTS_ESCAPE or wxWANTS_ALL_CHARS.
C - A global pointer:
with an API around it. (A wxWeakRef<wxWindow> would be suitable here).
If there is no fix I'll have to do a WIN32 specific workaround for it.