On Fri, 5 Nov 1999, Eva Isotalo wrote:
> Hi everybody,
>
> My images can now be moved around and "second-button-clicked" with no problems.
>Thanks to the help from you people!
> But another small fenomenon has occured. After moving one image I (sometimes) have
>to click twice on next image to make it respond to moving. It is as if I'm still
>stuck in a script with the first image.
>
> The image can be moved "directly" on the card but also "called" to move from a small
>stack where it has been "carried around" or called to move from another image .
>
> All of it works fine except for the dubble click which I don't understand.
>
> Sorry if I have trouble expressing myself correct. And bare with me and my "sort of
>programming". ;o) BTW, I miss Grant something terrible cause he was always
>"defending" us "small programming people". And giving lots of encouragement. (sigh...)
> ------------------------------------------------
> Here follows script from two images where this is happening.
>
> ==== Image 1, a bucket with oats.
>
> on mouseEnter
> lock cursor
> set cursor to 1
> end mouseEnter
>
> on mouseLeave
> unlock cursor
> end mouseLeave
>
> local lBuOa
>
> on mouseDown
> if not lBuOa then
> put true into lBuOa
> else
> mouseUp
> end if
> end mouseDown
>
> on mousemove
> if lBuOa then
> if the mouse is down then
> grab me
> end if
> end if
> end mouseMove
Oooh! This is Very Bad! You never want to use grab in a mouseMove
handler, as it'll be calling it every time you move the mouse. The
only good place to use "grab" is in a mouseDown handler. But in your
case, you shouldn't use "grab" at all, and just set the loc of the
image to the coordinates passed by the mouseMove message (+/- some
offset, see the Examples stack for details). Personally, I consider
using "grab" poor technique and the primary reason it's supported at
all is to ease porting of SuperCard stacks.
Also, as a general rule, you should also never use "the mouse" or "the
mouseLoc" in a mouse-related message handler. Instead, set a local
variable or property on the object to indicate the current state of
the mouse button, and save off the parameters of the mouseMove message
if you might need them later. There's a huge performance hit querying
these things, and your moves will be very jerky if you use the "belt
and suspenders" approach shown above. You also run the risk of
dropping events because you pulled them out of the event queue which
means they'll never be delivered as messages (which I'd guess is what
your problem is).
Finally, for a complete solution to this problem, also be sure to
handle the mouseRelease message, which is sent when the mouse goes
down in one object but comes up in another. It was added specifically
to deal with dragging situations like this.
Regards,
Scott
> ---------------------
> Regards,
> Eva
>
>
>
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
