On Mon, Jun 30, 2008 at 12:38 AM, Hamish Allan <[EMAIL PROTECTED]> wrote: > On Mon, Jun 30, 2008 at 5:33 AM, Charles Srstka > <[EMAIL PROTECTED]> wrote: > >> Wait, what? Okay, that contradicts the understanding that I had come to... >> so the built-in views establish two-way bindings *without* overriding >> bind:toObject:withKeyPath:options:? Great, that puts us back to square one! > > It would seem so, but in fact I was mistaken about the equivalence > between "value" and "objectValue" bindings: the binding to objectValue > is only a one-way binding. I guess that difference would make it safer > to use a separate namespace.
I am largely bindings clueless, so beware.... NSObject's -bind:... method does two things. First, it sets up an automatic one-way binding from the model object to the view object. When the model is changed, the view's key is automatically set to the new value. Second, it sets up an info dictionary for that binding. Although Apple's sample code shows overriding -bind:... to store information about the new binding, it doesn't look like this is necessary. You can simply use -infoForBinding: to obtain the info dictionary, extract the bound object and key, and use that information to update the model object. I'd assume this is what the Apple classes do, and it seems to me to be a lot simpler than overriding -bind:... to stash away a bunch of information that's already being stored for you anyway. The reason the objectValue binding doesn't work both ways is because NSControl doesn't implement this kind of thing when its objectValue changes. You need to implement the view->model changes manually they don't come for free just because you're KVC compliant, and NSControl doesn't implement it for objectValue. You get the model->view direction for free with KVC complaince, which is why it halfway works. Mike _______________________________________________ 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 [EMAIL PROTECTED]
