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 13:58:00 -0800
On Mar 1, 2012, at 13:23 , Per Bull Holmen wrote:
> OK. I haven't thought of KVO-compliance at the <parameterName> level
> because no values can change at this level. Only the controller's
> parameterInfo property can change, by replacing it. That's what I
> meant by calling the parameterInfo object immutable. No property
> values can change for one instance of PBH_ParameterInfo class. But I
> have seen some suggestions on the web (in response to others with
> similar problems), that I must explicitly set each property to nil in
> a KVO-compliant manner in my dealloc method. I didn't think the
> problem could be at this level, but I might try that.
On thinking more, I can't convince myself that KVO compliance is really the issue (though it *could* be, for some reason I can't think through right now).
The point is that if every UI item is bound to controller.parameterInfo.something… then changing the "parameterInfo" property KVO compliantly, as you do, should be enough to detach the UI items from observing the old parameterInfo, without worrying what happens further down the key path. Therefore, it's something else.
You can *try* dealloc voodoo, but I think it's crucial to look at the observerInfo in the debugger. And, the number of remaining observers may be more informative than what they are.
_______________________________________________
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