• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Overriding bind:toObject:withKeyPath:options:
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Overriding bind:toObject:withKeyPath:options:


  • Subject: Overriding bind:toObject:withKeyPath:options:
  • From: David Aames <email@hidden>
  • Date: Sun, 19 Nov 2006 23:16:22 +0000

Hello all,

I've been reading through the archives to see how people override bind:toObject:withKeyPath:options: when they need to implement their own bindings and the best thread which I could find is this one - http://www.cocoabuilder.com/archive/message/cocoa/2006/9/21/171579 which doesn't actually answer the question. If I send a bind:toObject:withKeyPath:options: message to a simple NSObject derived class NSObject's implementation will observe the bound-to object's property. Now here's the code from Apple which shows how they override bind:toObject:withKeyPath:options: in an NSView subclass:

- (void)bind:(NSString *)bindingName
toObject:(id)observableController
withKeyPath:(NSString *)keyPath
options:(NSDictionary *)options
{
if ([bindingName isEqualToString:@"angle"])
{
// observe the controller for changes -- note, pass binding identifier
// as the context, so we get that back in observeValueForKeyPath:...
// that way we can determine what needs to be updated.
[observableController addObserver:self
forKeyPath:keyPath
options:nil
context:AngleObservationContext];

// register what controller and what keypath are
// associated with this binding
[self setObservedObjectForAngle:observableController];
[self setObservedKeyPathForAngle:keyPath];
// options
angleValueTransformerName = [[options objectForKey:NSValueTransformerNameBindingOption] copy];
allowsMultipleSelectionForAngle = NO;
if ([[options objectForKey:NSAllowsEditingMultipleValuesSelectionBindingOption] boolValue])
{
allowsMultipleSelectionForAngle = YES;
}
}


if ([bindingName isEqualToString:@"offset"])
{
[observableController addObserver:self
forKeyPath:keyPath
options:nil
context:OffsetObservationContext];

[self setObservedObjectForOffset:observableController];
[self setObservedKeyPathForOffset:keyPath];
allowsMultipleSelectionForOffset = NO;
if ([[options objectForKey:NSAllowsEditingMultipleValuesSelectionBindingOption] boolValue])
{
allowsMultipleSelectionForOffset = YES;
}
}

[super bind:bindingName
toObject:observableController
withKeyPath:keyPath
options:options];

[self setNeedsDisplay:YES];
}


My question is wouldn't the super implementation also start observing the key (so we end up observing it twice) or does NSView override NSObject's bind:... without using the super implementation? As far as I understand we need to call the super implementation in NSView's because the super implementation will handle the other bindings (eg "value" etc). So what are the guidelines to overriding bind:...? As far as I can see from the code we need to call the super's implementation if we inherit from NSView. But what about if we're implementing our own bindings in a class which inherits from NSObject? (eg our own NSController subclass)? Do we use the super's implemention? Or not because there are no bindings to inherit? For example if I want to create a binding in a NSObject subclass and the binding name doesn't actually correspond to the property name I would have to override bind:. The question is: do I call the super's implementation or not? (so in order to answer this question I need to know what it is doing which we can guess from the cocoa bindings docs but I want to be sure).
_______________________________________________
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
  • Prev by Date: Re: NSXML - preserving white space in new elements
  • Next by Date: Re: window shadow and setAlphaValue bug?
  • Previous by thread: Re: window shadow and setAlphaValue bug?
  • Next by thread: Debugging complex autorelease/release/retain issue
  • Index(es):
    • Date
    • Thread