Re: NSWindowController subclasses, and retain cycles
Re: NSWindowController subclasses, and retain cycles
- Subject: Re: NSWindowController subclasses, and retain cycles
- From: Ken Thomases <email@hidden>
- Date: Thu, 24 May 2012 10:48:11 -0500
On May 24, 2012, at 9:26 AM, Jonathan Taylor wrote:
> There appears to be some weird runtime voodoo behind the scenes involving NSAutounbinder, which I think is what should ultimately be sending the final release to A. That is what sends the final release to B, but that final release for A is missing under that third scenario above.
>
> I am concerned by the following post:
> http://theocacao.com/document.page/18
> This seems to imply there is some dodginess behind the scenes that Apple have bodged to try and make things work. The blog post is 8 years old, so I would have hoped this would be sorted by now(!), but it does sound remarkably close to my scenario here.
NSAutounbinder is part of the solution to the problem noted at that blog. NSWindowController has special logic to break the retain cycle inherent in binding through File's Owner, which is why you should always use one to own a window NIB (and use NSViewController to own a view NIB).
The documentation for this is nearly lost to time, but there's still one oblique reference. In the old AppKit release notes, where it discusses the then-new NSViewController class, it says:
"• Does the same sort of memory management of top-level objects that NSWindowController does, taking the same care to prevent reference cycles when controls are bound to the nib file's owner that NSWindowController began taking in Mac OS 10.4."
I suspect you have a memory management bug in your own code.
Regards,
Ken
_______________________________________________
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