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 (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
