Dragging from a list field

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com