On Jan 20, 2009, at 15:18, Randall Meadows wrote:
I have an NSTableView, whose content is supplied through bindings to
an array controller. Column A is supplied via
FieldListController.arrangedObjects.name, Column B via
FieldListController.arrangedObjects.value; column B is editable,
column A is not.
I'm trying to observe when a cell in Column B is edited by
[thing addObserver:self
forKeyPath:@"fieldList"
options:(NSKeyValueObservingOptionOld |
NSKeyValueObservingOptionNew)
context:nil];
When I edit a field (by double-clicking it) and commit the edit
(pressing Return), in my -
observeValueForKeyPath:ofObject:change:context: method, "keyPath" is
"fieldList" and "object" is the object that owns the fieldList that
is being observed.
The NSKeyValueChangeKindKey in the change dictionary is
NSKeyValueChangeSetting; NSKeyValueChangeNewKey and
NSKeyValueChangeOldKey are both arrays containing all the observed
fields in "fieldList". But those "fields" are not the values that
are being edited, they are the objects which contain the values that
are being edited (i.e., [field value] is what's getting edited (and
[field name] is what's displayed in Column A).
OK, so all that makes sense, in that I'm observing "fieldList", and
the notification hands me an array (which is fieldList). However,
it doesn't tell me *which* field in the array was edited; I have to
iterate over all the fields, comparing the values from "old" and
"new" to figure out which specific field was edited.
I tried changing the observed keyPath to @"fieldList.value", but
that only succeeded in having the table not display anything at all
(which doesn't make sense to me either).
Is it possible to know exactly which array element was edited,
without registering observers on the entire contents of the array?
I figure it has something to do with the keyPath, but the exact
something has thus far eluded me.
If you want an array property observer to see what specific elements
changed, instead of the array as a whole, you need to add some
machinery to the 'thing' object's class: the KVO-compatible indexed
accessors insertObject:inFieldListAtIndex: and
removeObjectInFieldListAtIndex: (and, if you wish, the
replaceObject... variant too). See here for details:
http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html#/
/apple_ref/doc/uid/20002174-178830-BAJEDEFB
However, be careful about relying on this approach. A change to a
property (like your 'value') of an object in an array *isn't* a change
to the array, and doesn't cause a KVO notification to observers of the
array property. If you're getting a KVO notification for the array
property, then presumably it was caused by something the
NSArrayController did, and that may be an implementation artifact, not
something you can rely on.
_______________________________________________
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 arch...@mail-archive.com
