set cursor to busy

[FlexibleLearning.com]

The 'busy' cursor is a BLACK AND WHITE spinning beachball and part of
LiveCode so it is cross platform. It is hungry and eats cycles because it
has to re-draw every time it changes.

The COLORED spinning beachball on a Mac means the app is hanging (i.e. not a
good thing). Do not use this cursor on ANY platform.

The 'watch' cursor displays from OS system resources I believe, so is
platform specific. It looks like a watch on a Mac and an egg-timer on
Windows. It eats virtually nothing.

Point is, don't use an icon that means the wrong thing. As Scott said, use
the documentation (sometimes called RTFM), make sure you know your delivery
platform, and Google is your friend.

My suggestion stands. Use the watch cursor for short processes; use a
progress bar updated every nth iteration for lengthy processes. If you
really want to show a change in the cursor for EVERY repeat iteration, use
the black and white 'busy' beachball cursor, but be aware that it will slow
your routine down.

Hope this helps.

Hugh Senior
FLCo


william humphrey  wrote:

Thanks Scott. that helps. On a Window's platform does set cursor to busy
look like a spinning watch or is it still a MacOS 8 beach ball?


On Wed, Oct 9, 2013 at 7:25 AM, Scott Rossi <scott at tactilemedia.com> wrote:

> I probably added to the confusion here, so I'll try to explain again.
>
> The *colored* beachball cursor (drawn by OS X) is the one that means an
> app is not responding.  This is different than the black and white busy
> cursor that you can use in LiveCode, which can be used to indicate an
> application is, well, busy doing something.  The colored cursor is the one
> you want to avoid.
>
> The difference between the LiveCode watch and busy cursors is the busy
> cursor has multiple frames which advance each time you set the cursor.
> See "cursor" in the dictionary.
>
> Hope this clears things up.
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, UX/UI Design
>
>
>
>
> On 10/9/13 3:27 AM, "William Humphrey" <shoreagent at gmail.com> wrote:
>
> >Can you explain what is different between setting cursor to busy instead
> >of setting cursor to watch? Why does setting cursor to bust "eat cycles"?
> >
> >This is now a second reason not to use setting cursor to busy. The first
> >being that it tells the user something is seriously wrong (I didn't know
> >this one).  I assume that seeing the watch just means wait a moment
> >something is going on that is supposed to take time. (I see the watch
> >cursor all the time when I run windows stuff).
> >
> >Brevity and errors in this email probably the result of being sent by a
> >mobile device.
> >
> >> On Oct 9, 2013, at 2:50 AM, "FlexibleLearning.com"
> >><admin at FlexibleLearning.com> wrote:
> >>
> >> Setting the cursor to busy eats cycles and adds a time-overhead.
> >>
> >> Personal preference is to simply 'set the cursor to watch' for any
> >>actity
> >> lasting up to a few seconds, or a progress bar updated every nth
> >>iteration
> >> (such as n mod 100 =0) for longer routines. For indeterminate activity
> >> length, I use an animated gif such as a barber's pole.
> >>
> >> Short answer is I haven't used 'busy' in a long time.
> >>
> >> 2p/2c
> >>
> >> Hugh Senior
> >> FLCo