Re: NSMutableArrayForKeyPath
Re: NSMutableArrayForKeyPath
- Subject: Re: NSMutableArrayForKeyPath
- From: Allan Odgaard <email@hidden>
- Date: Fri, 19 Mar 2004 18:10:43 +0100
On 19. Mar 2004, at 14:59, Alan Donsky wrote:
In reviewig this stuff, i think this is the right way. And indeed,
when the user types, the model IS updated, just not exactly how i want
it.
Ah, now I think I understand you :) I was thrown off by the mention of
the model.
The problem lies with updating "arrangedObjects.name", because the
'name' portion constitutes an array constructed on the fly, and not
really a property of "arrangedObjects".
So what happens is something like this (ignoring mutable array proxies
and such):
1 id array = [controller valueForKey:@"arrangedObjects"];
2 id names = [array valueForKey:@"name"];
3 ... // mutate "names" array
4 [array setValue:names forKey:@"name"];
5 [controller setValue:array forKeyPath:@"arrangedObjects"];
Line #4 is the problem -- the implementation is like this:
- (void)setValue:(id)aValue forKey:(NSString*)key
{
NSEnumerator* enumerator = [self objectEnumerator];
while(id object = [enumerator nextObject])
[object setValue:aValue forKey:key];
}
I.e. for each item in 'arrangedObjects' it sets the name property to
the value (which is the entire 'name' array), resulting in an array of
arrays.
I think the "native" view classes overcome the problem by requiring (at
least) two bindings, one being "content", which is the key path for the
actual array, and the other being "contentValues", which is the (sub)
key path for the value property.
E.g. in your case "content" would be "arrangedObjects" and
"contentValues" would be "arrangedObjects.name".
When your view is edited, you would then always use the "content"
binding.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.