Re: How to observe and bind (KVO/KVB) to a value generated at runtime...
Re: How to observe and bind (KVO/KVB) to a value generated at runtime...
- Subject: Re: How to observe and bind (KVO/KVB) to a value generated at runtime...
- From: Andre <email@hidden>
- Date: Fri, 24 Feb 2006 19:34:09 -0800
Thanks Camillo, I thought nobody would reply!
On 2006/02/24, at 17:03, Camillo Lugaresi wrote:
On 24/feb/06, at 23:35, email@hidden wrote:
Title says it all.
I need to provide a proxy object that is KVB/KVO compliant for a
key not yet known until its requested.
I've implemented a proxy object that pipes set/Key values for Key
value coding, but when I return a proxy object
from an array index accessor (countOfItems/ItemAtIndex etc. style)
the table view wants to bind its text values to a key
not yet known. So when my proxy gets a undefinedValueForKey
message it checks if the object it wraps has a certain
conditions that it can take the value for that key, so I can
return a value or also set it.
The problem is that the following message occurs when returning my
proxy:
[<NSKeyValueArray 0x541b080>
addObserver:forKeyPath:options:context:] is not supported. Key
path: order
So I'm wondering, since I cant "pipe" values back and forth to the
wrapped object when bindings are concerned, how can I allow the
table column or other item bind to the underlying (wrapped) value??
It is definitely possible to bind to properties that are accessed
using valueForUndefinedKey: and setValue:forUndefinedKey:.
Really, thats a pleasant surprise. Thanks for that info.
As an example, the wrapped object always has a variable called
"value," so what ever is sent or retrieved to the proxy, even if
its unknown,
I still want it to bridge to the wrapped object....... should I
override addObserver:forKeyPath:options:context: in the proxy and
pass it
to the wrapped object???
I'm not sure if that's safe. Clients might get confused if they
think they're observing one object and start getting notifications
from another. It's probably better to implement
addObserver:forKeyPath:options:context:, removeObserver:forKeyPath:
and observeValueForKeyPath:ofObject:change:context: on the proxy so
that it registers/unregisters itself as an observed on the wrapped
object and passes on notifications.
Then again, the KVO contract requires you to notify observers
before and after a property is changed, and respecting that
requirement in a proxy object is not easy when KVO only gives you a
single notification (IMHO this can be considered a design flaw in
the API, but you have to deal with it).
It is much easier to make the wrapped object a property of the
proxy, and bind to it using a key path (eg proxy.object.value
instead of proxy.value).
Thats what I just thought of, I think this is the best way to go...
I wish in some ways apple had a public "NSKVBObjectProxy" (separate
from NSProxy)
that could perform the same magic the bindings proxies do.
Well, here is now the problem: after further investigation though,
whats happening is that
my generated property returns an NSArray (either by KVC indexed
accessors or by pure array accessor)
and the object (NSTableColumn) treats the returned array like a
single object. (Thats why I get the above error - <NSKeyValueArray>
addObserver:...... is not supported)
IOW, if I bind "value" in Interface Builder, to extraData.name to a
controller object, the "extradata" accessor
is called on my arraycontroller, but then the table column mistakenly
tries to bind its value key "name" into the NSArray I returned.
If I bind to "arrangedObjects" then the table column "magically"
knows its an array being returned and an binds to each object in
the array, otherwise whatever gets bound doesn't know whether its an
array or a single object being returned........
This seems like a major orversight in the frameworks: it doesn't
check if what is returned by the binding is an NSArray-type object...
It simply knows if the binding is "selectedObjects" or
"arrangedObjects" its treated like an array, otherwise no.... so I'm
a bit perplexed how to get around this.
Thanks Camillo for the pointers BTW.
Andre
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden