Continued: Popup edit in a dialog

[ATS]

> 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 
modified. 


C - A virtual function: 

   bool wxWindow::WantsEscape() 


D - Managing a pointer to the current editing window. The situation
is similar to that of popup menus (there can only be one active). 
Something like:

   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 
new cases. 

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. 

Thoughts? 


> A>   wxListCtrl::EndEditlabel( )
> A> 
> 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. 


Regards
// ATS. 

> 
>  Regards,
> VZ
>