Drag and Drop a copy

Ross Boylan RossBoylan at stanfordalumni.org
Fri May 25 04:40:49 UTC 2001


At 07:09 PM 5/24/01 -0700, Ned Konz wrote:
>On Thursday 24 May 2001 18:20, Ross Boylan wrote:
> > I have an object I'm interested in, call it A.  It's in a container C.
> > It is displayed on the screen with a morph M1, which is embedded in other
> > morphs.
> >
> > I have another object B, who display includes the morph M2.
> > If someone drags M1 to M2 and drops, I want to put A into one of B's
> > variables.
> >
> > What's the best way to do this?  It looks as if the drag n drop protocol is
> > designed for removing M1 from its morphs and placing it somewhere else.  I
> > want to leave it where it is.
>
>If the destination rejects the drop, the source morph will be returned whence
>it came. So in your destination (M2) morph, just override:
>
>acceptDroppingMorph: aMorph event: evt
>         "do stuff here"
>         aMorph rejectDropMorphEvent: evt
>
>--
>Ned Konz

At the moment I have a menu item that makes a copy, and I drag the copy 
into the target (M1 and M2 have the same class).  The target overrides 
#acceptDroppingMorph:event: to reset its key variables.

Hmm... I wonder where the morph being dragged ends up after this, since it 
does not replace the target morph.

The solution you outline seems problematic for 2 reasons.  First, this 
temporarily does drag M1 out of its owning morphs.  (It's a bit tricky for 
me to check the drag behavior, since my morph involves an 
UpdatingStringMorph that pops into edit mode whenever I click on 
it.  That's one reason I'm doing the hack with the copy).

Second, the main definition of the method states
acceptDroppingMorph: aMorph event: evt
         "This message is sent when a morph is dropped onto a morph that 
has agreed to accept the dropped morph by responding 'true' to the 
wantsDroppedMorph:Event: message. This default implementation just adds the 
given morph to the receiver."

so I think this is too late to reject the thing.  And I definitely want the 
"drop" behavior--the thing I'm dragging should not move into my receiver 
before the drop.  So the earlier messages in the process don't seem right 
either.

It looks as if overriding #aboutToBeGrabbedBy: to return self copy might 
give me the behavior I'm looking for... (I'm actually doing something a bit 
more indirect, but it's the same idea).  Ah... I just read Andreas's reply, 
which confirms this strategy.  Of course, I need to fix the problem that my 
mouse downs are overloaded before the drag will do any good.

Thanks to you and Andreas for your very speedy replies.  If anyone could 
clarify the points above it would be great.  I'm particularly wondering 
where the morphs that don't get pasted in end up.





More information about the Squeak-dev mailing list