Re: Deferring a selector until later, but before painting
Could you create the control hidden, then defer whatever sets the value of the control and defer a setHidden:NO? --Brady ___ 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]
Re: Deferring a selector until later, but before painting
Oh, wait… this requires Leopard :| Is there anything that works with Tiger? I'm trying to avoid Leopard dependencies when there are easy substitutes. John Stiles wrote: Actually, in this case, it seems like a perfect fit for what I'm doing. I'm already using a subclassed view anyway. I will definitely take a look at -viewWillDraw:. BTW, views don't actually have delegates—many control subclasses do, e.g. NSTableView has one—but a plain NSView does not. Thanks, Ken! I'll let you know if this resolves my issue. I highly suspect that it will. j o a r wrote: On Mar 6, 2008, at 8:32 AM, Ken Ferry wrote: Or can you do your final setup in -viewWillDraw? For some kinds of problems, you could synchronously mark whatever state you're interested as invalid, then resolve any invalidated state in -viewWillDraw. This would be an appropriate way to do deferred layout, for example. I think it's unfortunate to have to resolve to subclassing for this type of problem - The OP might end up having to subclass several different NSControl subclasses to make it work. Perhaps NSView should provide some sort of notification or delegation scheme to supplement this method? j o a r ___ 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/jstiles%40blizzard.com This email sent to [EMAIL PROTECTED] ___ 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/jstiles%40blizzard.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: Deferring a selector until later, but before painting
On Leopard, this solution works perfectly. I get a chance to update my view right before it draws, which is exactly what the doctor ordered. Any way to get this on Tiger or am I just out of luck? John Stiles wrote: Oh, wait… this requires Leopard :| Is there anything that works with Tiger? I'm trying to avoid Leopard dependencies when there are easy substitutes. John Stiles wrote: Actually, in this case, it seems like a perfect fit for what I'm doing. I'm already using a subclassed view anyway. I will definitely take a look at -viewWillDraw:. BTW, views don't actually have delegates—many control subclasses do, e.g. NSTableView has one—but a plain NSView does not. Thanks, Ken! I'll let you know if this resolves my issue. I highly suspect that it will. j o a r wrote: On Mar 6, 2008, at 8:32 AM, Ken Ferry wrote: Or can you do your final setup in -viewWillDraw? For some kinds of problems, you could synchronously mark whatever state you're interested as invalid, then resolve any invalidated state in -viewWillDraw. This would be an appropriate way to do deferred layout, for example. I think it's unfortunate to have to resolve to subclassing for this type of problem - The OP might end up having to subclass several different NSControl subclasses to make it work. Perhaps NSView should provide some sort of notification or delegation scheme to supplement this method? j o a r ___ 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/jstiles%40blizzard.com This email sent to [EMAIL PROTECTED] ___ 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/jstiles%40blizzard.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: Deferring a selector until later, but before painting
On Thu, Mar 6, 2008 at 9:59 AM, John Stiles [EMAIL PROTECTED] wrote: On Leopard, this solution works perfectly. I get a chance to update my view right before it draws, which is exactly what the doctor ordered. Any way to get this on Tiger or am I just out of luck? Out of luck. Well, you can do the work in -drawRect:, but if any of the work you do invalidates display, it'll be delicate code (meaning it may be hard to get it to work right, or relatively fragile between releases). It might be good to implement a -resolveInvalidatedStuff method, then call it from both -viewWillDraw and -drawRect:. Then, on Leopard, you'll never actually be doing any work in drawRect: because you will have already resolved all state. If it works on Tiger at that point, great, and if not, any further tricky work you do is targeting an unchanging OS. Make sense? I think it's unfortunate to have to resolve to subclassing for this type of problem - The OP might end up having to subclass several different NSControl subclasses to make it work. Perhaps NSView should provide some sort of notification or delegation scheme to supplement this method? Maybe.. I was guessing that John was writing a custom view, because that's mostly where it seems to come up. Existing Cocoa view classes do already support an invalidation model in places where it seems useful - consider -[NSTableView reloadData]. But, maybe. File radars when you hit places in your real code where you'd want it. :-) -Ken Cocoa Frameworks ___ 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]
Re: Deferring a selector until later, but before painting
On Mar 6, 2008, at 9:59 AM, John Stiles wrote: On Leopard, this solution works perfectly. I get a chance to update my view right before it draws, which is exactly what the doctor ordered. Any way to get this on Tiger or am I just out of luck? If nothing else you can use the hammer approach of NSDisableScreenUpdates()/NSEnableScreenUpdates(), although this is usually used when you want multiple windows to appear without a flash... -- David Duncan Apple DTS Animation and Printing [EMAIL PROTECTED] ___ 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]
Re: Deferring a selector until later, but before painting
On Thu, Mar 6, 2008 at 2:06 PM, John Stiles [EMAIL PROTECTED] wrote: Ken Ferry wrote: On Thu, Mar 6, 2008 at 9:59 AM, John Stiles [EMAIL PROTECTED] wrote: On Leopard, this solution works perfectly. I get a chance to update my view right before it draws, which is exactly what the doctor ordered. Any way to get this on Tiger or am I just out of luck? Out of luck. Well, you can do the work in -drawRect:, but if any of the work you do invalidates display, it'll be delicate code (meaning it may be hard to get it to work right, or relatively fragile between releases). It might be good to implement a -resolveInvalidatedStuff method, then call it from both -viewWillDraw and -drawRect:. Then, on Leopard, you'll never actually be doing any work in drawRect: because you will have already resolved all state. If it works on Tiger at that point, great, and if not, any further tricky work you do is targeting an unchanging OS. Make sense? Hmm. What I'm doing is almost certainly going to invalidate display, so I am probably just out of luck for Tiger. If there was some bulletproof solution that could be made to work under Tiger, that would have been nice, but it's not a big deal. I don't currently anticipate this code being used under Tiger. I just like to write things so that we could use them as far back as reasonably possible, in case plans change. I guess if that does happen, I can bring back the old code and Tiger users can live with the controls-changing-after-display behavior that we had before. Note that implementing -viewWillDraw won't keep your code from running on Tiger, the method just won't get called. That's what I was getting at with the hybrid drawRect:/viewWillDraw approach. -Ken ___ 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]
Re: Deferring a selector until later, but before painting
Ken Ferry wrote: On Thu, Mar 6, 2008 at 2:06 PM, John Stiles [EMAIL PROTECTED] wrote: Ken Ferry wrote: On Thu, Mar 6, 2008 at 9:59 AM, John Stiles [EMAIL PROTECTED] wrote: On Leopard, this solution works perfectly. I get a chance to update my view right before it draws, which is exactly what the doctor ordered. Any way to get this on Tiger or am I just out of luck? Out of luck. Well, you can do the work in -drawRect:, but if any of the work you do invalidates display, it'll be delicate code (meaning it may be hard to get it to work right, or relatively fragile between releases). It might be good to implement a -resolveInvalidatedStuff method, then call it from both -viewWillDraw and -drawRect:. Then, on Leopard, you'll never actually be doing any work in drawRect: because you will have already resolved all state. If it works on Tiger at that point, great, and if not, any further tricky work you do is targeting an unchanging OS. Make sense? Hmm. What I'm doing is almost certainly going to invalidate display, so I am probably just out of luck for Tiger. If there was some bulletproof solution that could be made to work under Tiger, that would have been nice, but it's not a big deal. I don't currently anticipate this code being used under Tiger. I just like to write things so that we could use them as far back as reasonably possible, in case plans change. I guess if that does happen, I can bring back the old code and Tiger users can live with the controls-changing-after-display behavior that we had before. Note that implementing -viewWillDraw won't keep your code from running on Tiger, the method just won't get called. That's what I was getting at with the hybrid drawRect:/viewWillDraw approach. Right. So I can leave it implemented, but for Tiger, I can check the AppKit version and if it's below the Leopard value, I can call my method via -performSelector:withObject:afterDelay: and get the same effect. It just will have a brief blink. I suppose I could also experiment with disabling screen updates to get past that hurdle. Honestly, for now, it's probably not all that important... I'll just accept that Tiger has limitations, and if I end up needing to target Tiger after all, I'll worry about it then. For now I'll stay focused on Leopard. Thanks for your suggestions; I appreciate the help! ___ 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]
Deferring a selector until later, but before painting
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. ___ 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]
Re: Deferring a selector until later, but before painting
On Mar 5, 2008, at 5:41 PM, j o a r [EMAIL PROTECTED] wrote: On Mar 6, 2008, at 2:12 AM, John Stiles wrote: 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. How about delaying adding the control until the value you want to display in the control is ready? Or can you do your final setup in -viewWillDraw? For some kinds of problems, you could synchronously mark whatever state you're interested as invalid, then resolve any invalidated state in -viewWillDraw. This would be an appropriate way to do deferred layout, for example. -Ken ___ 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]
