Hi Jonathan, Yes, that would work as long as the thing that changed is KVO compliant. To update the shadow object, you can do as Jens suggested, or use dispatch_async to the main thread, or use the main operation queue as described in the receptionist pattern.
Cheers, Dave On 2012-03-24, at 5: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? > > On 23 Mar 2012, at 23:14, Dave Fernandes wrote: > >> See the Cocoa Design Patterns doc: >> "The Receptionist Design Pattern in Practice >> A KVO notification invokes the >> observeValueForKeyPath:ofObject:change:context: method implemented by an >> observer. If the change to the property occurs on a secondary thread, >> theobserveValueForKeyPath:ofObject:change:context: code executes on that >> same thread." >> >> So you shouldn't use observeValueForKeyPath:ofObject:change:context to >> update the GUI in this context. I don't know of any better method than what >> the OP suggested. >> >> Cheers, >> Dave >> >> On 2012-03-23, at 6:32 PM, Jan E. Schotsman wrote: >> >>> Jonathan Taylor wrote: >>>> I have been struggling with a problem which I think I have eventually >>>> realised is down to me not handling multithreading issues properly. The >>>> situation is I have some computationally-demanding code that is running in >>>> a separate thread. This has input parameters and state variables >>>> associated with it. For diagnostic reasons I would like to be able to >>>> display the values of the state variables in the GUI. I had intended to do >>>> this just by binding to them. However I am getting occasional "message >>>> sent to deallocated instance" errors which I suspect are a symptom of the >>>> fact that I am Doing It Wrong. Further reading suggests that because of >>>> the way bindings work, modifying those state variables is leading to >>>> binding/gui type stuff happening away from the main thread, which appears >>>> not to be permitted. >>> I use KVO for this. Have your main thread observe the state variables >>> (declared as properties) and update the GUI in your >>> observeValueForKeyPath:ofObject:change:context: method. >>> I hope this is elegant enough for you ;-) >>> Jan E. >>> _______________________________________________ >>> >>> Cocoa-dev mailing list ([email protected]) >>> >>> 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/dave.fernandes%40utoronto.ca >>> >>> This email sent to [email protected] >> > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
