FROM : Ken Thomases
DATE : Thu May 15 06:54:48 2008
On May 14, 2008, at 11:43 PM, Daniel Child wrote:
>
> On May 15, 2008, at 12:09 AM, Ken Thomases wrote:
>
>> Can you be more specific about why you want your controller to
>> observe its own number property? What are you trying to
>> accomplish? I suspect there's another way to accomplish what
>> you're interested in.
> I'm simply trying to reduce bindings to the most basic case: type
> into a text field, have that value observed, and then reflect it
> somewhere else (as in another text field). The actual application I
> have in mind uses text fields to enable the user to specify sort
> fields, and rather than have a bunch of methods to check those
> values prior to sorting, I thought I could use bindings to
> automatically have those values set as soon as the user types them
> in. (I've used textDidChange in the past to accomplish something
> similar, but I thought this would be an easy case to try bindings.
> Especially since I might want to provide a more elegant interface
> for specifying sort fields prior to the sort.
First, bindings are implemented using KVO, but KVO is not the same as
bindings.
Second, to do what you're talking about, you'd bind the text field's
value binding to the controller-model. There's no reason to have the
controller observe its own property in this scenario.
Third, while you can definitely set bindings up in code, that's not
"reduc[ing] bindings to the most basic case". Setting the binding up
via IB is the most basic case.
>>> In other words, your "myFoo addObserver: self <THE CONTROLLER>
>>> forKeyPath: @"number" becomes....
>>>
>>> - (void) awakeFromNib {
>>> [self addOberver: self forKeyPath: @"number" options: 0 context:
>>> NULL];
>>
>> There's a typo there. You've missed the "s" in "addObserver".
> Oops. Sorry about that, but I get a runtime error all the same:
>
> [<NSApplication 0x119640> valueForUndefinedKey:]: this class is not
> key value coding-compliant for the key values.
> 2008-05-15 00:32:19.909 StringBinding[564:10b] *** Terminating app
> due to uncaught exception 'NSUnknownKeyException', reason:
> '[<NSApplication 0x119640> valueForUndefinedKey:]: this class is
> not key value coding-compliant for the key values.'
This seems to have nothing to do with the above code. First, the key
involved is called "values" not "number". Second, the receiver is
the NSApplication instance. So, why is something trying to access a
non-existent "values" property of the NSApplication class?
NSUserDefaultsController has a "values" property. I wonder if you
temporarily had a binding to that which you attempted to redirect
toward File's Owner but you didn't change it properly.
-Ken
DATE : Thu May 15 06:54:48 2008
On May 14, 2008, at 11:43 PM, Daniel Child wrote:
>
> On May 15, 2008, at 12:09 AM, Ken Thomases wrote:
>
>> Can you be more specific about why you want your controller to
>> observe its own number property? What are you trying to
>> accomplish? I suspect there's another way to accomplish what
>> you're interested in.
> I'm simply trying to reduce bindings to the most basic case: type
> into a text field, have that value observed, and then reflect it
> somewhere else (as in another text field). The actual application I
> have in mind uses text fields to enable the user to specify sort
> fields, and rather than have a bunch of methods to check those
> values prior to sorting, I thought I could use bindings to
> automatically have those values set as soon as the user types them
> in. (I've used textDidChange in the past to accomplish something
> similar, but I thought this would be an easy case to try bindings.
> Especially since I might want to provide a more elegant interface
> for specifying sort fields prior to the sort.
First, bindings are implemented using KVO, but KVO is not the same as
bindings.
Second, to do what you're talking about, you'd bind the text field's
value binding to the controller-model. There's no reason to have the
controller observe its own property in this scenario.
Third, while you can definitely set bindings up in code, that's not
"reduc[ing] bindings to the most basic case". Setting the binding up
via IB is the most basic case.
>>> In other words, your "myFoo addObserver: self <THE CONTROLLER>
>>> forKeyPath: @"number" becomes....
>>>
>>> - (void) awakeFromNib {
>>> [self addOberver: self forKeyPath: @"number" options: 0 context:
>>> NULL];
>>
>> There's a typo there. You've missed the "s" in "addObserver".
> Oops. Sorry about that, but I get a runtime error all the same:
>
> [<NSApplication 0x119640> valueForUndefinedKey:]: this class is not
> key value coding-compliant for the key values.
> 2008-05-15 00:32:19.909 StringBinding[564:10b] *** Terminating app
> due to uncaught exception 'NSUnknownKeyException', reason:
> '[<NSApplication 0x119640> valueForUndefinedKey:]: this class is
> not key value coding-compliant for the key values.'
This seems to have nothing to do with the above code. First, the key
involved is called "values" not "number". Second, the receiver is
the NSApplication instance. So, why is something trying to access a
non-existent "values" property of the NSApplication class?
NSUserDefaultsController has a "values" property. I wonder if you
temporarily had a binding to that which you attempted to redirect
toward File's Owner but you didn't change it properly.
-Ken
| Related mails | Author | Date |
|---|---|---|
| Daniel Child | May 14, 21:08 | |
| Ken Thomases | May 14, 23:11 | |
| Daniel Child | May 15, 05:54 | |
| Ken Thomases | May 15, 06:09 | |
| Daniel Child | May 15, 06:43 | |
| Ken Thomases | May 15, 06:54 | |
| Daniel Child | May 16, 04:47 | |
| Ken Thomases | May 16, 05:33 |






Cocoa mail archive

