Pink Plane vs Blue Plane
ned at bike-nomad.com
Fri Feb 14 04:15:34 UTC 2003
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
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
> > [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
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
> 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
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,
GPG key ID: BEEA7EFE
More information about the Squeak-dev