What exactly does NSDocumentController do when there's no NSDocument architecture?
What exactly does NSDocumentController do when there's no NSDocument architecture?
- Subject: What exactly does NSDocumentController do when there's no NSDocument architecture?
- From: Daryle Walker <email@hidden>
- Date: Wed, 27 Aug 2014 05:03:37 -0400
AFAIK, NSDocumentController has the only API for the “Open Recent” menu[1], so I added it (back) to my project. I moved my app delegate’s actions for the New and Open menu commands to my NSDocumentController subclass, but they wouldn’t activate until I forced them with an override of the user-interface validation method. It now seems understandable; since the controller can’t find any NSDocument stuff, it shuts out any method that needs the architecture. The “Open Recent” menu API has a NSDocument-based and an URL-based entry API; the latter meant for non-NSDocument apps to use.
But I saw something weird one time running my app through the Xcode debugger after a previous crash. I saw an NSLog message complaining about app restore data. I think NSDocumentController does app-restore actions even without an NSDocument architecture. Is this documented? What APIs can I use to control this? Are there other automatic actions NSDocumentController (or a subclass) does when initialized? (I just need it for the “Open Recent” menu, so I want to shut down, or at least check myself, any other automation.)
[1] For writing new entries. If you started with NSDocumentController, then rip it out, the “Open Recent” menu stays, unchanging but functional. (I never tried the “Clear Menu” option during that period.)
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
_______________________________________________
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