insertObject:in<Key>AtIndex: not being called.
insertObject:in<Key>AtIndex: not being called.
- Subject: insertObject:in<Key>AtIndex: not being called.
- From: Paul Szego <email@hidden>
- Date: Sun, 3 Apr 2005 10:47:12 +1200
Hi,
I can't get KVC working for to-many relationships when I don't expose the NSMutableArray directly. If I provide the following indexed accessors (for a property named "items"), it doesn't work:
<x-tad-bigger>-countOfItems</x-tad-bigger> and <x-tad-bigger>-objectInItemsAtIndex:
-insertObject:inItemsAtIndex:</x-tad-bigger> and <x-tad-bigger>-removeObjectFromItemsAtIndex:
</x-tad-bigger>
If I make the "items" attribute public, or provide get/set methods, things work. According to the documents however, this class *is* KVC compliant. In that case, I should be able to use
<x-tad-bigger>valueForKey:</x-tad-bigger> and
<x-tad-bigger>setValue:forKey:</x-tad-bigger> for this property.
Getting the value using valueForKey: works fine - it seems that an adapter class that implements NSArray is dynamically created, and implemented by calling the countOfItems: and objectInItemsAtIndex: methods. Setting the value however doesn't seem to work. If I call setValue:forKey: I get an error message
"this class is not key value coding-compliant for the key items."
So I'm not sure what the problem is. Other areas of documentation describe in some detail the steps taken to access a property when the NSKeyValueCoding methods are used. None of those descriptions mention looking for "Indexed Accessor Patterns for To-Many Properties". However the valueForKey: default implementation certainly seems to determine that the indexed accessors exist. In addition, statements like this one in the Apple documentation:
"I
mplementing indexed accessors methods for a property makes that property indistinguishable from an array when using key-value coding methods."
would lead to me to expect that a similar thing should happen when using setValue:forKey: on a to-many property.
Can anyone shed some light on this? Should it work?
Thanks, Paul.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden