Re: Continued: Popup edit in a dialog

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





---------------------------------------------------------------------
To unsubscribe, e-mail: wx-users-unsubscribe@...
For additional commands, e-mail: wx-users-help@...