Re: what happens between init and awakeFromNib?
Re: what happens between init and awakeFromNib?
- Subject: Re: what happens between init and awakeFromNib?
- From: Matthew <email@hidden>
- Date: Mon, 20 Dec 2004 07:52:04 -0500
An exception to this is that it probably won't be deallocated at
program termination.
Ok, this is what I was looking for. I was trying to unmount a device in
dealloc, which I was assuming would always be called assuming correct
memory management (which I believe I have), but what you've said makes
a lot of sense. I'll look into a better place to do this, perhaps in
applicationShouldTerminateAfterLastWindowClosed
Matthew
On Dec 20, 2004, at 3:37 AM, Chaz McGarvey wrote:
On Dec 19, 2004, at 10:27 PM, Matthew wrote:
I'm finding that my Controller's dealloc method is not being called
(via log messages) and have noticed that at the very end of init: the
Controller's retain count is 1 (which I'm assuming is correct), but
at the very beginning of awakeFromNib, it's 3, which I don't quite
understand and think is not correct.
What happens in between init: and awakeFromNib that could cause this?
Is it possible that the two retains are actually occurring in init:
but the retainCount isn't being updated until init: formally exits?
I'm getting this info from [self retainCount].
What might be a good approach to track this down? ObjectAlloc and
MallocDebug are there, but I'm not sure that they give the kind of
detail I'm looking for?
As long as you are following all the retain/release (aka memory
management) rules of Cocoa, don't worry about what framework classes
retain your controller. Your controller will be deallocated at the
correct time as long as you follow the rules. An exception to this is
that it probably won't be deallocated at program termination. As an
optimization, Cocoa doesn't waste time deallocating objects if the app
is just going to quit anyway.
Chaz McGarvey
http://www.brokenzipper.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden