Re: Release a NSWindowController after the window is closed
Re: Release a NSWindowController after the window is closed
- Subject: Re: Release a NSWindowController after the window is closed
- From: Kyle Sluder <email@hidden>
- Date: Sat, 18 Jun 2011 10:19:48 -0700
On Sat, Jun 18, 2011 at 10:09 AM, Kyle Sluder <email@hidden> wrote:
> It's essentially the same delegate/owner pattern you see all over the
> place in Cocoa, except the window controller doesn't need a weak
> pointer to the app delegate because it cal always get at it by calling
> [NSApp delegate].
Actually, I just realized that it's not quite the same as
delegate/owner, for one important reason: in this scenario, the
"delegate object" (the window controller) is nilling out its own
strong reference from the "owner object" (the app delegate). That
means the window controller is likely to be deallocated right in the
middle of -windowWillClose.
One solution under non-ARC would be to call [self retain] and [self
autorelease] from inside -windowWillClose. We take that approach in a
few places, but it smells worse than your original solution. I also
have no idea how you would mimic that pattern under ARC. "__strong id
holdMe = self"?
Another option would be to delay-perform the release of your window
controller. That feels hackish.
NSDocument certainly needs to handle this scenario somehow. According
to the -[NSDocument addWindowController:] documentation, "To remove a
window controller from the list of active controllers, send it the
NSWindowController message close." That implies that
NSWindowController is in charge of removing itself from the document's
list of window controllers. My instinct is that they do the [self
retain] / [self autorelease] dance.
--Kyle Sluder
_______________________________________________
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