WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> A> With 2, the dialog does not close, but neither does the popup text!
> A> The function wxKeyboardHook then just drops the key event and it never
> A> reaches the edit control. So it stays open.
> This looks like a bug but I don't see any good way to make this work, it
> looks like we need to add Allow() or Veto() method to wxKeyEvent to make it
> possible to specify what should happen next but I'm not especially happy
> about it...
The situation is not so common, so maybe better to fix at wxDialog level.
> A> A 3rd alternative would bo useful:
> A> 3 - Stop processing EVT_CHAR_HOOK but give the key event to
> A> the control that has the focus.
> Yes, definitely. The question is what would be the best API for it?
One can choose between:
A - wxDialogCmn being very smart and detecting the obvious cases.
Possible algorithm: Assume that _only_ direct children of the dialog
and any child wxPanel will want to be closed when WXK_ESCAPE is
pressed. Obviously this would only work for combinations of:
wxDialog : wxPanel* : wxSomeCtrl* : wxTextCtrl
(parent to child relations, * means can be nested several times).
But that would cover some ground and leave other file non-modified.
B - A style flag for wxWindow (say wxWANTS_ESCAPE). It's fairly easy
and to implement and logically clear. A number of files need to be
C - A virtual function:
D - Managing a pointer to the current editing window. The situation
is similar to that of popup menus (there can only be one active).
static wxTLW::SetPopupEditWindow( wxWindow *wnd )
In wxWindow destructor, check if we need to reset this pointer.
(in a way it's a harmless pointer since we only use it to compare
with a real living one). It would require some changes wherever
edit popup windows are used (wxListCtrl, wxTreeCtrl, ...)?.
My preference would be:
A or D - I think A is good enough and covers known cases.
D - Is a a nice general solution that extends more easily to
B - Better than C but flags can be messy. Implicit handling or
an API is more clear.
C - I'm not a fan of virtual functions for very limited things
like this. They add space to each type derived from wxWindow.
> A> wxListCtrl::EndEditlabel( )
> A> However... that function is broken on MSW.
> Hmm, it worked for me the last time I tested, did you test it outside of
> your application?
No. But calling ::DestroyWindow( HWND hwnd ) with the handle from the
popup text ctrl solved the matter.