On Thu, 22 Jun 2006 18:35:34 -0700, "D.K. Johnston" <email@hidden>
said:
I have a controller class that is instantiated and released by my
programme many times during a run. When initialising, the controller
object loads a nib file with the loadNibNamed: method, in order to
use a window contained therein. In IB, I set the window to be
released when closed.
What I'd like to know is: What happens to the nib file when one of
these controller objects is released? Does it remain in memory? Is
another copy loaded every time the class is instantiated? I can't
seem to find the answer to this question anywhere in the
documentation.
But this is why god gave you the performance tools, such as
ObjectAlloc, to
find out, so why aren't you using them?
However, here's a quick answer:
* Releasing a window controller releases the nib that it owns; that
is part
of the window controller's job. So, no, it doesn't remain in memory.
This is well documented. For example:
<http://developer.apple.com/documentation/Cocoa/Reference/
ApplicationKit/Cla
sses/NSWindowController_Class/Reference/Reference.html>
It says right at the top: "The window controller is responsible for
freeing
all top-level objects in the nib file it loads".
<http://developer.apple.com/documentation/Cocoa/Conceptual/WinPanel/
Concepts
/UsingWindowController.html>
Also useful:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
Documents/Tasks/F
AQ.html>
(Incidentally, notice that it doesn't say "releases the nib", as I
did,
because what I'm saying is a very loose way of putting it. The nib
*file*
was never really in memory in the first place, except accidentally
as part
of virtual memory. The nib file is just a kind of template on disk
containing instructions for forming some objects. To load a nib
file is to
read those instructions and obey them to form those objects.
**Those** are
the objects that are released when the window controller is
released, and
that's all you care about.)
* Yes, another copy of the nib is loaded every time the window
controller is
instantiated; that is one of the main purposes of having a window
controller
and a nib (since otherwise how would you open two copies of a window
simultaneously, as in any doc-based app?).
Note that your decision to release when closed may be a red
herring. It is
not necessary in order to cause the nib (and the window) to be
released when
the window controller is released.
Finally, you might like to rethink your impulse to release the window
controller at all. It's fine, and I do this with certain kinds of
window,
e.g. something that I think the user will probably summon either
zero or one
times through the life of the app. But if, as you say, the thing is
going to
be instantiated "many times during a run", then why release it? Why
not keep
it on hand as a singleton, so that all you have to do, once you've
instantiated it (the first time the user asks to see the window) is
keep
hiding and showing the window?
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
