On Mar 24, 2012, at 2:46 AM, Jonathan Taylor wrote: > It sounds, though, as if it should be ok to use > observeValueForKeyPath:ofObject:change:context (which will run on the > secondary thread, by the sound of it) as a way of monitoring the fact that > "something" has changed in the state of my object. I can then use that as a > single place in which I schedule a GUI update via a shadow object on the main > thread. Does that sound as if it would be ok?
Yes. The -observeValue… method will be called on whatever thread the property changed on; as long as the method does the scheduling in a thread-safe way, it’ll be fine. (For example, I believe calling -[NSView setNeedsDisplay:] is thread-safe.) This doesn’t really help solve the OP’s issue — it’s very convenient to use bindings instead of direct observation, as you don’t have to write code; but this gives you no opportunity to reschedule onto the main thread. Maybe it would be possible to implement a generic proxy object that could be interposed, and relay the property-change notifications from one thread to another. I don’t think this would allow easy wiring up of bindings from IB, though. —Jens _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
