On Apr 17, 2008, at 01:42, William Towe wrote:
Yep, that took care of it. Just so I understand, should I surround calls to any of the standard KVC method calls (in my case, insertObject:atIndex:) with [self willChangeValueForKey:@"affectedKey"]; and [self didChangeValueForKey:@"affectedKey"] if the standard KVC call will affect that derived property? This is probably described in the KVO documentation, I'll read up on it to make sure. Thanks for the quick fix.
Well, the answer is a qualified "yes". *But* willChange/didChange adds some visual complexity to the code, though, so keyPathsForValuesAffectingValueForKey: (or keyPathsForValuesAffecting<key>) is preferable if the dependency is unconditional (setKeys:triggerChangeNotificationsForDependentKey: prior to Leopard). *But* there's also collection-specific variants of willChange/didChange for when you're not simply replacing the entire collection. *But* automatic dependencies do not work for properties of core data managed objects. :)
And, I guess, in cases where explicit willChange/didChange becomes burdensome, you could consider changing the dependent property into an independent one. (In your case, for example, that would mean actually storing the allDescendantNodes array instead of calculating it on the fly.) Context would dictate whether this was a feasible solution, but it might simplify an otherwise complex set of dependencies.
_______________________________________________ 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]
