There's an HTML glitch in the link to "simplest solution"....

http://www.cocoabuilder.com/archive/message/2004/7/28/113081

Fixed, thanks.

I think the retain cycle problem is possible anywhere you bind to File's Owner and File's Owner properly retains its nib objects. Also, it doesn't manifest itself always (just tried to reproduce from scratch, no problem). Most importantly, I think you need a step 4 - use [objectControllerr setContent: nil] in a suitable method. For instance [NSDocument close].

Steven Kramer is quite correct. I modified Crawford's Manual Bindings example to a document-based app and it leaked like the dickens until I simply stuck in a line to set the content of the array controller to nil when the document window is closed.

Hi,
Thanks for the articles about CoreData, just printed them and will have some night reading to do tonight...

I was wondering if you have some tutorials on NSController and NSArrayController

I read some stuff at apple and even play with them but i think i am missing the deep down idea on how to use them.

Thanks
Ricardo

Hoops Sorry wrong thread

As of Mac OS X 10.4.3, NSDocument and NSWindowController seem to have this *almost* fixed. An undocumented class named NSAutounbinder seems to automagically perform an unbind for these two classes -- fixing the reference counted loop for Nib bindings.

This doesn't always work (quitting an application with a document window open that has no unsaved changes results in the document not getting unbound -- work around is to closeAllDocumentsWithDelegate manually on applicationShouldTerminate) and still doesn't fix the problem when the owner is neither an NSDocument nor NSWindowController.

In these "doesn't always work" situations, the NSObjectController fix described above still works.

Just so you know.

This is nice, but if you want to proxy the original file's owner in this way you'll need to go a little further.

In your NSWindowController subclass override awakeFromNib: and release with something that looks like this:

- (void) awakeFromNib;
{
// filesOwnerProxy == NSObjectController in the nib
[filesOwnerProxy setContent:self];
}

- (oneway void) release;
{
// special case when count is 3, we are being retained twice by the object controller...
if ( [self retainCount] == 3 )
{
[super release];
[filesOwnerProxy setContent:nil];
return;
}

[super release];
}

When you setContent: in the NSObjectController you get two extra retains in the new contentObject. This is a nice solution since you can be sure that the extra two retains will be from your objectController, and you can safely bind as much as you like to that controller. The only issue will be if apple changes their NSObjectController etc code.

I was just bitten by this "bug" and spent some time implementing the above suggestions with success. However, this seems like a real kludge to me.

Does anyone know how Leopard and garbage collection will affect this?

Does anyone know how Leopard and garbage collection will affect this
Garbage collection should make it a moot point.

If anyone is still reading this, be aware that this issue is still present in Leopard. I know of at least two reproducable cases where it occurs:

1. Binding to the File's Owner with key path "self" (this occurs when you use an NSObjectController 'proxy' for the File's Owner, e.g. to have a funnel point for NSEditor/NSEditorRegistration, as is recommended by many reputable people and the docs).

2. Binding an NSArrayController's contentArray to a to-many property of the File's Owner for which only indexed KVC accessors are implemented (i.e., not -<key> and -set<Key>:). Note that this is actually recommended practice (at least according to some people).