• 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: Retain cycle problem with bindings & NSWindowController
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Retain cycle problem with bindings & NSWindowController


  • Subject: Re: Retain cycle problem with bindings & NSWindowController
  • From: "Dennis C. De Mars" <email@hidden>
  • Date: Tue, 28 Sep 2004 21:55:40 -0700

On Sep 28, 2004, at 7:04 PM, Steve Checkoway wrote:

I just read the "Retain cycle problem with bindings & NSWindowController" thread on Cocoabuilder after beating my head against the problem for most of the day. After all of this I feel like bindings have wasted far more of my time than they saved... =)

I'm curious, has anything actually been done about this bug or has a better way to work around it been found? If not, I have to add IBOutlets for all of my subviews that have bindings to the window controller. If I do that, I might as well not use the bindings and just update the values manually.

It seems to me that bindings should never retain for this very reason.

- Steve

If you think it is that serious, you should definitely file a bug with Apple. I'm sure they know about the problem and I am sure they take it seriously, but the greater the number of people they know are waiting on a solution, the higher priority it will be.


There was a little more discussion of this problem in a subsequent thread titled "Who should release whom in a document-based app?" There I pointed out another way to work around the bug. First let me restate the basic principle you have to follow because of this bug: You cannot have a binding path that goes through the NSWindowController. That object cannot be referred to directly anywhere in the path.

So here is the workaround I currently use that is simpler than what I outlined originally in the thread you referenced:

You create an NSObjectController object in the nib file. You create an outlet in your File's Owner to point to it (this is the only extra IBOutlet you need). When the nib file is loaded, you set the content of the NSObjectController to the model object or objects you need to bind to. (If you only need to bind one model object just set the content to that object. If several need to be bound, set the content to an NSMutableDictionary (it actually is already by default) and create entries in the dictionary for each model object.

On the view side, just bind to the NSObjectController. Don't send any binding paths through the File's Owner (assuming the file's owner is an NSWindowController). That's all there is to it.

The only reason to have the IBOutlet (generally in your NSWindowController object) set to the NSObjectController is so that you can easily get to the NSObjectController to set its content at run time. I don't find this too inconvenient. The main inconvenience is setting the content manually for all objects you need to bind to. This detracts from the "no glue code" advantanges of bindings, but at least you only have to do it once per object rather than once per binding. It's up to you whether this is more work that it is worth...

- Dennis D.

_______________________________________________
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


References: 
 >Re: Retain cycle problem with bindings & NSWindowController (From: Steve Checkoway <email@hidden>)

  • Prev by Date: Controllers and Business Rules
  • Next by Date: Re: Document Edit State, Undo and Cocoa Bindings
  • Previous by thread: Re: Retain cycle problem with bindings & NSWindowController
  • Next by thread: NSDocument and Saving File Packages
  • Index(es):
    • Date
    • Thread