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: Steve Israelson <email@hidden>
- Date: Fri, 6 Jul 2007 14:59:53 -0700
One problem I am having is that the managedObjectContext is a member
variable of the file's owner.
So in my controller object (not the file's owner) I have a member
variable that asks the file's owner for the managedObjectContext.
The problem is that my reference to the file's owner at nib load time
is nil. Thus the whole bindings mechanism falls apart.
This seems like a major design flaw. I am hoping it is not and that
there is some solution I have not figured out yet.
On 6-Jul-07, at 11:38 AM, Steve Israelson wrote:
I still can't seem to get this to work without things crashing or
leaking.
Binding getting removed at some later time that now refer to deleted
objects etc.
I do have one object that programatically binds to another object too.
I looked at the retain counts when I am attempting to close the nib
and dispose of it and they are at 3 or higher.
Is there any more detailed tips on how to dispose of a NIB after it
is loaded when it uses bindings?
On 28-Jun-07, at 10:11 AM, Ricky Sharp wrote:
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
_______________________________________________
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