On 06/03/2008, at 12:12 PM, John Stiles wrote:
There are many times in my code where I want to defer a selector's execution until the next time the event loop runs, which is a perfect match for -performSelector:withObject:afterDelay:, passing a delay of 0.0. However, this executes after the app has repainted all the windows. Is there a way to get a selector called later, but before windows paint?Right now in my app, there are some controls which appear and then their state changes a fraction of a second later, and I'd like to avoid the visually jarring "pop" effect of a control which changes itself right after first appearing, but I can't find an easy way to avoid deferring some operations.
If the above is the case, I don't see how defering the selector's execution is going to help.
What I guess is happening at the moment is: 1. Control is added. 2. View is re-displayed. 3. State changes. 4. View is re-displayedDeferring the selector in the way you want is still going to put the addition of the control before 2.
Why are you worried about the application drawing twice—I mean what's wrong with just delaying the display of the control until after the first window paint? Is there a performance issue?
- Chris
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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 [EMAIL PROTECTED]
