site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On Jul 19, 2007, at 2:42 PM, Fritz Anderson wrote: I want to quit an application before I overwrite it or its preferences. At present, I have preinstall/preupgrade simply use osascript to quit the application. This is not a good experience, as having the application save or not save its documents will be wrong some of the time; and having it ask leaves the possibility the user will cancel the quit. The better thing to do would be to stall the installation until the user quits the application. I've seen Apple Software Update installers refuse to proceed unless, for instance, iTunes has been quit; it posts an alert with the objection, and reasserts it so long as iTunes is running. I gather from Googling lists.apple.com that this is a problem with a known solution, which has been discussed extensively and optimized. This sounds better than my Braille-ing it out for myself, but I can't get that solution out of Google. Can someone please refer me to it? Apple's policy (which is not followed 100%) is to put up an error immediately if the target app is running. To do this, check for the app running in your InstallationCheck script (or similar part of the distribution script), and just return an error. This means that the user has to switch to the other app, save and close, quit the installer, and then re-run the installer. That's a bit lame, but. There's two other possibilities, which are used occasionally: 1) If you KNOW for a FACT that the user will not lose data, you COULD have the installer quit the app, forcibly. Apple used to do this with iTunes, but we don't do that any more because iTunes might be downloading a movie you paid for, or syncing with a phone, or something. 2) You could allow the install to start, and then, during preflight, call an app to put up an alert asking the user to quit the app, staying stuck in a loop until they actually quit. Apple does this with software updates, but that's because there's no other real choice in the matter. It's bad because we're stuck in a loop, and if the user has left software update running overnight, they'll be cranky the next morning. It's required because a preflight cannot abort installation. For these reasons, Apple doesn't use this modality during a regular software installation, for the most part. I'm going to suggest you stick with the suggested policy, since it's the lesser of evils. If you wanted to be extremely powerful, you could write a helper app that is called during InstallationCheck, which would test if the target app is running, show an alert if so, send a quit apple event to the app and bring it to the front, and then, when returning to the helper app, decide if the target app is quit, and if so, return noError. It would also have a "Cancel" button that returns an error to the InstallationCheck. You can write some slightly clever code to say "If Installer.app is the frontmost app, make ME the frontmost app" which will make it look like the program is part of the Installer.app. The only drawback to this is that the user will get the security alert ("The package contains a program that determines if the software can be installed!"). And that it's a good sized piece of code. And yes, it would be great if the Installer.app did this someday. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com