site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teal.net; s=teal; h=received:x-smartermail-authenticated-as:received:from:message-id:content-type: mime-version:subject:date:in-reply-to:cc:to:references:x-mailer; bh=CuFnHPF7FL8w+/qXHHkdYNON9Bhx7PlMBvAfI6DFz9Y=; b=Q2aLCpoLahLXNkSq7A6HV7KJV00LNlPQ3TBnoRM47Hnau+lBU0Z9IFYdTgr4ec5FXaooZZBh/UcjP UDnlWp7kPedGfTRVmTLls9Z/WsJ9XvFBiMLCJN2TT8PvJKBnaALDDnJiMKptJcqc1FYiNRG4VANkCh tHjBTYGy6689i35k= On Aug 30, 2017, at 06:18 , Jonathan Mitchell <lists@mugginsoft.com> wrote:
My documents have a lot of variable user cancellable activity that must run prior to document closure regardless of whether the document is dirty or not.
My solution is to run a termination preflight that processes my clean documents prior to allowing actual termination,
There’s a difference between your scenario and the one in the thread you linked to. In your case, you don’t need to write anything to the document itself, you say. I think it’s a (slight) conceptual mistake to tie the termination processing to the document machinery, especially as overriding NSDocumentController is a bit hacky even when done right. I also think it’s a mistake to override “terminate:”, because it’s just an action method and you can’t be certain that it’s actually going to be called. (The standard menu item could have a different action method name in the future, or there may be paths within Cocoa that don’t invoke the action method.) Instead, the “applicationWillTerminate:” override of your app delegate seems like the right place, especially because it explicitly permits you to delay terminate while you do stuff, without having to run the run loop manually. That’s the *point* of the “applicationWillTerminate:” mechanism. The consequence of using this override, though, is that documents may already have been closed. So, what I would suggest is maintaining a separate pool of “tasks” (a set of document references would be the simplest approach). In an override of “close”, start the user cancellable activity and remove the corresponding task from the pool. In “appWillTerminate:”, trigger any remaining tasks, and send the termination reply when they’re all done. The reason I’m suggesting “close” rather than “canClose…” is just that it’s simpler, and it avoids getting tangled up in any possible code path where the close is prevented. _______________________________________________ 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/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com