unexpected messages

Dave Cragg dcragg at lacscentre.co.uk
Sun Apr 27 19:33:01 EDT 2003

At 11:14 am -0700 27/4/03, Bob Rasmussen wrote:

>What I was trying to do (have done actually) is duplicate drag
>behavior like you see for
>instance in the MacOS Finder.  While moving an icon, the original
>stays behind and a
>semi-transparent copy moves with the mouse cursor.  On releasing the
>mouse button, the original
>icon moves to the last location of the copy.
>The way I was doing things, the copy needed to stay hidden until the
>mouse moved, so I created
>it and hid it right away with the idea of showing it again when
>"mouseMove" was called.  Because
>the unexpected "mouseMove" happened before I had saved the name of
>the copy, the "mouseMove"
>message was trying to show and move an object referred to by a
>variable that was still empty.
>Once I worked out the reason, the fix was simply reordering a couple

I tried this with single objects (not a group), and didn't get the 
problem. (I could only get something like you described if I hid the 
original target.) But I'm wondering if the fact that you're working 
with a group makes a difference. For example, the original target of 
the mouseDown is an object in the group, not the group itself. When 
you duplicate and rename the group, the group objects will still have 
the names of the objects in the original group. So there will now be 
an object with the same name as the target. But as you've got round 
the problem, I haven't explored it further.

>Hence my original request.  I knew a "mouseMove" was coming from
>somewhere inside the
>"mouseDown" handler, but where?  It was a large handler.  If I had
>had a place to look for all
>the ways a "mouseMove" can get generated, that would have been much
>easier.  Instead I had to
>zero in with bracketing "put" statements.  I can foresee similar
>situations arising in the
>future, so a general list seems in order.

While a list would be nice, what you described sounds like a bug so 
it probably wouldn't make the list. A mouseMove message shouldn't get 
handled in the middle of a mouseDown handler unless you've done 
something specifically to get async behavior (e.g. wait .... with 


More information about the Use-livecode mailing list