Thierry wrote:
Le 8 févr. 2011 à 15:56, Richard Gaskin a écrit :
The only problem I can find with this approach is that it "snaps back" the
dragImage to the source, even though the allowDrop has been set to true.
if anyone here knows a reliable way to prevent that I'm be most grateful.
Hi Richard,
I add one more line in your mousedown script.
See below
Please, let me know if it works.
Regards,
Thierry
on mouseDown
put the long id of me into tObj
export snapshot from tObj to tVar as PNG
set the width of img 1 to the width of tObj
set the height of img 1 to the height of tOBj
set the visible of img 1 to false
put tVar into img 1
end mouseDown
Unfortunately setting the image visibility to false has no effect. I had
it visible only because it's a demo and it's fun to watch the image
change; I have production code with such images false and still get the
snap-back.
RunRev's Ben Beaumont offered this tip on the dev list which works a
treat, also noting that this bug will be fixed in v4.6:
---------------------------
Firstly, we've tracked down the problem and fixed it for
the next release. In the meantime and for those using
older version of LC here is a workaround:
on dragEnd
remove script of btn "ObjectDragFrontScript" from front
put gObjectDragInfoA["stack"] into tDestStack
send "doDragEnd tDestStack" to me in 0 millisecs
end dragEnd
on doDragEnd tDestStack
if tDestStack <> empty then
put gObjectDragInfoA["loc"] into tLoc
set the defaultStack to tDestStack
set the properties of the templateButton to \
the properties of me
lock screen
create btn
set the loc of last control to tLoc
select last control
end if
end doDragEnd
The problem occurs because creating a button and setting the
loc causes (at some point) the dragAction global property to
be reset, which is then what the engine is returning to the
OS - hence the 'drag didn't succeed' snap-back.
The engine should really return the value of 'dragAction' at the
point the drop occured (before any messages are sent), rather
than after the drop had been processed. This is the underlying bug.
----------------------------------
Thanks, Ben!
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
