• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSWindowController retain counts, chapter 2
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSWindowController retain counts, chapter 2


  • Subject: Re: NSWindowController retain counts, chapter 2
  • From: James Walker <email@hidden>
  • Date: Tue, 07 Oct 2008 11:42:04 -0700

Shawn Erickson wrote:
On Tue, Oct 7, 2008 at 11:05 AM, James Walker <email@hidden> 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

No, there is no such message.

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.

No, I don't have such a top-level autorelease pool, and I don't know why anyone would.


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

I know.

(of course I do wonder why you are still using Carbon event
management, it really is time to be switching off of that)

Because I still have a bunch of PowerPlant windows, and changing the event management seemed riskier than not doing so.


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


  • Follow-Ups:
    • Re: NSWindowController retain counts, chapter 2
      • From: "Shawn Erickson" <email@hidden>
References: 
 >NSWindowController retain counts, chapter 2 (From: James Walker <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: Graham Cox <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: James Walker <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: Graham Cox <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: James Walker <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: Negm-Awad Amin <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: James Walker <email@hidden>)
 >Re: NSWindowController retain counts, chapter 2 (From: "Shawn Erickson" <email@hidden>)

  • Prev by Date: Re: Appropriate use of bindings?
  • Next by Date: Next Key View doesn't "go to" pushbutton
  • Previous by thread: Re: NSWindowController retain counts, chapter 2
  • Next by thread: Re: NSWindowController retain counts, chapter 2
  • Index(es):
    • Date
    • Thread