A> > But it's true that it would be even better if it could be done
A> > automatically. And for this we indeed need to ask the focused window (and
A> > its parents) if it needs to intercept the key event even before
A> > EVT_CHAR_HOOK.
A> > A> And it needs some method to decide that. (what I proposed
A> > A> earlier are such methods).
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).
A> and in wxListCtrl and wxTreeCtrl we make a handler for EVT_CHAR_HOOK
A> that calls EmitNextKeyEvent() for the particular case of WXK_ESCAPE
A> and having a popup edit control open.
Yes. An alternative could be to push an event handler on the text control
used for editing but I don't see any big advantages to doing this.
A> There doesn't seem to be a wxListCtrlBase class
Unfortunately no. And this is unlikely to change now as it doesn't make
much sense to work on improving wxListCtrl when we have wxDataViewCtrl.
A> What wxEvent flag must be set to propagate just up to first TLW?
You need to set m_propagationLevel to wxEVENT_PROPAGATE_MAX in the derived
A> > A> Not being an API function it doesn't matter much to me.
A> > It's certainly part of wx API so it would be nice if it worked... As the
A> > comment there says, normally sending WM_CANCELMODE should do the trick but
A> > it didn't do it for me. Maybe you should try changing the code to do it.
A> Nope, just checked listctrl.h and it's not in there. It's only defined
A> and used in the MSW case. It is part of treectrl.h though.
Hmm, you're right and I didn't even know about this. IMO we should provide
it in all ports but seeing that nobody asked for it so far it's probably
not that urgent...