Re: Nib top-level object ownership?
Re: Nib top-level object ownership?
- Subject: Re: Nib top-level object ownership?
- From: Camillo Lugaresi <email@hidden>
- Date: Sat, 31 Dec 2005 13:34:20 +0100
On 31/dic/05, at 05:32, Ricky Sharp wrote:
On Dec 30, 2005, at 10:14 PM, Jim Correia wrote:
Back before NSNib, if you instantiated a nib and were not an
NSWindowController subclass, you were responsible for making sure
that all the top level objects were sent a release message.
Now that we have NSNib, if I use
-instantiateNibWithOwner:topLevelObjects:
to instantiate a nib, am I responsible for sending a release
message to each object in the returned topLevelObjects array when
I am done with the nib? It would appear so, since I have leaks
without i, but the documentation doesn't explicitly state one way
or the other, at least in the places I've looked :-)
Yes, you're responsible for releasing those objects.
I started a couple threads[1] about this within the past few
weeks. I was revamping my app due to leaks and I started out by
trying instantiateNibWithOwner:topLevelObjects:. I couldn't really
get that to work due to circular dependencies, so I ended up
subclassing NSWindowController. The e-mails I wrote point out
other gotchas.
I took a different approach: my controller acts as a delegate for the
main window in the nib, and releases the top-level objects when it
gets a windowWillClose: message for that window. Of course, if a
super-controller wants to destroy that controller directly, it needs
to tell it to close the window first. Otherwise, it can just release
the controller, and it will survive on its own until the window is
closed.
Another solution could be this:
- get your retain count before and after loading the nib, and save
the difference in an ivar;
- override release: when your retain count drops to the saved
difference (ie only the objects in the nib are retaining you),
release the top-level objects.
I haven't tried it, though.
Camillo
_______________________________________________
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