Re: NSWindowController retain counts, chapter 2
Re: NSWindowController retain counts, chapter 2
- Subject: Re: NSWindowController retain counts, chapter 2
- From: Negm-Awad Amin <email@hidden>
- Date: Tue, 7 Oct 2008 10:02:43 +0200
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?
[…]
Cheers,
Amin Negm-Awad
email@hidden
_______________________________________________
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