The Control can have a KEYDOWN event, and if you return FALSE, it pass the key up to the window
but it seems there is no way to have the Window pass it on… as APP has no KEYDOWN event
So if Window returns False and Control returns False, the key event just goes into Limbo? I was hoping to pass certain keys to a central method without doing much.
example
Control.KeyDown : if key="Q" then return false
WIndow.KeyDown : return false [the default]
App?????.Keydown : do something
[quote=407539:@Dave S]a typical app structure might be
APP -> WINDOW -> CONTROL
The Control can have a KEYDOWN event, and if you return FALSE, it pass the key up to the window
but it seems there is no way to have the Window pass it on… as APP has no KEYDOWN event
So if Window returns False and Control returns False, the key event just goes into Limbo?[/quote]
A description of Xojo’s event model would be nice. What actually happens appears to be ad-hoc and incompletely described.
[quote]I was hoping to pass certain keys to a central method without doing much.
[/quote]
I don’t actually see any reason why all controls (and APP itself) don’t have such user-initiated events available to them, a bit like the HTML DOM. It would make life a lot easier. If a control doesn’t want the event, then don’t create a handler for it. Event handlers should have the choice whether to pass the event up, by returning TRUE/FALSE.
What I meant was that returning the appropriate boolean value should always pass the event up to the control’s parent - until APP is reached. In the HTML DOM, events are bubbled up to the Window and then down again (or mebbe it’s the other way around, been a while). Either way, an object gets two bites of the cherry to handle an event unless an intervening object has called an event method ( evt.stopPropagation (); ) to stop the event being handed onwards.
In Xojo that propagation seems to be controlled sometimes by the returned boolean but not always.