Re: NSWindowController retain counts, chapter 2
Re: NSWindowController retain counts, chapter 2
- Subject: Re: NSWindowController retain counts, chapter 2
- From: James Walker <email@hidden>
- Date: Mon, 06 Oct 2008 17:38:27 -0700
Graham Cox wrote:
On 7 Oct 2008, at 9:57 am, James Walker wrote:
After fixing things so that my NSWindowController subclass gets
deallocated, I discovered that the NSWindow was not getting
deallocated. It appears to be related to the fact that the NSWindow's
retain count is incremented each time -[NSWindowController window] is
called. I don't see anything in the documentation of the window method
that would have led me to expect that behavior. Is there some general
principle I should know about?
For now, I've worked around the problem by overriding the window
method as follows, where mWindow is a member variable:
- (NSWindow *)window
{
if (mWindow == nil)
{
mWindow = [super window];
}
return mWindow;
}
This seems a wee bit crazy.
NSWindowController has a perfectly good member variable called 'window'
that supplies the window in question, and is returned by the -window
method (provided you remembered to hook it up in IB of course).
NSWindowController.h does not say that it has a member variable named
window, it says that there is a private member variable named _window.
The fact (if it is a fact) that the retain count of the window is
incremented is not something you should be looking at or caring about.
Retain counts are none of your business, and incrementing one doesn't
imply anything. Maybe for example the [NSWindowController window] method
does this:
return [[window retain] autorelease];
There's nothing wrong with that, there's no leak, yet you'd see the
retain count incremented if you were poking your nose into it. It's not
mentioned in the documentation because it's perfectly in keeping with
normal rules of ownership so doesn't need calling out as an exception to
those rules.
Hmm, OK...
In the earlier part of this thread, which I didn't contribute to yet
read with interest, you were repeatedly told to stop worrying about
retain counts and just follow the rules. I'll weigh in and add my voice
to that clamouring chorus.
I can accept that looking at retain counts may just be confusing me, but
"just following the rules" hasn't sufficed.
How do you know the window isn't being deallocated? Examining retain
counts is not going to tell you whether it is or not. The only way would
be to subclass it and log the -dealloc method.
That's exactly what I did. The dealloc method was not getting called
before I added the workaround. Well, the initial symptom was that I got
an access violation because a custom view was asked to draw after the
window had been closed and the window controller had been destroyed. In
the course of debugging that, I subclassed the window.
--
James W. Walker, Innoventive Software LLC
<http://www.frameforge3d.com/>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden