Re: finger cursor over flash buttons?

[Bruce Epstein - Zeus Productions]

From: Colin Holgate <[EMAIL PROTECTED]>
>My method is very fast, and takes care of the needs of custom cursors
>for different areas of the same sprite.

I'm definitely not understanding something. What are you referring to? How
does your method implement different custom cursors for a single sprite?

Are you talking about a method that you use in very specific cases? (and
I'd consider different cursors for different areas of a sprite an unusual
case). It seems like you were saying that you do all your custom cursors
the way you described.

>It also works around one of
>my pet peeves about Director, and that is that it constantly gets the
>cursor wrong.

I've not had Director get the cursor wrong. What are you referring to? Are
you setting the sprite cursor to -1 to reset it? If so, that is incorrect.
You should generally set the sprite cursor to 0 to reset it. That makes it
obey the global cursor setting. If you set a sprite cursor to -1, the
sprite will use the arrow cursor even if, say, the global cursor is an
hourglass.

>Is it really the case that Director checking all the sprites that
>have a custom cursor set. and deciding (if it even does) which one
>should win, is faster than my method?

I'm assuming that Director does *not* check all the sprites that have a
custom cursor set. Instead, I'm assuming that once the cursor overlaps a
sprite, it checks if that one has a custom cursor. As it is event-driven,
it should be faster than your "polling" method of using prepareFrame.

>By the way, I'm not saying to use prepareframe for all cases, that's
>needed for the flash case.

I'll have to look back at the Flash case mentioned in the original
question. I must have missed something.

>In many cases I would use mouseenter to
>set the global, and so most of the time not much is happening, and
>the once per frame setting of the cursor is instant

MouseEnter would make a lot more sense than prepareFrame because it would
go from being polling-driven to event-driven. That said, I find it cleaner
to set the sprite cursor once in beginSprite and clear it in endSprite.
I've never had a need to do it on mouseEnter instead. To me, the cursor is
a property of the sprite, not an action to be taken when the mouseEnter
event occurs. I'm still missing something apparently.

One admitted disadvantage of my technique is in the following case:

Let's say that you have a button with a custom cursor (a pointing finger).
But when you click on the button, you want to post a wait cursor. You'd
need to either set the sprite cursor to 0 (and then set the global wait
cursor) or set the sprite cursor to the wait cursor (and you'd still have
to set the global cursor to get a wait cursor even if the user rolled off
the current button). But such a case has been exceedingly rare for me. I
prefer to manage a sprite as a self-contained object. Therefore, I like for
it to manage its cursor independently of a global cursor setting.

Regards,
Bruce





[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi  To post messages to the list,
email [EMAIL PROTECTED]  (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo.  Thanks!]