Re: Who is responsible for removing observers in longer key paths
Re: Who is responsible for removing observers in longer key paths
- Subject: Re: Who is responsible for removing observers in longer key paths
- From: Quincey Morris <email@hidden>
- Date: Thu, 01 Mar 2012 12:42:40 -0800
On Mar 1, 2012, at 11:26 , Per Bull Holmen wrote:
> parameterInfo.<parameterName>.<attributeName>
>
> "parameterInfo" is a literal key name, <parameterName> maps to a
> parameter in a plug-in, and must be resolved at run-time.
> <attributeName> is one of several attribute names, such as "minValue",
> "maxValue" etc. There is a value object that represents parameterInfo,
> which is of class PBH_ParameterInfo. […] When
> the info in the tree changes, the controller just makes a new
> parameterInfo instance, and replaces the entire tree with [self
> setParameterInfo:newParameterInfo]. What happens then is:
>
> 1) The view correctly updates, meaning it must have received the notification.
> 2) The old parameterInfo object is correctly deallocated.
> 3) I get an error in the console saying the parameterInfo object is
> being deallocated while there are still observers attached.
>
> These observers are clearly registered under-the-hood by NSObject's
> (?) implementation. When the controller object is asked to register an
> observer for the key path parameterInfo.linearGain.maxValue, it goes
> to the next property in the chain (parameterInfo), and registers some
> sort of proxy pbject as an observer for linearGain.maxValue. So my
> question is who is responsible for removing the observation when it is
> no longer needed, and how shall I make it happen The Right Way? […]
>
> If you say don't make the parameterInfo object immutable, instead
> create one mutable KVO-compliant object that stays there for the
> controller's life, that shouldn't be hard to do. I just want to learn
> how it's supposed to work.
No, it's nothing to do with the mutability of the parameterInfo object.
The problem is likely caused by lack of KVO compliance of your key path either at the <parameterName> or the <attributeName> level, or both. I think the console message suggests a place to set a breakpoint. Set one there, and then look at [self observationInfo] on the object being deallocated. The number and classes of the observers listed should give a clue to where it's going wrong.
Incidentally, if '[controller valueForKeyPath: @"parameterInfo.<parameterName>]' were invoked, what object would your controller return?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden