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…
/*
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
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
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 a
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
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 a
