Fw-Up: views removed from their superviews are automatically released?
Fw-Up: views removed from their superviews are automatically released?
- Subject: Fw-Up: views removed from their superviews are automatically released?
- From: Andrea Perego <email@hidden>
- Date: Wed, 20 Mar 2002 17:29:53 +0100
Lance Bland was able to answer my question about automatic release
of a view by [nwView removeFromSuperview] (thanks!)
The view is deallocated on the run loop because it has to mix with
notifications and other things. To test that just place a NSLog() inside
the view's dealloc method. It will be called later on. Of course, I
didn't design that feature and I am just surmising why it is happening
the way it does.
As a final remark, I'd wish to note that the delayed release
mechanism is smart enough to take into account the possibility that
the view might have been already deallocated in the meanwhile;
otherwise my app would have crashed during the tests I did. This is
just an example of decent behavior by a Cocoa class, but for me it's
also a reminder of the importance of defensive programming...;->
Andrea Perego
Univ. of Florence - Phys. Dept.
My original message:
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.
........
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].
........
_______________________________________________
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.