Morph dropping (was: RE: [BUG][FIX][TEST] Morph adding/removing ( introduces drop reject bug ))

Ned Konz ned at bike-nomad.com
Tue Aug 12 19:18:37 UTC 2003


On Tuesday 12 August 2003 11:19 am, Andreas Raab wrote:

> Good catch. HandMorph>>dropMorph:event: was one of the few places
> which used #privateRemoveMorph: without setting the owner to nil
> afterwards. 

> While the symptom would be trivial to fix (just use
> "anEvent hand world" in #slideBackToFormerSituation:) there is a
> good question about whether the morph should be really "out of the
> world" during the drop.

I don't think it should be. If it's visible, it should be in the 
world.

> I'm not certain about this ... not at all. On one hand it seems as
> if things should continue to work if we just fix the above problem
> but conceptually, it sounds very, very wrong. While the morph is
> "falling down" it should most certainly be in the world (where
> would it fall if it weren't???) and it would (quite implicitly) end
> up in the right place (the world) if noone handles that drop. On
> the other hand, I have no idea what other implicit assumptions
> about dropping is in the code now, so I simply don't know if
> anything is going to break.

I'm not sure why the Hand wants to get rid of the dropping morph so 
soon. After all, the default behavior on drop is to change ownership. 
And if the drop is rejected, the Hand deletes the morph.

If you just comment out the removeMorph: line in 
HandMorph>>dropMorph:event: it still seems to work OK.

Though I have to test this some more.

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



More information about the Squeak-dev mailing list