|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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? ~Phil_______________________________________________ Cocoa-dev mailing list (email@hidden) 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: This email sent to email@hidden
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.