views removed from their superviews are automatically released?
views removed from their superviews are automatically released?
- Subject: views removed from their superviews are automatically released?
- From: Andrea Perego <email@hidden>
- Date: Wed, 20 Mar 2002 11:45:24 +0100
Hi!
NSView's documentation about "removeFromSuperview" reads:
removeFromSuperview
- (void)removeFromSuperview
Unlinks the receiver from its superview and its NSWindow, removes it
from the responder chain, and invalidates its cursor rectangles. The
receiver is also released; if you plan to reuse it, be sure to
retain it before sending this message and to release it as
appropriate when adding it as a subview of another NSView.
which implies that the removed view is released. A quick search in
the archives of this list revealed nothing against this assumption.
Nevertheless, while
experimenting on a project of mine, I found a situation where this
release seems not to happen. To be sure, I bracketed my call with
"NSLog":
NSLog(@"before removing from superv. retcount for
view=%d",[paramOptionsView retainCount]);
[paramOptionsView removeFromSuperview];
NSLog(@"after removing from superv. retcount for
view=%d",[paramOptionsView retainCount]);
and the corresponding output is:
2002-03-20 10:24:51.149 testspectra1[528] before removing from
superv. retcount for view=1
2002-03-20 10:24:51.149 testspectra1[528] after removing from
superv. retcount for view=1
and the retain count isn't changed. Maybe there is something obvious
I'm missing here; anyway, to provide some more info to anyone that
might get intrigued by this puzzle:
- my app is not multithreaded (jet!)
- the view has been loaded from a nib file whose owner is the same
class instance that issues the remove afterwards
- the aforementioned class is part of a code plug-in that has been
dynamically loaded (I don't see how this fact might affect the case,
but...)
I have considered the possibility that the actual release associated
with "removeFromSuperview" might be somehow delayed (e.g.,
autorelease), so that my check would be fooled, but I rejected this
guess, since a [paramOptionsView release] issued in my code
immediately after the quoted lines works fine and does not indirectly
cause any crash, as it would be the case if a delayed release
associated with "removeFromSuperview" were issued afterwards. I went
further and tried a second release in my code, verifying that *this*
caused a crash [this way of testing isn't elegant, but sometimes I
resort to it as a Q&D check that a previous release has actually
deallocated an object].
I'd appreciate any enlightening comment on the subject.
TIA
Andrea Perego
Univ. of Florence - Phys. Dept.
_______________________________________________
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.