On Mar 15, 2009, at 14:02, Marc Van Olmen wrote:
And then the above KVO worked. So I'm curious now why I need to add
[super observeValueForKeyPath: theKeyPath ofObject:theObject change:t
Because the documentation doesn't say anything about that. Is there
a documented reason when you have to call [super
observeValueForKeyPath ...]?
It's sort of obvious when you think it through. If you subclass an
object, and your subclass adds itself as an observer of something, the
superclass code may *also* have added itself as an observer of
something. Both scenarios result in the *same*
observeValueForKeyPath... being called.
Therefore, your observeValueForKeyPath... override must first check if
the notification is the one you established. If it is, you process it
and return without calling [super observeValueForKeyPath...]. If it is
not, you simply call [super observeValueForKeyPath...].
How do you decide if the notification is for you instead of the
superclass? That's a small hole in the API. To deal with it, you'll
have to set the context parameter to something unique to your subclass
(such as its name), and check the context in observeValueForKeyPath...
to decide if your code "owns" the notification or if the superclass
does.
This is obviously not ideal, and makes your observeValueForKeyPath...
override fairly ugly, but there it is ...
_______________________________________________
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
