Drag and Drop Question
lists at mangomultimedia.com
Tue Oct 26 18:40:46 EDT 2004
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.
Blue Mango Multimedia
trevor at mangomultimedia.com
More information about the Use-livecode