Re: Why aren't my bindings firing?
Re: Why aren't my bindings firing?
- Subject: Re: Why aren't my bindings firing?
- From: Charles Srstka <email@hidden>
- Date: Sat, 28 Jun 2008 10:17:35 -0500
On Jun 28, 2008, at 4:55 AM, Ken Thomases wrote:
Yeah, and the description of the "binding" parameter of that method
also says it's a "key path for a property of the receiver", which
contradicts my understanding (as we've been discussing).
So, my curiosity piqued, I did some more reading. The "Bindings"
chapter of the Cocoa Fundamentals Guide <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_6.html
> also directly contradicts what I've been saying. It unambiguously
states that you can bind together any two objects so long as they're
KVC/KVO-compliant. Now _I'm_ confused -- and worried that I've been
spreading misinformation.
I wouldn't worry about that too much - everything you said seems to
jibe perfectly with what views do - the text field's binding *is*
called "value" and not "stringValue" (that was my bad), and there's no
corresponding "value" instance method on NSTextView nor any of its
superclasses, nor does running class-dump on the AppKit turn up a
"value" method on any class in the AppKit except for
_NSControllerKeyValuePair, whatever that is. So in the typical case of
views, you'd seem to be correct that the bindings represent something
other than properties, and live in a different namespace.
However, NSObject does have a default implementation of
bind:toObject:withKeyPath:options:, which must have some purpose.
Setting up a two-way binding by running the binding twice does seem to
work, although I don't know how "kosher" it is, and it does seem less
than satisfactory to me as, like you mentioned, it doesn't seem to
work with a key path for the first argument, making it necessary to
take the controller out of the equation. So it's definitely probably
better to override bind:toObject:withKeyPath:options: on the view, to
allow for using a controller and having a cleaner implementation.
After thinking about it a bit, though, I don't think infinite loops
should be a problem, because my guess as to how the bindings work is
that the willChangeValueForKey: method probably registers the object
somewhere as being in the middle of setting that key, and then when
the bindings system goes around looking for objects to set that key
for, it would pass over the ones that have indicated they're already
setting that key by calling willChangeValueForKey: I'd expect then
that didChangeValueForKey: would clear that status (along with asking
the bindings system to update any object that observes that key and
hasn't called willChangeValueForKey: recently). So infinite loops
shouldn't be much of a problem if I'm understanding this right.
I think what we can all take home from this is that the documentation
for bindings needs to be clearer and less self-contradictory on the
very basic concept of exactly what Cocoa Bindings *is*.
Charles
_______________________________________________
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