Re: NSView subclass never gets dealloced?
Re: NSView subclass never gets dealloced?
- Subject: Re: NSView subclass never gets dealloced?
- From: Brock Brandenberg <email@hidden>
- Date: Fri, 29 Mar 2002 17:56:07 -0600
Hi Erik.
Thanks for the info.
1) NSWindowController releases top level objects in associates nibs.
If you
are not using NSWindowController then you must release them yourself.
I'm assuming that "not using NSWindowController" means not using a
subclass? A default controller is created for you if you have a one
window nib file, correct?
2) Normal reference counted memory management applies. If you retain a
view
and do not correspondingly release it, YOU have created a memory leak
and it
is not the frameworks fault.
Sure. I definitely release any subviews that I create programmatically.
I alloc and init, addSubview then release, letting the superview retain
it. It's then up to Cocoa to release subviews when the superview goes
away, right?
3) The IB option to release on close exists to support the situation in
which NSWindowController is not used. Using that option in combination
with
NSWindowController probably produces too many releases.
For Jonathan Wight's initial question, if you create a new Cocoa app
project, add a custom view to the window, create an NSView subclass, set
the custom view to that subclass, then add the following code to the
subclass implementation, the dealloc never gets called.
@implementation MyView
-(id)initWithFrame:(NSRect)aRect
{
NSLog(@"initWithFrame:");
self = [super initWithFrame:aRect];
if(self)
{
// blah, blah, blah
}
return self;
}
-(void)dealloc
{
NSLog(@"dealloc:");
[super dealloc];
}
@end
You have to check the "Release when closed" button in IB for it to be
properly dealloc'ed. I think my problem with the app crashing with this
option checked is that I have a couple of floating windows and one main
window, and the default window controller appears to only support one
window. The presence of more than one window appears to be what caused
the crash I saw. Our app is in no way finished so I'm not intent on
leaving it this way, but that's the state it's currently in. I'll start
on a NSWindowController subclass to do it right.
And is this list moderated by anyone from Apple? The lack of sample
code
for Cocoa is pathetic, as is the lack of examples of proper application
of the APIs? Whose working on these docs?
There are copious examples available. If you are not finding them then
something is wrong with the way you are looking. Keep in mind that
generic
UNIX API use is not restricted to Apple examples. Look in the millions
of
lines of code out there. We can always use more examples and more
documentation. Your specific problem is well understood and solved by
many
examples.
I would think so too, but it's usually these seemingly obvious little
things that get left out that make learning difficult for newcomers to
the frameworks. Unlike procedural code, much is hidden in the
frameworks, so it's important that the behavior of this hidden code is
clearly demonstrated. And it's disconcerting to find statements in the
docs like:
- (BOOL)isReleasedWhenClosed:
...The default for NSWindow is YES; the default for NSPanel is NO.
This is contradictory to the default settings in IB, so should you
change the IB setting or not? Under what conditions is this valid? A
window created programmatically versus from a nib file? There should be
an additional sentence that clarifies behavior with the default window
controller and IB. Please note that I'm not ranting at you - I'm just
illustrating why the docs and samples are frustrating to me.
It's sometimes difficult finding good sample code, too. A lot of it I
wouldn't touch with a ten foot pole, and the really good stuff usually
doesn't have UI stuff wrapped around it. It's a collection of libraries
for tree manipulation or graphics manipulations that is UI independent.
So finding appropriate UI examples can be tough.
I've grown up doing Toolbox development with the original InsideMac
series which is wonderful. The later docs are not as good as the
original series, but they're not bad. However, the Cocoa docs are still
lacking examples. It's odd that O'Reilly does a starter book on
development, but Apple doesn't have their own, even with 13+ years of
Next history. It doesn't take long to outgrow the O'Reilly book either,
so now I'm looking for those examples of extracting glyph outlines from
fonts, getting PDF information from files into a graphics context as
vectors rather than an imaged pixmap, and ways to save PDF data to a
file using Cocoa rather than the Adobe library or a gnu library. Which
reminds me, it's funny looking thru the GNUStep docs. They're incomplete
too and seem to be just copies of the Apple docsright down to the
duplicate "description forthcoming" comments.
Thanks for the help and tips,
Brock Brandenberg
----- industrial design @ bergdesign.com ------
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.