On Tuesday 07 August 2001 12:49 pm, you wrote:
> On Tue, Aug 07, 2001 at 09:45:27AM -0700, Ned Konz wrote:
> > On Tuesday 07 August 2001 09:20 am, Josh wrote:
> > > I'm implementing a drawing app where there are multiple 'tools'
> > > available, one of which is active at any given time.  Depending on the
> > > tool selected, mouse actions have different effects.  For example, if
> > > the 'selection' tool is active, clicking on a morph will toggle
> > > whether it is selected.  If the 'delete' tool is active, clicking on a
> > > morph will delete it (and possibly other morphs in its group).
> > >
> > > One reason that I care about mouseEnter/Leave is that I want all
> > > morphs in a group to be highlighted whenever the pointer enters any
> > > morph in the group.
> >
> > One possibility is to have the tools do a mouse capture and then handle
> > the mouse events themselves, sending various messages to the involved
> > other morphs.
>
> If I understand you correctly, you are envisioning a ToolMorph that would
> be above the morphs being operated on.  It would receive the events
> normally, but handle them differently.

No, it doesn't have to be above anything. It could even be sitting 
off-screen, or invisible...

Look at the enclosed change set. It implements a simple tool based on this 
concept.

> Would the tool be held in the hand?  How would it move around to intercept
> the mouse events?

It doesn't have to be held. Once you start mouse capture, all the mouse 
messages go to your morph, until you stop the mouse capture. This happens 
whether or not the Hand is over your Morph. So the tool morph could just be a 
morph with enough smarts to handle the mouse events in capture mode.

You can change the mouse cursor, though I had to fix a couple of things in 
the Hand that kept reverting the cursor by forcing hand redraws.

> > So for instance, a mouse click is received by the tool, and translated
> > into a toolWhateverClicked: evt call on the appropriate Morph.
> >
> > For mouse over detection, the tool could just look at which Morphs were
> > below the mouse position, and call toolEntered: or toolLeft: or something
> > like this.
> >
> > That way, you don't have to change the event handling of existing Morphs,
> > and get to work with any old Morph.
>
> Yes, this is a very important feature to have; it's why I was mucking
> around with the event dispatcher in the first place.

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MorphSelectorMorph-NK.2.cs.gz
Type: application/x-gzip
Size: 1125 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20010807/c6c4197f/MorphSelectorMorph-NK.2.cs.bin