#1|1

Control events
-computer programming-


The keydown system is a bit different (to mousemoveevent) in that it effectively needs to handle dozens of
different events (keys) not just one piece of info (the new relative mouse coord). As such, it bubbles the event
to parent controls of the focused one, so you can distribute handling of multiple keys, if you return false from
your keydown handler (i.e. didn't claim that keydown, note no 'event' at the end of a handler hook).

If nothing handles the key, it'll recurse the event (not the handling) through all the controls to give special
ones the opportunity to hook/override the handler itself. Its last difference (to mousemove/event) is that if
nothing else handles the call (and nothing is focused or focus has been nulled) it finally will send the event to
the handler of the root control i.e. the (outer) skin (technically to anything in the hierarchy with a null parent).
The keyup system works the same for the moment, but I'll be adding a mechanism to direct the keyup at
whichever control claimed the keydown (this morning possibly).

It will then work in a manner similar to mouse/menu(middle button or left hold)/rmouse down/up (i think). I'll
probably add the fallback-to-root control mechanism to the mousemove event system too, i.e. if the move is
not captured or claimed it'll trigger the root handler (who could inspect captured and clicked to see the
situation that caused it, note these will never get to child controls so they can behave naively). This will be
useful for roll over hints on mouse-based systems, perhaps other things too.