Re: Retains and bindings
Re: Retains and bindings
- Subject: Re: Retains and bindings
- From: Keith Renz <email@hidden>
- Date: Fri, 22 Oct 2004 11:34:52 -0400
I have an NSArrayController in my nib. File's Owner is a subclass of
NSWindowController. I setup and outlet in my window controller for
the NSArrayController. My window controller subclass is also the
window's delegate. I unbind the NSArrayController in the
windowWillClose: delegate method which releases the window controller
and seems to clear up the memory leak.
- (void)windowWillClose:(NSNotification *)notification
{
// NOTE: For some reason, binding contentArry to File's
Owner.document.flights in the nib retains this controller. Closing
the document no longer releases this controller, i.e a leak. If this
binding is removed in the nib, this controller is released as always.
Unbinding here releases this controller and fixes the leak, but I
think it's a bug.
[flightsController unbind:@"contentArray"];
}
I remember seeing this solution posted, though I have a vague
recollection of a follow-up post that suggested this didn't address
every possible case. I'll see if I can find it again at some point.
- Scott
Okay, thanks. If there's a good reason not to do this, I'd like to know.
For a more general, but similar solution, if the window is not set to
release when closed, you wouldn't want to unbind, but you could handle
that case simply enough.
From watching my object deallocations, it appears that everything is
being deallocated correctly. It seems that setting up this binding in
the nib places 1 extra retain on the window controller. I also tried to
release the window controller here to balance the retain count, but
that leaves a bunch of observers registered to a released object and
causes a crash. I also tried autorelease, but that just delayed the
crash slightly -- makes sense. I'm just a beginner with bindings, but
it appears unbind is the way to go, assuming one agrees with this
solution.
Keith
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden