Re[2]: Continued: Popup edit in a dialog

On Wed, 12 Mar 2008 00:32:30 +0000 (UTC) ATS <asteinarson@...> wrote:

A> > A> With 2, the dialog does not close, but neither does the popup text!
A> > A> The function wxKeyboardHook then just drops the key event and it never
A> > A> reaches the edit control. So it stays open.
A> >
A> >  This looks like a bug but I don't see any good way to make this work, it
A> > looks like we need to add Allow() or Veto() method to wxKeyEvent to make it
A> > possible to specify what should happen next but I'm not especially happy
A> > about it...
A>
A> The situation is not so common, so maybe better to fix at wxDialog level.

 I think I disagree. It's maybe not common but it's not specific to
wxDialog at all and could equally well happen in any other situation. E.g.
imagine a frame which uses this event to get F1 key presses inside it
(presumably to show some kind of help) and some window which wants to
handle F1 specially.

A> > A> A 3rd alternative would bo useful:
A> > A> 3 - Stop processing EVT_CHAR_HOOK but give the key event to
A> > A> the control that has the focus.
A> >
A> >  Yes, definitely. The question is what would be the best API for it?
A>
A> One can choose between:
A>
A> A - wxDialogCmn being very smart and detecting the obvious cases.

 I strongly dislike this both because of the above and because introducing
special cases like this is just not good for code maintainability.

A> B - A style flag for wxWindow (say wxWANTS_ESCAPE).
...
A> C - A virtual function:
A>
A>    bool wxWindow::WantsEscape()

 These don't work because this is not specific to escape.

A> D - Managing a pointer to the current editing window.

 And it's not specific to the editing window neither...

A> Thoughts?

 I still don't see anything better than allowing the EVT_CHAR_HOOK handler
to indicate whether it wants the key event to be generated or not. I.e. add
wxKeyEvent::AllowNextEvent() which would set some internal flag to true (it
would be false by default for compatibility). The strange name is due to
the fact that I think this would be also useful for EVT_KEY_DOWN handlers:
currently you have no choice about getting (or not) EVT_CHAR: if you skip
the event, you get, otherwise you don't (at least this is the way I believe
it works, I didn't test it). AllowNextEvent() could be helpful here if you
didn't want to skip the event (to prevent the base class event handler from
doing something with the key) but still wanted to get EVT_CHAR for it.

 This is simple to implement for all of wxMSW, wxGTK and wxMac (the code
for the last 2 is similar as EVT_CHAR_HOOK is generated by wx code) and I
don't really see anything wrong with doing it like this, do you?


A> > A>   wxListCtrl::EndEditlabel( )
A> > A>
A> > A> However... that function is broken on MSW.
A> >
A> >  Hmm, it worked for me the last time I tested, did you test it outside of
A> > your application?
A>
A> No. But calling ::DestroyWindow( HWND hwnd ) with the handle from the
A> popup text ctrl solved the matter.

 EndEditLabel() posts WM_CLOSE to it which should result in the same thing
(default window proc calls DestroyWindow() when it receives WM_CLOSE). I'd
be curious to know why this doesn't work in your case.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/


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