Trevor DeVore wrote:
What I did in the same scenario was move the selectionChanged code to
mouseDown. I couldn't find another way around it. You have to set
dragData in mouseDown. mouseDown is sent before selectionChanged and
setting the dragData kills selectionChanged.
Exactly what I was seeing, but you explained it better.
I'm not sure that this is directly related to setting the dragData
though. It seems there are other ways to kill selectionChanged in
mouseDown as well. For example:
on selectionChanged
answer "selectionChanged"
pass selectionChanged
end selectionChanged
on mouseDown
answer "mouseDown"
pass mouseDown
end mouseDown
In Rev 2.6 on OS X you will never see the answer dialog for
selectionChanged. If you remove the answer "mouseDown" code you will.
A repeat loop in a mouseDown event can kill selectionChanged. See bug
#2930.
That's very similar to what I was doing, and I saw the same results. I
found that if I pass mouseDown on the first line then it works okay. So
I'm checking for a condition first:
on mouseDown
if <condition> then pass mouseDown -- allows selectionChanged to trigger
-- set dragData, implement dragging here
end mouseDown
And this seems to work okay. Unfortunately it doesn't solve the problem
of what condition to actually check for. I don't think there's a way to
differentiate between clicking on a list and dragging from a list
without adding a user action, so right now I'm checking to see if the
Option key is down. If so, we're dragging. I'd rather be able to just
tell without involving the user though.
So there are many ways to keep selectionChanged to keep from being called.
Interesting. I'll go look at that bug. Thanks.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
