Re: NSEditor, NSEditorRegistration Protocols
Re: NSEditor, NSEditorRegistration Protocols
- Subject: Re: NSEditor, NSEditorRegistration Protocols
- From: Allan Odgaard <email@hidden>
- Date: Sun, 7 Mar 2004 21:33:25 +0100
On 7. Mar 2004, at 20:17, mmalcolm crawford wrote:
By the message [mySlider bind:@"value" toObject:self
withKeyPath:@"sliderValue" options:nil], the slider is instructed:
bind:@"value"
If whatever is associated with "value" changes,
toObject:self
tell the specified object that
withKeyPath:@"sliderValue"
its (the object's) "sliderValue" has changed
Ah, thanks for this info! So just to be clear: the default NSView
subclasses do overwrite bind:toObject:withKeyPath:options: so that
a) they support virtual keys (i.e. not accessible through KVC),
b) (for some classes) they are able to use the NSEditor protocol
(which would be more difficult if they were to rely on the default
implementation), and
c) notify the observable object (through KVC).
Though the latter is not the default behavior for non-NSView objects,
illustrated by this example:
@interface Dummy : NSObject { int someValue; }
@end
@implementation Dummy
@end
Dummy *obj1 = [Dummy new], *obj2 = [Dummy new];
// a binding similar to what I showed for the slider
[obj1 bind:@"someValue"
toObject:obj2
withKeyPath:@"someValue"
options:nil];
printf("%d, %d\n", obj1->someValue, obj2->someValue);
[obj1 setValue:[NSNumber numberWithInt:3] forKey:@"someValue"];
printf("%d, %d\n", obj1->someValue, obj2->someValue);
[obj2 setValue:[NSNumber numberWithInt:5] forKey:@"someValue"];
printf("%d, %d\n", obj1->someValue, obj2->someValue);
The output is:
0, 0
3, 0
5, 5
This is why I thought the controller was also observing the view.
In my own view-subclasses I do as outlined in my original letter, i.e.
have the keys as real keys and rely on the default implementation of
bind:... -- that way I have to make the controller observe the views,
though I try to cut out the controller part and will generally bind my
model directly to my view and vice versa.
To help with this (remove the need for a controller) I have also tried
to make a re-usable implementation of
observeValueForKeyPath:ofObject:change:context: -- it decides which
action to take based on the context, so for example one action might be
to call a method with the new value as argument, which is similar to
what bind:... does (it calls setValue:forKey:), but the requirement of
the receiver being KVC-compliant for the key is gone (so I can e.g.
bind the currentSongPath to setTitleWithRepresentedPath:).
I also have some printf-capability, so the value of a key can be nicely
formatted and then passed on (similar to what a value transformer could
do, except that one needs to register a new object for each parameter)
and so on...
Some may recognize such features from MUIs notify system, as that was
indeed the source if inspiration for these things :)
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.