Re: NSArrayController bound to @unionOfArrays not updating
Re: NSArrayController bound to @unionOfArrays not updating
- Subject: Re: NSArrayController bound to @unionOfArrays not updating
- From: Quincey Morris <email@hidden>
- Date: Thu, 17 Apr 2008 09:36:29 -0700
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 (email@hidden)
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:
This email sent to email@hidden