Re: KVO Response for incomplete paths
Re: KVO Response for incomplete paths
- Subject: Re: KVO Response for incomplete paths
- From: Gordon Apple <email@hidden>
- Date: Wed, 21 May 2008 13:51:11 -0500
OK, thanks. That helps on the KVO responses. However, I have other
questions about the entire KVO process.
Not having access to the innards of KVO, I wonder how dymanic the
process is. For example, my inspector bindings are through an object
controller which binds through MSApp.mainWindow which seems to successfully
switch its focus to a new main window with no problems. This, to me,
indicates that the process operates dynamically according to the path,
rather than statically binding when it is set up.
So my new question is whether or not I can successfully observe a
property that does not exist at registration time, and then have it observe
properly when the path is created. E.g., register to observe
xxx.shadow.angle when shadow does not exist, then add the shadow object and
have xxx.shadow.angle be observed properly.
> On May 19, 2008, at 2:02 PM, Gordon Apple wrote:
>> 1. What happened when you try to observe a property that doesn't
>> exist?
>> (e.g., is there is no shadow, there is no "shadow.angle". Do I
>> have to test
>> "hasShadow" to disallow observing "shadow.angle when the properties
>> list is
>> scanned?
>>
>> 2. What happens when you try to stop observing a property that
>> does not
>> exist (a la Q1)?
>>
>> I was hoping both of these would simply not do anything if the
>> path was
>> not complete (e.g., "shadow.angle"). Unfortunately, it appears to be
>> blowing me out of the water (unless that is actually happening
>> elsewhere).
>> Is KVO supposed to have a benign response to these cases or am I
>> going to
>> have to filter them when scanning the properties list?
>
> I believe it invokes the valueForUndefinedKey: method on the object
> which is missing the property at that point along the key path. The
> default implementation of that method throws an
> NSUndefinedKeyException, but you can override it to do something
> else. Or, you can catch the exception to learn that the attempt to
> observe that key path failed.
>
> See here: http://developer.apple.com/documentation/Cocoa/Conceptual/
> KeyValueCoding/Concepts/BasicPrinciples.html#//apple_ref/doc/uid/
> 20002170-178726
>
> That's discussing KVC rather than KVO specifically, but KVO is
> implemented on top of KVC so it still applies.
>
> Do a full-text search for "valueForUndefinedKey" to find more
> discussion related to this subject.
>
> By the way, if there are places where it makes sense for your code to
> observe or bind to a key path including the "shadow" property on
> objects which are not known to be anything more specific than Shapes,
> then you might want to move the shadow property up to the Shape class
> and have a default implementation which just returns nil.
>
> Cheers,
> Ken
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden