Re: Retain cycle problem with bindings & NSWindowController
Re: Retain cycle problem with bindings & NSWindowController
- Subject: Re: Retain cycle problem with bindings & NSWindowController
- From: "Dennis C. De Mars" <email@hidden>
- Date: Tue, 8 Jun 2004 02:06:35 -0700
On Jun 7, 2004, at 10:29 AM, Allan Odgaard wrote:
On 7. Jun 2004, at 9:33, Dennis C. De Mars wrote:
My question is: is it possible to use bindings when the nib "File's
Owner" is an NSWindowController subclass.
I have this problem as well (and did mention it a few times on this
list w/o responses ;) ).
The documentation for addObserver:forKeyPath:options:context: says
that "Neither the receiver or anObserver are retained", so it should
not happen solely by having the view observe the controller/model.
But the documentation for bind:toObject:withKeyPath:options: does not
make such a guarantee, and surely, it is only some bindings which
cause a retain cycle.
I don't see any way to specify the path to the model property for a
binding except through the File's Owner, so it looks like the File's
Owner can't be the window controller. But that can't be right.
I hope you'll report it as a bug -- I haven't come around to doing
that myself yet, so many bugs, so little time, and so little incentive
to do so ;)
OK, I think I'll do that. I just wanted to check that I wasn't
forgetting anything obvious.
I will have to investigate further as to which bindings cause this. I
have found you don't even need a binding per se to have this problem. I
tried instantiating an NSObjectController in my nib file to access the
model indirectly, under the theory that the binding would retain the
NSObjectController and not the File's Owner, but no such luck. Even if
you don't have any bindings, just connecting the NSObjectController's
content outlet to the File's Owner will retain it. Drat!
However, the available examples I've found so far use an NSDocument
subclass as the File's Owner [...]
Unfortunately that won't solve anything.
Document retains window controller,
window controller retains top level nib objects,
top level nib objects retain children,
children retain document (because of bindings),
-> and there's your cycle again!
Well, yes and no. You definitely have a retain cycle there, as I
realized after I made my last post. But, this only causes a memory leak
if each object only releases the object it retains in its dealloc
method. But if one of the objects can release its retained object under
other circumstances, it can break the cycle.
For instance, the document object can know when the window controller's
widow is closed. It can then release the window controller and that can
propagate down the chain until the document itself gets released (at
which point the document has to make sure that it doesn't send a
release to the window controller that it already released).
I am not privy to the internal workings of NSDocument but it seems
quite possible something like this is going on, so I tried a little
experiment. I made a fresh project with a document and put one text
field in the window with a binding to a variable I put in MyDoucment.
After building, I ran the application under ObjectAlloc. After closing
the window, the MyDocument object was deallocated.
Then I created a second project and defined an NSWindowController
subclass. I created an identical text field, but the binding had a
model path like: document.testField.
In this case, the NSWindowController object did not get deallocated
after the window was closed, as observed by ObjectAlloc.
So, even in this simplest of examples the NSWindowController object is
caught in a deadly embrace with the view object binding to it, which
the NSDocument seems to be able to break.
- Dennis D.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.