On Feb 24, 2008, at 7:22 PM, Jack Repenning wrote:
On Feb 23, 2008, at 6:44 PM, Hamish Allan wrote:
On Sun, Feb 24, 2008 at 2:25 AM, Jack Repenning <[EMAIL PROTECTED]
> wrote:
In my -(id)initWithContext:, I [NSBundle loadNibNamed:@"SCCommitUI"
owner:self]. Among other things, this retains me a few times inside
the bundle. When I'm done, I want "self" to go away, but it does
not:
the retain count never goest to zero (my dealloc is never called),
because of those retains inside the bundle. How do I make the
bundle / nib let me go?
A similar question came up recently on the list, and the short answer
is: if the bundle wants to retain you, let it do so; if you want the
resources you release in your dealloc method gone sooner, create an
API for that (c.f. [NSFileHandle closeFile]).
I must not be fully understanding this solution, and I can't seem to
locate the thread. Can you hint me some keywords, or an URL or
something?
I understand the part about providing a closeMe method, to do all
the releasing new done in my unused -dealloc. But there's the "me"
itself to release or leak, and there see still to be references to
it that seem still to be used in some way or other (to judge from my
BADACCESS crashes if I over-release myself). And I do want to
create new instances of "me", bound once again to the same nib (or
an identical one), to post the window yet again. Are you saying I
should just let that stuff leak?
It sounds like you want to be able to release all top-level objects.
I do this myself since I also load/unload the same nibs throughout the
lifetime of my app.
Things can get a bit tricky, so definitely hunt down the various
threads on it. For example, you may not be able to bind items to your
nib's owner (controller). I got around this by:
(1) Controller is owner of the nib; contains outlets/actions as
needed. One outlet is to a 'workspace' object.
(2) An instance of the workspace object is added to the nib and
connect to the controller. An object controller is also added to the
nib which controls the workspace object. I then bind whatever I need
in my views to that workspace controller.
Note though that this is just one solution. You can always change
things around to not rely upon dealloc to do some of your cleanup.
This especially becomes useful if you eventually want to migrate your
code to use GC.
In my codebase, I've done a compromise. I do most of my teardown
stuff involving views in viewDidMoveToWindow when the given window
param is nil. My dealloc code just releases memory (as expected) and
additionally unbinds any custom bindings and invalidate timers.
___________________________________________________________
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
