Re: Window controllers and memory leaks
Although the problem in this thread has been solved, a project I'm working needed a systematic way to hang on to transient windows. And subclassing NSWindowController as I suggested last week is costly due to lack of multiple inheritance in Objective-C. So today I wrote a new class which… /* @briefProvides a place for window controllers that control transient windows to "hang out" without being deallocced, so that you don't junk up your app delegate with repeated boilerplate code and instance variables. */ Now any time I want a window controller to simply stick around until its window closes, [SSYWindowHangout hangOutWindowController:windowController] ; A little more code this time. Also comes in a demo project. https://github.com/jerrykrinock/SSYWindowHangoutDemo ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window controllers and memory leaks
Thanks Kyle and Jerry. It feels a bit strange to be adding extra glue code to track otherwise-completely-autonomous windows (and controllers), but that has certainly done the trick. I found the static analyzer a bit odd to get used to - it sometimes gives purportedly very detailed explanations of its logic that actually seem to miss out the key non-obvious step (e.g. obscure code path accidentally returning nil from a constructor). Once I'd got the hang of it, though, it was a great tool. Cheers Jonny. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window controllers and memory leaks
On 2013 Sep 13, at 12:11, Kyle Sluder wrote: > Add a property to your app delegate that retains the window controller. > Have your window controller listen for NSWindowDidCloseNotification from > its window, and send a message to the app delegate. In response to this > message, the app delegate should release the window controller (probably > by assigning its property to nil). That is good, and I've done it that way. But my app delegates get so damned long, so last year I put that boilerplate delegation and notification observing code into a subclass of NSWindowController. In cases where you can live with that (no multiple inheritance), and want to have only one window of a given class (a Preferences window, for example), it "works for me". To add a new "self-releasing" window to your project, 3 steps… • Make the new FooWindowController a subclass of SSYTempWindowController. • In FooWindowController, override +nibName. • To display the window, +[FooWindowController showWindow]. That's all. It loads the nib, shows the window, and all goes away when the user closes it. SSYTempWindowController.m is 62 lines including whitespace… https://github.com/jerrykrinock/ClassesObjC/blob/master/SSYTempWindowController.m ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window controllers and memory leaks
On 13 Sep 2013, at 17:12, Jonathan Taylor wrote: > > > However the static analyzer complains that there is a "potential leak" of > myWindowController, because it recognises that it has a retain count of 2 > when it returns from the init method. (The same applies if I don't retain in > init and don't release in TestWindowController). > > It strikes me that this would be quite a common pattern. I appreciate that > the static analyzer doesn't *know* whether there's a leak or not, but if I am > indeed correctly following a common pattern then I would have expected the > analyzer to understand what is going on. > > My question then is whether I am doing things in an unconventional way here, > and/or whether there is something I could change that would help the analyzer > understand what is going on. It's complaining because init is not a "special" (alloc, copy, new, magic method), normally the pattern I would use is to put it into a property and then release it at dealloc time. That way the property is holding a reference to the object and then analyser won't complain! Cheers Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Window controllers and memory leaks
On Fri, Sep 13, 2013, at 09:12 AM, Jonathan Taylor wrote: > I want to allocate a window + controller, and I want it to live until the > user closes the GUI window, at which point I want it to disappear and > clean up after itself. I believe that the following code does not leak > memory and behaves as intended. Don't do this. Experience has taught us that apps are more stable when developers don't make exceptions to the standard memory management rules. Add a property to your app delegate that retains the window controller. Have your window controller listen for NSWindowDidCloseNotification from its window, and send a message to the app delegate. In response to this message, the app delegate should release the window controller (probably by assigning its property to nil). --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Window controllers and memory leaks
This must be an incredibly basic question, but I haven't found an answer I'm
convinced by (apologies if I have missed something on the list). My question
relates to window controllers, and how ownership, retain/release etc should be
managed in order to (a) be correct and (b) satisfy the static analyzer. This
has come up because it's only now that I have migrated my codebase to be
compatible with the latest version of xcode that I have been able to run the
static analyzer over it and examine the results.
I want to allocate a window + controller, and I want it to live until the user
closes the GUI window, at which point I want it to disappear and clean up after
itself. I believe that the following code does not leak memory and behaves as
intended.
@interface MyWindowController : NSWindowController
{
}
@end
@implementation MyWindowController
-(id)init
{
if (!(self = [self initWithWindowNibName:@"MyNib"]))
return nil;
// Window will release self when closed, so we need to retain
an extra time here
[self retain];
return self;
}
-(void)dealloc
{
printf("Deallocated\n");
[super dealloc];
}
-(void)windowWillClose:(NSNotification*)note
{
[self autorelease];
}
@end
void TestWindowController(void)
{
MyWindowController *myWindowController = [[MyWindowController alloc]
init];
[myWindowController.window makeKeyAndOrderFront:nil];
// We own a reference to myWindow since we allocated it,
// but we have now finished all the setup we want to do
// and are relinquishing control of the window object,
// releasing it into the big wide world to live or die
// as it may.
[myWindowController release];
}
However the static analyzer complains that there is a "potential leak" of
myWindowController, because it recognises that it has a retain count of 2 when
it returns from the init method. (The same applies if I don't retain in init
and don't release in TestWindowController).
It strikes me that this would be quite a common pattern. I appreciate that the
static analyzer doesn't *know* whether there's a leak or not, but if I am
indeed correctly following a common pattern then I would have expected the
analyzer to understand what is going on.
My question then is whether I am doing things in an unconventional way here,
and/or whether there is something I could change that would help the analyzer
understand what is going on.
Many thanks
Jonny.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
