Re: Unable to get animation of NSProgressIndicator on my custom view (subclassed)
Re: Unable to get animation of NSProgressIndicator on my custom view (subclassed)
- Subject: Re: Unable to get animation of NSProgressIndicator on my custom view (subclassed)
- From: Quincey Morris <email@hidden>
- Date: Fri, 15 Jan 2010 17:16:12 -0800
On Jan 15, 2010, at 14:54, Shane Stanley wrote:
> On 16/1/10 7:44 AM, "Quincey Morris" <email@hidden> wrote:
>
>> AFAIK, the "animation" meant by 'startAnimation:' is *not* the animation of
>> the pattern inside the progress indicator, but an animation of the change in
>> the length of the filled-in part of the progress bar. That is, when it goes
>> from 1/4 to 1/2, say, without animation the blue bar just jumps in length, but
>> with animation it slides along smoothly. For an indeterminate progress bar,
>> the animation does nothing for you (because the bar is always full).
>
> I think you might have that backwards:
>
> startAnimation:
> Starts the animation of an indeterminate progress indicator.
>
> - (void)startAnimation:(id)sender
>
> Parameters
> sender
> The object sending the message.
>
> Discussion
> Does nothing for a determinate progress indicator.
Actually, I had it mostly sideways, and it's considerably more inconsistent that I knew.
This time I actually wrote code to test it, with these results (under Snow Leopard, which might not have precisely the same behavior as Leopard):
1a. The indeterminate bar "candy stripe" animation *never* runs unless events are being processed -- either by returning to the main event loop, or dequeuing events with '[NSApplication nextEventMatchingMask:...]' -- *and* 'startAnimating:' has been invoked. Setting the progress value in a local loop doesn't kick the animation in this case. 'setUsesThreadedAnimation:' has no effect whatsoever.
1b. Indeterminate circular indicators always animate after 'startAnimating:' has been invoked, even during a tight loop that neither kicks the indicator nor processes events. 'setUsesThreadedAnimation:' has no effect whatsoever.
2a. The Aqua animation in determinate bar indicators with 'setUsesThreadedAnimation:YES' runs if *either* events are being processed *or* the progress value is kicked repeatedly. The length of the bar animates smoothly.
2b. The Aqua animation in determinate bar indicators with 'setUsesThreadedAnimation:NO' runs *only* if events are being processed. The length of the bar jumps from value to value.
2c. For determinate circular indicators, 'setUsesThreadedAnimation:' has no effect whatsoever. They always behave like case 2b (with arc angle instead of bar length).
AFAICT.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden