Drag and Drop Question

[Trevor DeVore]

On Oct 26, 2004, at 3:22 PM, Dave Cragg wrote:
>
> Bug or unimplemented feature??
>
> I was planning to look at the drag and drop features to see if they 
> would make it easier to implement something such as you described. 
> Previously, I'd done this with the classic mouseDown, mouseMove, 
> mouseUp, mouseRelease, script locals combination.
>
> If, instead of having  a palette follow the mouse around, you use 
> another control (button, graphic, whatever) and keep it under the 
> mouse, then the dragMove will continue to get sent. But in that case, 
> the dragEnter message doesn't get sent when you drag over another 
> control, which was really what I wanted to use. So you need to do some 
> kind of hit test in the dragMove handler which is no different from 
> doing it in the mouseMove handler under the "classic" method.

The problem with this is that you can't drag to another stack window.  
The floating palette works nicely for this.

> I guess what I need is an alternative to dragEnter, something like 
> dragEnterEvenWhenThereIsAnInterveningObject. (Can't think of anything 
> better right now.)
>
> By the way, something not documented with the dragMove message is that 
> it takes the location of the pointer as an argument. (same as 
> mouseMove) Using this instead of using the mouseLoc function to set 
> the loc of an object is *much* smoother.
>
> on dragMove x,y
>   set the loc of <whatever> to x,y
> end dragMove
>
> I guess some/all of this should be Bugzilla'd. I don't see this 
> entered already.

I have this mostly working now.  Here is what I am doing:

* User clicks on object to start drag.  In the mousedown handler I put 
some data into dragData.

* The mouseDown handler opens a palette window and puts a button script 
in the front.  The script watches the dragMove and mouseMove messages.  
dragMove is sent when the pointer is over an object.  mouseMove is sent 
when the pointer is over the card so this gives very smooth movement as 
long as the pointer is within a Rev application window.  During 
initialization the palette also sends a message to itself that do all 
of the cleanup (hide the palette, etc.).  Drag drop seems to lock all 
other messgaes until it is finished.  This message won't be received 
until the drag/drop action has finished since I send it in 0 seconds.

send "closeMeAfterDrop" to me in 0 seconds

* The palette follows the mouse around 5 pixels below and to the right 
of the pointer position.

* all controls that you want to deal with drag and drop can now process 
the dragEnter/dragLeave messages so you can provide user feedback as to 
which objects can be dropped on.

There is one problem remaining.  Revolution does not send the dragMove 
or mouseMove handlers when the pointer moves outside of the Revolution 
application during drag and drop.  This means that the floating palette 
stops dead in it's tracks when the pointer exits the app window.  It 
will follow the pointer again once the pointer reenters the app window 
though.  I think this is a bug unless anyone can tell me a good reason 
for it.  I will probably post some bug reports tonight that deal with 
drag and drop.


-- 
Trevor DeVore
Blue Mango Multimedia
trevor at mangomultimedia.com