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
|