That depends on how the bar class from your OP (or one of its
superclasses) implemented bind:toObject:withKeyPath:options:. That
code may not have checked the passed-in binding name, and may have
unconditionally added itself as an observer of ivar_controller for
the key path "selection.displayName". That would have guaranteed
that bar would receive
observeValueForKeyPath:ofObject:change:context: messages whenever
foo's displayName property was changed in a KVO-conforming manner.
(For example, if, in listing 2 of the how-it-works document, the
check of the binding name against "angle" were omitted.)
Then, what happens next is up to bar's implementation of
observeValueForKeyPath:ofObject:change:context:. If it blindly did
[self setTitle:[object valueForKeyPath:keyPath]], then that would
explain it. (For example, if, in listing 4, the test of context
The superclass would be NSView, which doesn't declare
bind:toObject:withKeyPath:options: in its header file, nor does
NSResponder, so it's likely NSObject's implementation, whatever it
does. Interestingly, NSObject's header file doesn't declare this as a
method either, although NSKeyValueBinding.h declares it as a category
on NSObject, which is apparently why the compiler doesn't complain.
Also interestingly, the only reference to the
bind:toObject:withKeyPath:options: method that comes up in an API
search of the documentation is from the NSKeyValueBindingCreation
protocol, which states this:
"Establishes a binding between a given property of the receiver and
the property of a given object specified by a given key path."
Since this doesn't seem to be actually the case, someone ought to file
a report on the documentation about this.
Oh well, thanks for your patience with my questions.
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