You misunderstood what I was saying.
On May 15, 2008, at 9:47 PM, Daniel Child wrote:
You were right, it accidentally switched to user defaults. Removing
that and setting it back to controller still leads to a runtime
exception.
2008-05-15 22:30:53.718 StringBinding[290:10b] An uncaught exception
was raised
2008-05-15 22:30:53.719 StringBinding[290:10b] [<NSApplication
0x119650> valueForUndefinedKey:]: this class is not key value coding-
compliant for the key values.
The above error says that something is trying to use KVC to access a
property called "values" on an NSApplication instance. The
NSApplication class does not provide such a property.
I suspect you have a binding somewhere in your main nib (typically
MainMenu.nib) where the controller is File's Owner (which is the
NSApplication instance for this nib) and the model key path is
"values" (or starts with "values."). This can happen accidentally if
you at some point had a binding to the Shared User Defaults Controller
and you later changed the controller for that binding without properly
adjusting the key paths.
2008-05-15 22:30:53.723 StringBinding[290:10b] *** Terminating app
due to uncaught exception 'NSUnknownKeyException', reason:
'[<NSApplication 0x119650> valueForUndefinedKey:]: this class is not
key value coding-compliant for the key values.'
2008-05-15 22:30:53.723 StringBinding[290:10b] Stack: (
2449281611,
2445869307,
2449280369,
Under bindings, "Values" shows that it is set to Controller.number.
Please be more precise. At what GUI element's bindings are you
looking? Off-hand, I can't think of any class which exposes a binding
called "Values" plural. Many expose a binding called "Value"
singular. Note though, that the above error is not referring the name
of the binding, it's referring to the name of a key.
I suspect you're focused on one particular binding, and assuming the
error is happening because of that, while it's really due to some
other binding that you're not paying attention to.
I have set up conventional accessors. Under setNumber: I also try to
bounce the value back to an outlet text field using
[valueField setStringValue: [self number] stringValue];
You can do that, but you're missing the point of bindings. Why isn't
the text field just bound to the same model property, so it
automatically reflects any changes to that property?
Have you read through the Cocoa Bindings Programming guide? It has a
walkthrough of just such a simple bindings example as you're trying to
reproduce.
But it doesn't even run. I am not clear why it is claiming NSApp is
not key value coding-compliant when I set up the binding to the
controller object.
As I say, I think you've got a form of tunnel vision that's common
when developing. You're certain that the problem is happening in the
part of the nib where you're focused, so you're not looking
elsewhere. Take a step back and see if it's not in a different part
of the nib, or possibly somewhere in your code.
Try viewing the nib in list mode. Use Command-A to select all, and
then Option-right-arrow to show every single object within it. Then,
call up the bindings inspector (Command-4) and use the arrow keys to
select each object in the nib in turn. Eventually, you'll find the
object with the incorrect binding. (Prior to IB 3 there was a much
easier way to find all connections among objects. I submitted a bug
about the loss of usability, and Apple acknowledged it, but they
haven't corrected it yet.)
-Ken
_______________________________________________
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]
