> A> > A> And it needs some method to decide that. (what I proposed
> A> > A> earlier are such methods).
> A> >
> A> > Yes, I didn't like them because they were too specific but something
> A> > generic along the same lines (e.g. a virtual NeedsKey() method) could do
> A> > it.
> A> How about this:
> A> 1 - We have a function wxKeyEvent::EmitNextKeyEvent()
> A> 2 - EVT_CHAR_HOOK is sent to to the active (focused) child window
> A> 3 - If not handled it propagates to its parent (up to first TLW).
I'll have a go at it. There are quite a number of files to modify. I'll let
it spin on my setting a couple of days before submitting a patch, to reduce
possibility of it breaking other keyboard handling.