Re: Problem with bindings and cleaning up a view
Re: Problem with bindings and cleaning up a view
- Subject: Re: Problem with bindings and cleaning up a view
- From: Ricky Sharp <email@hidden>
- Date: Thu, 28 Jun 2007 12:11:20 -0500
On Jun 28, 2007, at 10:53 AM, Steve Israelson wrote:
I have a nib file and controller that has an NSArrayController and
an NSObjectController and a table view and a custom grid view I
have made.
A different controller for my window will instantiate one or more
of these controllers to add its set of views into its window.
This works like spotlight.
My nib + controller class manages one spotlight category, like
"documents" or "images" and the controller for the window creates
as many of these "category" sections as are needed for the search.
This works great until it comes time to dispose of one of these
"category" sections.
I can't just release the controller since that will do nothing
since the window etc all have retained objects from the NIB and the
array controller retains me too. So, instead I have written a
"detach" method that goes through and removes my view from its
superview and releases all the top level items from the nib.
The problem I am getting is when the autorelease pool does its
thing I get a crash in a bindings related call:
"NSKeyValueObservationInfoCreateByRemoving"
So, is there some trick to tearing down your view + controller such
that it actually gets dealloc'd and does not later crash?
In my kiosk-style app framework, I use one nib per "screen". And, in
each nib, I set things up as follows:
The nib owner is my main controller class. Such a controller class
may have IBOutlets and IBActions wired to UI elements in the nib's
window.
_But_, I do not bind anything to that controller whatsoever.
Instead, I create "workspace" objects (models) which I bind to. For
each workspace object, I have a object controller in the nib. Then,
my controller class will contain an IBOutlet for each workspace.
Finally, in my controller's "initialize" routine (not literally +/-
initialize, but instead my "main entry point for loading", I
initialize the workspaces as needed.
This decoupling allowed me to be able to fully release top-level
objects correctly. All bindings are able to be torn down without
issues as well.
So, in short, I believe you'll run into this issue when binding to a
controller such that that controller is nib's owner. Instead, bind
to other objects (kinda a proxy of sorts).
I'm sure there are other solutions, but this was what I came up with
about 3 years ago. You can perhaps look in the archives for topics
on "top level objects" and may find other solutions or the original
threads involving my issue/solution.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden