RE: views removed from their superviews are automatically released?
RE: views removed from their superviews are automatically released?
- Subject: RE: views removed from their superviews are automatically released?
- From: "Bob Newhart" <email@hidden>
- Date: Wed, 20 Mar 2002 06:07:54 -0700
Well, this may be a silly question, but is your view actually embedded
in a superview?
Jason
>
-----Original Message-----
>
From: email@hidden
>
[mailto:email@hidden] On Behalf Of Andrea Perego
>
Sent: Wednesday, March 20, 2002 3:45 AM
>
To: email@hidden
>
Subject: views removed from their superviews are
>
automatically released?
>
>
>
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/co> coa-dev
>
Do not
>
post admin requests to the list. They will be ignored.
_______________________________________________
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.