Re: Memory management with nibs
Re: Memory management with nibs
- Subject: Re: Memory management with nibs
- From: j o a r <email@hidden>
- Date: Fri, 22 Apr 2005 09:22:36 +0200
On 2005-04-22, at 08.44, Julien Palmas wrote:
The nib handling abilities of a NSWindowController are pretty
attractive and I would like to use a sub-class of it. Still, I only
need one window per document and each different nib, like I said
before, would only be there to provide other views.
Would it be bad to add a window inside each nib, just in order to use
a sub-class of NSWindowController as its owner ? even if I completely
don't care about this window ?
It seems to me that you think too much about this. What is the problem?
If you load a nib file, you need to release all top level objects in
the nib file (unless the files owner is a subclass of a class that
provides that functionality automagically, like NSWindowController).
It's dead simple. Just do it in your nib loading classes.
@interface MyNibLoader : NSObject
{
@private
IBOutlet NSView *myView; // Top level item in nib file
IBOutlet NSView *mySubview;
}
@end
@implementation MyNibLoader
- (void) dealloc
{
[myView release]; // Top level item in nib file
[super dealloc];
}
@end
You will have to learn how to release the other instance variables of
your objects anyway, so what's the big difference with learning to
remember to release the appropriate IBOutlets?
I don't think you should use a NSWindowController subclass in this
case, as it's designed with something else in mind. And it would
definitively be both bad, and completely unnecessary, to add a dummy
window to the nib file if you do choose this path.
Perhaps Apple should add a NSNibController class, that you could use as
the superclass of objects that loads a single nib file? The only
functionality this class would need to provide is the automatic
deallocation of top level nib objects, much as NSWindowController does.
Would be kind of neat.
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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