• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Re: How to get rid of an NSWindowController? Or: Who is retaining my window controllers?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: How to get rid of an NSWindowController? Or: Who is retaining my window controllers?


  • Subject: Re: Re: How to get rid of an NSWindowController? Or: Who is retaining my window controllers?
  • From: Christian Gottschall <email@hidden>
  • Date: Tue, 5 Oct 2004 01:08:52 +0200

Hi,

first of all: thank you very much! Your description clarified matters for me, and I was able to work around the problem fairly fast.

IMO, this is a huge bug with Cocoa bindings, which "should" use 100%
non-retained observation, but it doesn't.

Now that I understand the foundation of this problem, of course I would prefer this to be the case. Nevertheless, the biggest problem is the lack of appropriate documentation: As big a caveat as this is, it should be pointed out very clearly in the documentation. What surprises me a bit is that I did not even find much information in the Internet - could it be that users of bindings are not fully aware of their application(s) leaking storage?

Overall, I think Cocoa bindings are good, but
definitely not perfect, and not suitable for all types of applications.

I would like them very much if there was a little bit more documentation around, and, of course, if there was an easier way to address this particular problem.

The workaround is not to bind anything to/thru the NSWindowController.

Since my application was not far from completion, I was a bit afraid of redesigning things. So what I tried is find as easy a way as possible to programmatically unbind the "bad" bindings. I don't know if this may be considered good design, or even if I still overlooked something, but what I did was the following:

In my document class, MyDocument, I overloaded removeWindowController as follows:

- (void) removeWindowController: (NSWindowController *) windowController {
id obj = windowController;
if ( windowController && [obj respondsToSelector: @selector(unbindBadBindings)] )
[obj unbindBadBindings];
[super removeWindowController: windowController];
}

Now, every window controller to or through which I did bind things has to have an unbindBadBindings function. It also has to have an outlet to each respective binding. I am not particularly happy with this, but it turned out to be less impractical than I would have expected: In most of my NIB files, there are only one or two bindings to or through the window controller.

Of course my first idea was to have the unbindBadBindings function automatically find the respective bindings. Unfortunately, my knowledge of the inner workings of Cocoa is much too little advanced for doing such a thing. Hence the manual solution...

Best regards,
Christian
--
http://logik.phl.univie.ac.at/chris/

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
  • Prev by Date: Re: NSTextView crashes with web content
  • Next by Date: NSColorPanel breaks GetColor?
  • Previous by thread: Re: Oracle Database Connection within a Cocoa Application
  • Next by thread: NSColorPanel breaks GetColor?
  • Index(es):
    • Date
    • Thread