Re: Proper Way to "Unload" a Loaded Nib w/Bindings
Re: Proper Way to "Unload" a Loaded Nib w/Bindings
- Subject: Re: Proper Way to "Unload" a Loaded Nib w/Bindings
- From: James Bucanek <email@hidden>
- Date: Tue, 27 Mar 2007 13:00:51 -0700
Keary Suska wrote on Tuesday, March 27, 2007:
>on 3/27/07 12:51 PM, email@hidden purportedly said:
>
>>> If you know what your top-level objects are, send one release to each when
>>> you're done with the nib. (Remember that if you have release-on-close set for
>>> the window, the NSWindow will release itself.)
>>>
>>>> Is there sample code for dynamically "unloading" a nib, especially without
>>>> needing to know precisely what outlets are connected and what bindings
>>>> exist. Basically what NSWindowController seems to do.
>>>
>>> If you have an arbitrary or unknown set of top-level objects, do what
>>> NSWindowController does: Use loadNibFile:externalNameTable:withZone:
>>
>> Personally I would look at using NSNib and the functionality it
>> provides to load and instantiate nibs, in particular
>> instantiateNibWithOwner:topLevelObjects:. It is simpler to use. Note
>> NSNib is a 10.3 and later API.
>
>I am using the NSBundle method, modeled after the docs:
>
> [[NSBundle mainBundle] loadNibFile:name externalNameTable:nameTable
>withZone:nil]
>
>The problem is that when I release the top level objects, my app crashes. My
>research seems to show that this is because of an NSWindow's
>initialFirstResponder outlet being set.
My guess is that you are either overreleasing an object, or you have a weak reference an object that has already been released.
Some objects keep so-called "weak" references to other object. That is, the reference is not retained. The danger here is trying to use that object after it has been released. Delegates are notorious for having this problems, as delegates are typically not retained.
But this isn't a nib problem. This is standard Cocoa memory management and you'd have the same problem wether the objects were created from a nib or programmatically.
NSZombie and ObjectAlloc are your friends.
>The docs warn that all outlets
>should be set to nil for all objects in the nib, but don't mention how this
>may be done when the outlets aren't known by the nib owner.
Again, this is responsibility of the individual objects, not really the nib's owner. A window that is being released should not be using its initial first responder. If it is, something's wrong -- but this should have nothing to do with the fact the objects were created by a nib.
>Manually
>tracking outlets would be a huge pain, so I was hoping there was some way to
>detect connected outlets in a nib and "disconnect" them.
Again, it's the responsibility of the objects not to use other released objects. Setting all of the object's outlets to nil before releasing anything would probably accomplish this, but that isn't the solution.
>NSWindowController
>seems to accomplish this
NSWindowController knows nothing about connections. It simply releases the top-level objects per the NIB loading guidelines. The objects with connections are responsible for those connections.
>I am also not sure whether bindings will gracefully "let go", or if I need
>to unbind as well to avoid crashes.
I think regular bindings should take care of themselves, but be careful of any observers that you've manually connected. Neither the observer or observee are retained. I typically disconnect my observers in the dealloc method.
--
James Bucanek
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden