Re: Why doesn't -[NSArrayController selection] et al fire keyPathsForValuesAffectingKey?
Re: Why doesn't -[NSArrayController selection] et al fire keyPathsForValuesAffectingKey?
- Subject: Re: Why doesn't -[NSArrayController selection] et al fire keyPathsForValuesAffectingKey?
- From: Jerry Krinock <email@hidden>
- Date: Fri, 2 Apr 2010 22:17:25 -0700
On 2010 Apr 02, Quincey Morris wrote:
> I only see 4 distinct keys in your list below, since one of them is duplicated.
Yes, you're correct. There are only 4.
> I'm suspicious of the "fooArrayController" part. Is it *just* an instance variable?
It's an IBOutlet, and also there is a getter which returns the IBOutlet.
> If so, then it gets to be a property only by virtue 'accessInstanceVariablesDirectly' being YES (which is bad magic, but a different story). If so, then it's not KVO compliant, though the only scenario I can think of where this would cause keyPathsForValuesAffecting... to fail is if something was already observing "selectedFoo" before the nib file containing it was loaded.
There is something else observing "selectedFoo", and it is in the nib, another "detail" array controller, to which is bound a table which displays the 'bars', shall we say, of the 'selectedFoo'.
So you're telling me that all of the keys in a key path must be KVO-compliant. I hadn't thought so, because in the key path "fooArrayController.selection", the fooArrayController is hard-wired to an IBOutlet and never changes. But now I see a possible explanation is that the Cocoa Bindings Wizard created its observer before the fooArrayController got wired to its outlet.
On 2010 Apr 02, Kyle Sluder wrote:
> Because +keyPathsForValuesAffectingValueForKey relies on NSKeyValueObservingOptionPrior, which NSArrayController doesn't support.
That would explain the problem also.
So the answer is either Quincey's explanation, or this bug, or both.
> File a bug. It'll get dup'ed, but do it anyway.
If I don't hear more from you on this, Kyle, I'll test and file a bug tomorrow.
Other Details...
On 2010 Apr 02, Quincey Morris wrote:
> TBH, if I had a reason to want to observe the selection (keyPathsForValuesAffecting... being a special case of that), I'd create a real NSIndexSet* selectedItemIndexes property of my own, bind the array controller's "selectionIndexes" binding to that (so that the array controller maintains the real property for me), and then observe the real property, leaving all reference to the array controller itself out of my code.
Yes, that seems like it would work.
>> I solved the problem by eliminating all this code and binding my button's 'enabled' binding instead to the array controller's 'selection' and, to my surprise, it worked. My surprise is because, according to superclass NSObjectController documentation, 'selection' returns NSNoSelectionMarker when there is no selection, not nil which is what my NSIsNotNil value transformer would expect.
>
> I think the answer is that it works because it's a frameworks binding, and frameworks bindings are very clever in ways we aren't actually told about. It probably knows whether it's allowed to pass on the marker value, or if it must convert the marker to some kind of "real" object first -- hence nil. Or perhaps passing NSNoSelectionMarker to the value transformer is simply special-cased somewhere.
That's what I was afraid of.
_______________________________________________
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