On Aug 25, 2009, at 2:02 PM, James Walker wrote:
When my app ran on Tiger, there was an NSInvalidArgumentException
with the reason:
"-observeValueForKeyPath:ofObject:change:context: only defined for
abstract class. Define -[NSCFString
observeValueForKeyPath:ofObject:change:context:]!"
That seemed to happen when I had 2 enabled bindings on the same
checkbox. Is that a known limitation?
I don't think this has anything to do with having 2 bindings.
Notice the mention of NSCFString in the exception reason. It appears
that you have signed up some string object to receive KVO change
notifications for some object's property. Since NSCFString isn't
equipped to handle receiving those notifications, you get an
exception. The reason string is saying, "An object of class
NSCFString has had -observeValueForKeyPath:ofObject:change:context:
invoked on it. This class didn't override that method, and so the
base-class method implementation was invoked, and that implementation
throws an exception telling you about the problem."
Of course, although it's advising you to implement an override of -
observeValueForKeyPath:ofObject:change:context: on NSCFString, that's
not what you really need to do. You need to figure out why you
subscribed a string object to receive such KVO change notifications in
the first place. It's almost certainly not what you meant to do.
One likely candidate is a memory management problem. You may not have
actually signed up a string object to receive such notifications.
Instead, you may have signed up some other object but allowed that
object to deallocate itself by failing to retain it. So, that object
disappeared. Later, a string object was allocated at the same memory
location. Now, it is receiving KVO change notifications it was never
supposed to. You can use NSZombie to diagnose this particular issue
and learn which class of object was originally observing property
changes. You can also use the Object Alloc instrument or
malloc_history to learn where in your code that object was originally
allocated.
Regards,
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 arch...@mail-archive.com
