• 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:05:41 -0700

Negm-Awad Amin wrote:

Am Di,07.10.2008 um 04:56 schrieb James Walker:

[…]
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.
I'd suggest it would be more fruitful to chase down the actual bug rather than one that appears to be related but might be just a red herring.
If a view is being asked to draw but its window has gone away, then something's very, very off somewhere. Normally views are drawn by their windows, so how can such a situation arise? If you can answer that question you've probably found the problem. Is some other object retaining the view? Why? Are you drawing outside the usual update event cycle mechanism? Why?

When I said "the window has gone away", I spoke imprecisely. I meant the window had been closed. But, as I said, it had not been deallocated.
To clarify:
The window is closed (still allocated) and you get a draw request?

More precisely, the window's delegate had received the windowWillClose: notification and later there is a draw request.


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.

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

  • Prev by Date: Re: Parsing integers from strings
  • Next by Date: Re: Appropriate use of bindings?
  • Previous by thread: Re: NSWindowController retain counts, chapter 2
  • Next by thread: Re: NSWindowController retain counts, chapter 2
  • Index(es):
    • Date
    • Thread