[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Keypress handling

Alex Bligh wrote:


Phil,


In the case where a control and "the page" (the active view?)



yes, sorry, sloppy terminology.


claim the
same hotkey, the control would normally expect to get the first chance to 
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 keypress first. 




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 nest. 


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 local 
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 be to 
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 sent 
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 book"...
Luke: In the case that incorrectly eats KeyDown events (when no view window is open?), where is the input focus at the time? 

Phil