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 k...@ksluder.com 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 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
Re: Window controllers and memory leaks
On 13 Sep 2013, at 17:12, Jonathan Taylor jonathan.tay...@glasgow.ac.uk 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
