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
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
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
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
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
