Tim,

The metaphor that is used is different than, "start drag, drag, end drag".
It's more like "grab - carry - drop ". If you happen to drop in an agreeable
spot, it appears as if a drag and drop operation took place.

Here's an example:

>From the main menu select "New Morph..." ; "Basic Morph" ; "Rectangle Morph"
.
Do this twice, or bring up the halos and duplicate the morph using the green
halo.
Notice that when you grab and drop one of the rectangles on the other
nothing interesting happens.
Pull up the handles on one of the rectangles, select the red menu, and
select the option 'drag and drop'.
When you drag the other rectangle on to the drag and dropped enabled morph,
it 'sticks'.
You can seperate the two using the black halo, and notice that you cannot
drop the drag enabled morph onto the regular morph and have it stick.

As I recall, #startDrag: pretty much puts the morph into the hand. It's
basically along the lines

    World hand grabMorph: morph.

which puts the morph into the hand. You'll see this as 'event hand
grabMorph: self' . This is the default behavior that a morph in a
PasteUpMorph (World) exhibits. Conceptually, it's really just 'grab'. The
#startDrag: example is a little more complicated because you're trying to do
three things; single click, drag and double click all at once.

Once it is in the hand, the metaphor changes a bit. The hand goes to drop it
(when the user release the mouse button), and the morphs that are underlying
the hand are expected to handle the drop. Typically the first clue the
receiver gets is #mouseEnterDragging: , which tells the morph that the hand
has entered carrying something (with the mouse button down). At that point
the morph may want to examine what the hand is carrying to determine if it
is a valid item to be dropped. As an example, if the hand is carrying a
RectangleMorph when it enters, the morph may want to highlight itself with
spiffy graphics indicating a valid drop zone. Note that the World will
accept almost anything (it's such a slut).

When the hand actually goes to drop its contents on the receiver, the
receiver answers true to #wantsDroppedMorph:event: to accept the morph ; in
symmetry, the morph to be dropped must answer true to the message
#wantsToBeDroppedInto: This is for the case where a carried morph doesn't
like where it's going (for example, it doesn't want to be dropped in the
World). I've sure you've seen Squeak reject drag and drops, and the morph
wanders back to where it was grabbed from.

If everything checks out, the receiver gets the message
#acceptDroppingMorph:event: which actually "drops" the morph onto the
receiver. The receiver usually does something like #addMorph: if they want
the usual visual addition of the morph. However, this could just as easily
be something like dropping representations of coins in a piggy bank, where
the amount of money in the piggy back increases after the coin is dropped,
and the coin disappears

If you're still a little befuddled, give me a simple example of what you're
trying to do, and I'll code it up. Something like, "I pick up the
RectangleMorph, drop it on another and I expect this to happen "

Jim

----- Original Message -----
From: "Tim Rowledge" <tim at sumeru.stanford.edu>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Sunday, July 08, 2001 4:52 PM
Subject: Re: porting 2.7 morph dragging to 3.1


> Thanks to various respondents I have got as far as implementing
> #startDrag: and getting a _single_ jump when I try to drag my morphs.
>
> I've been looking at the DoubleClickExample for more info and it seems
> to be rather out of date; the class comment
> a) refers to #drag: but the class implements #startDrag:
> b) claims we get repeats of #drag: until the mouse button goes up, which
> seems not to be happening.
>
> I'd rather imagined that with a message #startDrag: I'd see a #stopDrag:
> and even a #dragStep: or similar. Can't find anything like that so far.
> I've scanned the Swiki for a few hours and found nothing sufficiently up
> to date to help (Dave Smith - your drag n drop page seems to have been
> partially obsoleted since you wrote it :- ( )
> Does anyone have any working code I can steal from, er, I mean base my
> research upon?
>
> tim
>
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: ESBD: Erase System and Burn Documentation
>
>
>
>