On 2010 Feb 01, at 03:53, Quincey Morris wrote:
I'd point you to the the documentation:
(This is the quote from Cocoa Bindings Programming Topics the
documentation I quoted in my original post.)
I don't see how this can be clearer that bindings are bidirectional.
Yes. It is clear. And
On Feb 2, 2010, at 8:42 AM, Jerry Krinock wrote:
So now we have this paradox:
1. Cocoa Bindings Programming Topics says that bindings are bidirectional.
2. bind:toObject:withKeyPath:options: documentation says it establishes a
binding
3. bind:toObject:withKeyPath:options:
(Apologies for over-quoting here. And for the length of the response.)
On Feb 2, 2010, at 07:42, Jerry Krinock wrote:
On 2010 Feb 01, at 03:53, Quincey Morris wrote:
I'd point you to the the documentation:
(This is the quote from Cocoa Bindings Programming Topics the
documentation I
On Feb 2, 2010, at 1:20 PM, Quincey Morris wrote:
1. There are three (3) [III] agents involved in a binding.
-- Class A (typically some kind of view) defines+implements a binding
[behavior] identified by an attribute x. Attribute is not the best choice
of terminology, but it's what the
On Jan 31, 2010, at 19:03, Matt Neuburg wrote:
There's a common misconception here, and I see a lot of nonsense written
about it, to which I with difficulty restrain myself from responding. It's
all very simple.
(1) There is no such thing as a bidirectional binding; all bindings are
On Fri, 29 Jan 2010 22:52:34 -0800, Jerry Krinock je...@ieee.org said:
[this1]
This clearly states, twice, that ind:toObject:withKeyPath:options: creates
something which is bidirectional.
[this2]
This tells me that, as a minimum, a binding is only unidirectional.
How do you know when a binding is
1. The word binding is ambiguous. It refers on the one hand to the behavior
of a class that allows it to synchronize some attribute (such as a property,
but it could be something internal like an instance variable) to a property
of target objects. It also refers on the other hand to the
On Jan 30, 2010, at 4:24 AM, Quincey Morris wrote:
Does that throw any light on the matter?
Yes!
--Richard
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the
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
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.
This isn't what happens, run the following code:
static NSString
On 2010 Jan 30, at 09:12, Keith Duncan wrote:
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.
This isn't what
In Cocoa Bindings Programming Topics ▸ What Are Cocoa Bindings ▸
Supporting Technologies, I read:
A binding is established with a bind:toObject:withKeyPath:options:
message which tells the receiver to keep its specified attribute
synchronized ... with the value of the property... The
12 matches
Mail list logo
