On Tuesday 12 August 2003 12:33 pm, Andreas Raab wrote:
> > If you just comment out the removeMorph: line in
> > HandMorph>>dropMorph:event: it still seems to work OK.
>
> Yes, until you make a mistake in your drag and drop code. The
> reason why the hand tries to get rid of the morph is only because
> it makes it much more robust. For example, try to drop some guy who
> has an error in #wantsToBeDroppedInto: - this will screw the
> system.

So why not just wrap the call to #dropMorph:event: in an exception 
handler that just deletes the morph on an exception?

Something like:

HandMorph>>dropMorphs: anEvent
	"Drop the morphs at the hands position"
	self submorphsReverseDo:[:m|
		"Drop back to front to maintain z-order"
		[ self dropMorph: m event: anEvent ] ifCurtailed: [ self 
removeMorph: m ].
	].

> BTW, on an even larger scale I think that drag and drop shouldn't
> even be done by adding some morph "physically" to the hand. For me,
> the hand represents the mouse cursor so everything added to it,
> logically _is_ the mouse cursor. Dragging objects is something
> which (in my understanding) happens by having the morph being
> dropped "follow" the hand. But that's an issue for a different
> conversation ;-)

I'm doing something like that in Connectors during (the second half 
of) wiring.

A new, invisible Connector is grabbed by the hand.

When it's dropped, it becomes visible and its second end starts 
following the hand.

Then when the next mouse event happens (up or down), it stops 
following the hand.

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