Thanks everyone. You are ALL right in your comments, and still my problem persists.
In reality, I have at least 6 external "triggers" or state-changes that determine (in a quite complicated way) whether or not I should observe that attribute. The (rather wise!) suggestion to start my key-path at self, and so avoid the need to watch for representedObject changes could cure one of the 6. Still I have the other 5... My question is general. Supposedly I could NOT start observing once, and stop it once. Reasons: 1. There are many instances of that NSViewController 2. This observation is quite frequent in time (could reach 100 times a second) 3. The code to filter-out unwanted value-changes is CPU intensive. (Accounting for 5 orthogonal conditions, upon which I should actually do something with the attribute change) So - I'd rather REMOVE the observation when I don't need it. Currently, I have a BOOL ivar that I update whenever I start/stop the observation, and so I can avoid double-observations or exceptions trying to remove non-existent observation. I ask about A GENERIC way to do this. I want to know my observation state programmatically. If that is impossible, or contrary to KVO design, I'll keep my current (rather ugly) code.... On 10 בספט 2012, at 06:12, Lee Ann Rucker wrote: > Yes, that approach is *so* much safer. When we switched over to doing it that > way so many "dealloc called while object was being observed" problems went > away. > > ----- Original Message ----- > From: "Quincey Morris" <[email protected]> > To: "Motti Shneor" <[email protected]> > Cc: "Cocoa-Dev List" <[email protected]> > Sent: Sunday, September 9, 2012 4:26:27 PM > Subject: Re: KVO Question: How to programmatically determine if one object is > observing another on a keyPath and context? > > On Sep 9, 2012, at 13:50 , Motti Shneor <[email protected]> wrote: > >> On 9 בספט 2012, at 22:04, Ken Thomases wrote: >> >>> Why is that a "however"? What's the problem? Since the representedObject >>> is KVO-compliant, all observations _through_ that property will >>> automatically follow it as it changes. >> >> Nope. When representedObject becomes nil, I DO NOT WANT to observe anything, >> and I need to remove the observance from the previous representedObject, >> BEFORE it is set to nil on my NSViewController. > > I think, by using the word "through", Ken is suggesting you do this: > > [self addObserver:self forKeyPath:@"representedObject.incomingNotes" > ...]; > > rather than this: > > [self.representedObject addObserver:self forKeyPath:@"incomingNotes" > ...]; > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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/lrucker%40vmware.com > > This email sent to [email protected] Motti Shneor e-mail: [email protected] phone: +972-8-9267730 mobile: +972-54-3136621 ---------------------------------------- Ceterum censeo Microsoftinem delendam esse _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
