On Oct 21, 2013, at 3:58 AM, jonat...@mugginsoft.com wrote: > Yes. You need to keep your wits about you with this sort of thing. > >> I gag a little whenever I remember that's how it works, but at this point it >> ain't broke so I'm not going to tempt fate by fixing it. ;-) >> > What would you suggest as a possible fix?
If I remember correctly off the top of my head: In my case, I have "foo" watching for changes to properties on self.bar — ie self.bar.propertyXYZ. The bindings all go through an object controller whose content is bound to foo's .bar. So all changes to any properties on bar, pass through foo's setValue:forKeyPath:. This allowed me to override setValue:forKeyPath: in *foo* to watch for changes to *bar*. So other than the above, I could either change the implementation of bar to send an NSNotification or delegate method, or register for and watch all property paths via KVO. A notification is a reasonable idea, a delegate method often makes no sense, and I would say registering with KVO to be the best option (though anti-KVOists would disagree) and I do it fairly often in various places in my various apps. Using a known fixed array of key paths, the registration and unregistration becomes very small loops, and handling in observeValue… looks for the key path in the array and handles all properties the same. (I recall there being something subtle and tricky which makes this alternative non-trivial for my setValue:forKeyPath: override case.) -- Seth Willits _______________________________________________ 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
