Firstly, you’ve got the ‘quit’ command inside ‘tell’ statements for two other applications. A recipe for confusion.
Secondly, the Finder’s not needed here anyway.
Thirdly, the process name given is different from the application name. Sometimes that’s correct; usually it’s not. I don’t know the situation with Microsoft Excel as I don’t have it.
Fourthly, System Events itself now quits after a certain amount of time unless you run a script to change this. However, I’d expect it only to cause a slight delay here and your error message suggests it’s actually System Events reporting the error.
Possibly something like this would fix the problem:
tell application "System Events" to set ExcelRunning to ((bundle identifier of application processes) contains "com.microsoft.Excel")
if (ExcelRunning) then quit application id "com.microsoft.Excel"
I’d leave the Finder out of it. This works for me in ML 10.8.5
tell application "System Events" to if exists process "Excel" then
tell application "Microsoft Excel"
activate -- added to promote a possible message to save.
quit
end tell
end if
tell application "System Events"
delay 0.5
if exists process "Excel" then
quit application "Microsoft Excel"
end if
end tell
I think I’d rather use the application id though as in Nigel’s script. That probably won’t change.
I edited my process quitting script to use that instead of names:
set my_name to name of me
tell application "System Events"
set app_ids to (bundle identifier of every process whose visible is true and not (name is my_name or name is "Finder" or name is "System Events"))
end tell
repeat with app_id in app_ids
tell application id app_id to quit
end repeat
Hi Stefan,
That’s a very nice and crisp way of writing it
Is there anywhere a detailed history (“official” or otherwise) of AS changes, updated at each successive AS upgrade?
The running state is just a finished launching state. It simply says that the application has fully loaded by the program loader (into the kernel). It doesn’t say if if the application itself is completed with it’s initialization. The AppleEvent manager sends an apple event with a timeout which means the application still has 1 minute to launch. Adding a wait-loop is useless to me, because the running state doesn’t even wait until all the UI elements are loaded (for GUi scripting)
The point of my post was that “waiting until the application is running” is already done by the AppleEvent Manager. When an application is still launching the AppleEvent manager waits until the application is ready to receive AppleEvents. To make an wait-loop for this is not needed. Another situation where you can need a wait-loop is for GUI scripting, making sure the gui is ready. But the application already has an running state even before interface files are loaded so it’s not useful in those situations either.
Because I don’t see a third situation where you ever need such a construct I won’t advise anyone to use that in their code.
Had a slightly good sleep and it does work! I was thinking that using the application reference would launch the application, but It only does this when first compiled.