On Sat, Jun 18, 2011 at 10:09 AM, Kyle Sluder <kyle.slu...@gmail.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
