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 [EMAIL PROTECTED]
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
