[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
Re: [XaraXtreme-dev] Keypress handling
- From: Phil Martin <phil@xxxxxxxx>
- Date: Mon, 08 May 2006 15:17:02 +0100
- Subject: Re: [XaraXtreme-dev] Keypress handling
Alex Bligh wrote:
In the case where a control and "the page" (the active view?)
yes, sorry, sloppy terminology.
same hotkey, the control would normally expect to get the first
use the keypress.
Isn't that the opposite of what we decided? For instance, a wxCheckBox
will claim a "space" keypress if given it.
Sorry, my scenario setup wasn't complete: I meant in the case where the
control has input focus - you'd then expect the control to get the
If I understand you correctly you're saying that a
central keypress filter should detect that focus is not in the page but
in a control and in that case, not let the page have the keypress first.
That is where I start to have issues with the idea because it's the thin
end of the wedge. More and more of those kinds of tests will inevitably
get added to the central keypress filter and it will become a rat's
No. I'm saying the application (which gets the chance to filter all
keystrokes), should determine if the focus is in a camelot window
(other than a modal dialog or a control within it), AND that the
window is not a keyboard-handling-control (wxTextControl etc.). If so
(with the exception of return, and ALT-F4 etc.) it should pass the
keystroke to the "page" (i.e. the active view) directly. If not,
it should just allow keys to follow their normal key-processing route.
That's more or less what I said and illustrates my point perfectly by
adding some special case exceptions already.
Much better to let individual objects make small decisions based on
knowledge (possibly statelessly) than have one big lump of stateful code
using information from many different sources.
But that means you will have to subclass every wx control which will
say the least painful. To avoid that, you end up with doing Connect() to
put an event handler on first. But that isn't very OO either, and misses
the point that the framework can eat the keypresses without them being
to any control.
In most cases a control's default behaviour will be fine (because you
are suggesting controls should claim all keypresses if they claim any).
No subclassing required.
That aside, I think wx provides mechanisms to handle events for controls
without subclassing them. See "Pluggable Event Handlers", P.29 of "the
Luke: In the case that incorrectly eats KeyDown events (when no view
window is open?), where is the input focus at the time?