OK, so I've been playing with dragMove and it doesn't seem to be behaving as documented. The docs state:
"The dragMove message is sent to the control the mouse pointer is over, or to the card if no control is under the mouse pointer."
In my tests the dragMove message is only sent if the mouse is over a control. Anyone else see this?
Yes. I see it here.
dragEnd also seems to be behaving contrary to the docs. The docs say:
"The dragEnd message is sent to the control that the drag started from. If the data is not dropped onto a control that accepts it, the dragEnd message is still sent."
I do not get the dragEnd message sent to the control that started the drag unless I drop onto a control with a dragDrop message. Putting a dragDrop handler in the card works if you end the drop on a control but if you drop on a card then no message is received. I guess I can just put a graphic that covers the entire card to solve that issue. So are the docs incorrect, or are there bugs in the drag and drop behavior or is it just me having a rough day?
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.
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.
Cheers Dave
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
