I'm still digesting all the fine advice in this thread. But since it seems like I'm going to keep my standalone data source in some form, here is a quick answer to Martin's question regarding crashes.
On 2012 Sep 05, at 10:16, Martin Hewitson <martin.hewit...@aei.mpg.de> wrote: > occasional crashes that occur when the parent NSDocument instance (which has > an instance of the view controller and adds the view to the main window) is > closed. I believe I'm hitting corner cases where the outline view still tries > to display the objects which have already been released as a result of > closing the window. Yes. > Is there any advice as to how to handle these corner cases? Would it be > better (or for that matter, any different) to dispense with the stand-alone > 'builder' object and just compute the objects within the view controller? I don't think it would be any different, assuming that your adjunct 'builder' object is alive until the view controller deallocs. As far as the corner cases, I think Chris Hanson implied that an NSArrayController has the document-closing housekeeping built in. Interesting, but my NSTableView is actually an NSOutlineView, and NSTreeController would be too much of a rewrite. With the standalone data source, my approach is to set all relevant references to nil as soon as you get any indication that a document is closing. The references you want to nil are, of course, the table view's data source and delegate. But look both ways; also set the 'document' to nil in the standalone data source. Regarding the indication, I've yet to find a single hook in Cocoa which gives me a reliable early warning that a document is closing. So I've implemented a 'tearDown' method, with an interlock so that it only runs once, and fire at it liberally from multiple detectors… • Override -[NSDocumentController removeDocument:] • Override -[NSDocument close] • Override -[NSDocument readFromURL:ofType:error:], fire if anything fails • Fire early from any of your methods which cause a document to close _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com