It's ok, you can do it if you like, monitor your own properties, however if all 
you really want to do here is, in your own class, do something more when 
mySelection is changed, you can write your own setter and put it in there 
yourself directly. 

-(void)setMySelection:(NSArray*)mySelection
{
        // set whatever instance variable you have for mySelection, with 
appropriate memory management if necessary

        // do the other stuff you want to do
}

you'll have to write the getter as well, you can't write one and synthesize the 
other any more. 

One more point, never, ever use addObserver:forKeyPath:options:context with a 
nil context. It's so tempting, it's such an easy habit to get into, it will get 
you one day and the resulting bug will make you tear your hair out for days. 
Set up a static for the context, use it, CHECK the context in the 
observeValueForKeyPath:.. call and only process if the context is yours else 
call super. Also, as Apple has now finally kindly allowed us to specify the 
context when we remove observers instead of the runtime guessing and getting it 
wrong, always use that version. 

On May 8, 2012, at 11:16 AM, Koen van der Drift wrote:

> One of my viewcontrollers uses the representedObject to bind to the 
> NSArrayController that holds all the data for the application (OS X, ARC on). 
> I declared a local property mySelection (an NSArray) and bind it to the 
> representedObject as follows:
> 
>    [self bind:@"mySelection" toObject:self.representedObject 
> withKeyPath:@"selectedObjects" options:nil];
> 
> So far so good.
> 
> Now when the user changes mySelection,  not only my local property needs to 
> be updated, but also some other parts in my code. So I cannot just rely on 
> the automatically generated setter, and thus need to monitor a change in 
> mySelection.  After some searching I came up with the following:
> 
>    [self.representedObject addObserver:self forKeyPath:@"selectedObjects"  
> options:NSKeyValueObservingOptionNew context: nil];
> 
> and then:
> 
> - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object 
> change:(NSDictionary *)change context:(void *)context
> {
>    if ([keyPath isEqualToString: @"selectedObjects"])
>    {
>       // do additional stuff
>    }
>    else 
>    {
>        [super observeValueForKeyPath:keyPath ofObject:object change:change 
> context:context];
>    }
> }
> 
> Again, this all works. Whenever the user changes the selection, 
> observeValueForKeyPath: gets called and the "do additional stuff" gets 
> executed.
> 
> But I have the feeling I am over-complicating things.  From reading on this 
> subject I get the impression the approach above seems to be more for 
> monitoring properties in other classes, not in the owner class.
> 
> So, is this the correct way to do this (responding to a change in a local 
> property, or am I overlooking something very obvious?
> 
> Thanks,
> 
> - Koen.
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.org


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to