On Jun 27, 2011, at 15:58, Philip Dow wrote: > I am exploring using a custom window controller for a core data document > based application and wanted to ask those more knowledgeable than myself if > there are any caveats I must consider. > > Following the documentation, I am overriding NSDocument's > makeWindowControllers method in my NSPersistentDocument subclass and am > initializing the window controller here before calling addWindowController. > Everything works as expected in a simple trial run. > > The critical difference is that I am not using my document subclass as the > window controller's owner, and neither will my document subclass be the > window's delegate. I am pursuing this route because the custom window > controller is based on existing code which I am integrating into my > application and which requires that the window controller itself be the nib > owner and window delegate. > > My concern is that I will lose some built-in essential functionality if the > persistent document assumes that it is the owner of the nib file and the > window delegate. I don't know that it does, which is why I'm checking here. > An example is the undo functionality which is normally provided by the > managed object context in a persistent document. > > Does the persistent document framework make any assumptions about the > persistent document normally owning its nib file and acting as its window > delegate which I must make up for when using a custom window controller that > takes over these two roles?
Nope, what you're proposing is perfectly normal. It's within NSDocument's intended behavior that a NSWindowController should take over the role of being the window nib's File's Owner. All you need to do is have your NSWindowContoller subclass' init method use [super initWithNibName:] -- or, what is the same thing, [super initWithNibName: ... owner: self] -- and NSDocument bows out of the nib picture. The fact that it's really a NSPersistentDocument isn't important. This part of the behavior comes directly from NSDocument. Undo (in the sense of its relationship to Core Data) is a data model function, so it doesn't care what kind of controller sits between the data model and the user interface. The only factor I can think of to consider is that the Core Data model and managed context come from the document. However, addWindowController: sets the window controller's "document" property to the document object, so you can always get to document-based information via windowController.document (once nib loading reaches the awakeFromNib point, that is). _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
