Ken Thomases wrote:
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.
Not only did my code not sign up a string object for notifications, my
code did not sign up ANY object for notifications. So it has to involve
bindings, doesn't it? And getting rid of the cases where I had 2 enable
bindings on one control made the problem go away. (I guess I should
have given more detail in my original post.)
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.
Thanks for the idea, I'll try to remember about NSZombie if this problem
crops up again.
Part of the problem is that my project is built with Xcode 3.1, which
does not run on Tiger. I tried to set up remote debugging, but had all
sorts of trouble. And by the way, Instruments, which you mention,
doesn't run on Tiger either.
--
James W. Walker, Innoventive Software LLC
<http://www.frameforge3d.com/>
_______________________________________________
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
