On Aug 7, 2009, at 10:44, r c wrote:
I have read that document, but it indicates that this method (as well as start and stopAnimation:) only apply to indeterminate progress indicators - is this not true?
It doesn't say that for setUsesThreadedAnimation:, only for the other two. FWIW I don't believe it's the answer to your original question. I truly don't know what's *supposed* to happen for determinate progress indicators, but my observation has been:
-- 'usesThreadedAnimation' doesn't seem to (really) control the internal aquatic animation of the blue portion, but instead causes changes to the *length* of the blue portion to animate smoothly.
-- It could well be true, though, that while the length is animating smoothly, 'usesThreadedAnimation' will also cause the aquatic animation to update.
-- If you stop setting the current value of the determinate progress bar, the animation will stop, regardless of whether 'usesThreadedAnimation' is YES or NO.
-- You can only set the current value in the main thread, because anything that causes the user interface to redraw should (generally) be done from the main thread.
-- So if your main thread is busy, the aquatic animation will stop no matter what else you do.
I admit I could be completely wrong about this, but the whole progress animation thing is extremely frustrating (in part due to the non- informative documentation), and the only sure way I've found to keep the water flowing has been to regularly set the control's value from the main thread.
What the rules are for indeterminate animations, I couldn't tell you. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
