On Tue, Oct 7, 2008 at 11:05 AM, James Walker <[EMAIL PROTECTED]> wrote:
> I think the important thing is that the window was not getting deallocated. > After more experimentation, this seems to be another symptom of the same > basic problem as in my previous NSWindowController thread, which is that a > Carbon app using WaitNextEvent still needs to set up and release its own > autorelease pools each time through the event loop. When I do that, the > problem goes away. And unlike my previous workarounds, this doesn't make me > feel like I'm doing voodoo. Have you looked at the console log or run log if running from Xcode for messages like the following? *** _NSAutoreleaseNoPool(): Object <SomeObjectPointer> of class <SomeClassName> autoreleased with no pool in place - just leaking Of course you may not be seeing those if you have a top level auto-release pool setup, say in your main entry point, that simply exists for the life of the application. If you do have such a top level auto-release pool that exists for the life of the application consider knocking it out (at least temporarily) to help you detect code pathways that are using Cocoa API yet they are not correctly managing an auto-release pool. Note the event loop in a NSApplication based application with do such management for you, at least on the main thread (aka which is running the even loop, aka main runloop). (of course I do wonder why you are still using Carbon event management, it really is time to be switching off of that) -Shawn _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
