Re: NSWindowController retain count confusion
Re: NSWindowController retain count confusion
- Subject: Re: NSWindowController retain count confusion
- From: James Walker <email@hidden>
- Date: Fri, 03 Oct 2008 17:22:30 -0700
Uli Kusterer wrote:
On 03.10.2008, at 21:14, James Walker wrote:
Uli Kusterer wrote:
On 30.09.2008, at 21:01, James Walker wrote:
However, I did solve my problem. I neglected to mention that I'm
working in a mostly Carbon app. When I surrounded the alloc, init,
and showWindow calls with a local autorelease pool, the problem went
away and the NSWindowController gets deallocated without funny
business. I thought I had read that it was no longer necessary to
set up my own autorelease pools.
You probably already know that, but just in case:
1) Do not put an autorelease pool at the bottom of your event loop,
i.e. into your 'main' function so it surrounds the event loop run
call. All this will do is inhibit the 'NSAutoReleaseNoPool' error log
messages. Since that all-encompassing pool would take up all objects
where no pool existed, but would never be drained, you'd have the
leaks without the leak warning message.
I see, but no I didn't do that.
Just for the archives: It's OK in general to have an autorelease pool
in the main function, as long as one makes sure it gets drained
occasionally.
2) If you did your creation, destruction and testing in the same
event handler (even if it spawns its own sub-event-loop to e.g. run
the Cocoa window modally), then they'll all be in the same
autorelease pool, so you'll get a false leak. It's perfectly common
to e.g. have another autorelease pool inside a tight loop, to more
frequently autorelease objects that aren't needed after an iteration
anymore. Carbon creates its own pool in RAEL, but that won't be
drained until the next event or could (as a performance optimization)
be drained only every fifth event or so.
There was no sub-event-loop. The dealloc method never got called, no
matter how long I waited.
Any other objects involved that may be retaining your object? NSTimer?
NSThread? NSInvocation? Anything getting retained by an application
delegate? In general, the objects at the top level of the MainMenu.nib
don't get released on shutdown, that throws off many people.
No, I've never used NSTimer, NSThread, or NSInvocation in this project.
There is no MainMenu.nib and no application delegate. The only global
Cocoa objects are a couple of registered value transformers and an
object that watches NSUserDefaults with KVO.
Any of these ring a bell with regard to your project?
Nope, but thanks for trying.
If I'm not misremembering your name, you wrote a very nice piece of
code once that could be used to show help texts and Readmes... I had a
lot of fun with that back when I started out -- consider it an attempt
at payback :-)
Ah, yes, Show_help, in the ancient days before OS X.
--
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