On Thursday 13 February 2003 08:39 pm, Daniel Joyce wrote:

> 	Focus is special, I understand that. I assume the eventhandling
> here refers listners who are intrested in mouse clicks, but who
> have not been clicked in? Else it seems redundant with what is
> below.

The listeners are for global hooks. This is currently mostly used by 
the EventRecorderMorph, but I think I've used it for eToy keyboard 
stuff too. These are recipients who otherwise would not get these 
events.

> >   [on its way down, any morph can install a prospective handler
> > if interested]
>
> 	Why doesn't a morph install a handler when created, why does it
> install one now? ( Is there a reason for lazy handler
> initialization? )

Look at MorphicEventHandler>>dispatchMouseDown: anEvent with: aMorph

The handler is on a per-event basis. Morphs *do* tend to have 
semi-permanent handlers, but this gives different morphs in the 
ownership chain the opportunity to handle events. The actual 
"handler" that is installed in this case is just the morph itself. 
That is, each morph can say "I want to handle this event if no one 
else does".

So each more innermost morph can see whether a higher morph (one of 
its parents) has set a prospective handler yet. It's possible to 
override this, of course; if you look at (say) 
Morph>>handlerForMouseDown: you'll see some logic that takes into 
account (for instance) mouseDownPriority.

> > * when the event traverses back up the chain, the event is sent
> > to each morph in this chain using #handleEvent:
>
> 	This seems bizzare. So an event goes all the way to the bottom
> before coming all the way back up and possibily being handled? What
> is the reason for this?

To let the decision of where an event will be handled happen at any 
level of the hierarchy.

The problem is that we want Morphs to be able to live on their own and 
respond to interaction, as well as to live as part of other Morphs. 
So their event handling depends on their context. This is a way to 
present the requests of their enclosing contexts to them.

> 	Or wait, is this to make handling changes (caused by handling of
> the event ) in submorphs of a parent morph easier for the parent
> morph?
>
> 	Here's another question then....
>
> 	Parent has ChildA, ChildB, ChildC, all of who are leaves...
>
> 	It forwards EventFoo to each.
>
> 	EventFoo bounces back from the Children after being handled by
> them... So does that mean the parent sees EventFoo bouncing back up
> 3 times?

No, because only one of them at most would want to handle the event 
(ordinarily, they'd reject the event if it happened outside of their 
bounds).

And anyway, it's not a bounce, rather it's a recursive method that 
sets a handler, then calls its submorphs, then looks at what happened 
(whether the event was handled, whether a handler was installed, 
etc.).


-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE