On Tue, 11 Mar 2008 22:47:52 +0000 (UTC) ATS <
asteinarson@...> wrote:
A> Testing this a bit more I found that EVT_CHAR_HOOK indeed triggers
A> on this situation. However, I encountered new problems:
A>
A> - When processing EVT_CHAR_HOOK I can either choose to:
A> 1 - Skip the event (and the whole dialog closes)
A> 2 - Not skip the event.
A>
A> With 1, if I skip it, wxDialogCmn does its thing. Not wanted.
A>
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...
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?
A> So... I tried a different alternative. Inside my EVT_CHAR_HOOK I
A> tested if it was a popup edit ctrl with focus, and then called the
A> function:
A>
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?
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@...
