"Hernan Tylim" <htylim at yahoo.com.ar> wrote:
> Hi all.
> 	Which is the proper way for intercepting KeyboardEvents ?
> 	What I would like to do is to be able to prevent the TAB keystroke event to
> reach it's destination and change the keyboard-focus to another morph.
> 

It's a complicated situation!

The most straightforward approach is to modify the morphs you care
about, to pass TAB events up to their owner.  If you are interested in
dialogue windows, then this seems like a very reasonable approach.

If you really want to do a general approach, it takes some thought. 
Right now there is only one keyboard focus, and the keystroke events go
straight to it.  To see how it all works, start browsing from
HandMorph>>handleEvent:.

I guess one way to do what you suggest would be to modify HandMorph to
support multiple keyboard focuses, and each one gets to try the key in
turn.  This seems like a cleanest approach, except that you have to
think about how to get the secondary guys registered at the right time. 
That issue might turn the approach into a mess.

Another way would be to modify HandMorph to always pass keyboard events
through the owner of a morph before passing them to the submorphs.  This
is similar to what happens with mouse events, anyway.  The method could
be named something like:

	possiblyHandleEvent: event   thatWasSentToSubmorph: submorph

My first impression is that this is very ugly.  But on more thought, it
*does* sort of mirror what happens with mouse events.  It does seem
appropriate, I guess, that the owners of a morph can intercept
keystrokes coming to it.  The idea is that the events flow from the hand
to the world and from there down into the morph.


-Lex


PS -- does BOB's UI do this kind of thing?  How does it do it?