FROM : j o a r
DATE : Fri Apr 22 09:22:36 2005
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
DATE : Fri Apr 22 09:22:36 2005
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
| Related mails | Author | Date |
|---|---|---|
| Julien Palmas | Apr 21, 11:05 | |
| Dirk van Oosterbos… | Apr 21, 13:49 | |
| Julien Palmas | Apr 22, 02:26 | |
| Ondra Cada | Apr 22, 03:35 | |
| Julien Palmas | Apr 22, 08:44 | |
| j o a r | Apr 22, 09:22 | |
| Ondra Cada | Apr 22, 12:30 |






Cocoa mail archive

