Re: Binding/KVC : valid accessor for framework objects. (was: implicit and explicit invocation of description method)
Re: Binding/KVC : valid accessor for framework objects. (was: implicit and explicit invocation of description method)
- Subject: Re: Binding/KVC : valid accessor for framework objects. (was: implicit and explicit invocation of description method)
- From: Max Barel <email@hidden>
- Date: Tue, 5 Oct 2004 00:44:43 +0200
Le 2 oct. 04, à 23:44, Scott Anguish a écrit :
On Oct 2, 2004, at 7:57 AM, Max Barel wrote:
Yes, the description method is documented, I know and that's why I
tried to use it. That's not the point.
What is undocumented is the implicit CALL to this method, when an
NSTextView.value is bound to an NSDictionary object.
Oh, I see.
well, value expects an NSString... if you try and NSLog a
dictionary object, you'll see that it also calls description.
is this documented? Well, it's nothing to do with bindings, so
I'm not sure.
why are you trying to hook an NSDictionary up directly to a next
view?
But I don't! I was precisely trying to get a string representation of
the dictionary to display its content (read-only) in a text view (in
this precise case, to display a NSScreen description). That's why I
used an KVC accessor of the form anNSDictionary.description, which
doesn't work. And I tried the direct bind to the object while trying
figure the problem.
I'm currently learning and testing the binding layer to use it in my
next app.
I'm aware of what can be done with categories and -more binding
specific- with value transformers.
What is still unclear for me is: What is a valid accessor for a
framework object?
The NSDictionary interface does not show any public ivar. Does this
means that it has NO KVC property?
Or else, are parameterless methods valid accessors to the object
information?
If yes, why another method returning an NSString does not work neither
:
- (NSString *)descriptionInStringsFileFormat;
If not, why the runtime implicitly calls the description method that
you can't use an an accessor.
IMHO, this is misleading.
_______________________________________________
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