• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?


  • Subject: Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
  • From: Jerry Krinock <email@hidden>
  • Date: Sat, 30 Jan 2010 07:29:16 -0800

Keith, thanks for your comments too.

On 2010 Jan 30, at 03:24, Quincey Morris wrote:

> Does that throw any light on the matter?

Obviously, yes.

Now let me try and answer my original questions...

> How do you know when a binding is going to be unidirectional or bidirectional

You must study the implementation of this method in the object receiving the bind:::: message or, if that's private, the Cocoa Bindings Reference (i.e. "Binding is Read-only").

> how can you control this?

By subclassing and writing your own implementation of bind::::.

> Why are bindings A, B, C and D bidirectional but E is only unidirectional?

Regarding A, B, C and D: Apparently, NSButton's implementation of bind:::: sets up observers in both directions when binding to the "value" binding.

Regarding E:  Foo does not implement bind:::, so NSObject's implementation is used, and this implementation, apparently, only sets up one observer in one direction.


So here's another addition to my growing list of Why Dummies Like Me Find Bindings So Confusing

To the documentation,

- (void)bind:toObject:withKeyPath:options:

Establishes a binding between a given property of the receiver and the property of a given object specified by a given key path.

I would add this:

Details: We might say that the default implementation establishes a binding which is unidirectional -- observes and passes value changes only from the bound-to object back to the receiver.  But if we said that, we'd have to document the implementations in the many Cocoa subclasses of NSObject which override this method to establish bidirectional bindings.  But since we didn't say that, we don't need to document all those overrides, and you must look instead in the Cocoa Bindings Reference to find out whether "Binding is Read-Only".  Tip: When using this (NSObject) implementation, you *may* find that it establishes a unidirectional binding ;)  ;)

_______________________________________________

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

  • Follow-Ups:
    • Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
      • From: Keith Duncan <email@hidden>
References: 
 >bind:toObject:withKeyPath:options: Unidirectional or Bidirectional? (From: Jerry Krinock <email@hidden>)
 >Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional? (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Returning a nil float?
  • Next by Date: Re: Returning a nil float?
  • Previous by thread: Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
  • Next by thread: Re: bind:toObject:withKeyPath:options: Unidirectional or Bidirectional?
  • Index(es):
    • Date
    • Thread