In the discussion linked to above, Shane explains (if I can put it in my simpleton’s tongue) that the error is generated because AppleScript tries to send the activate message to the target it ‘remembers’ from the first command. But, of course, that process is now dead as a result of the first command, so we get the error. Clever old AppleScript doesn’t give up though, and looks for another process, finds it or creates it, and so launches the app (in this case Console, but that’s just for the example).
Assuming I’ve more or less told the tale correctly, my questions are:
Is there any way to force AS to forget that first proc Id after the first command and before the second? Some kind of ‘flush’ I guess I mean. Why? I don’t want that error to be logged, which will only raise user questions (my users are techie enough to be sniffing around Console, even the horrible Sierra+ one).
Any suggestions on the best way to quit and immediately relaunch an app (I’ll take an answer in any language)? It is imperative that the launch does not fail. One of the reasons I’m leery about doing it this way is the dependence on the hit-and-hope delay.
This is all being done via a user domain LaunchAgent when certain conditions occur, and the agent is calling osascript (some other things happen apart from the quit/launch that make AS a better choice than a shell script, plus I need a nice dialog box, but I’ll take any other suggestions here also).
tell application "Console" to quit
tell application "System Events"
repeat while (application process "Console" exists)
delay 0.2
end repeat
end tell
tell application "Console" to activate
use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use framework "AppKit"
use scripting additions
set theApp to (current application's NSRunningApplication's runningApplicationsWithBundleIdentifier:"com.apple.Console")'s firstObject()
set theURL to theApp's its bundleURL()
theApp's forceTerminate()
repeat while theApp's isTerminated() is false
delay 0.1
end repeat
current application's NSWorkspace's sharedWorkspace()'s launchApplicationAtURL:theURL options:0 configuration:(missing value) |error|:(reference)
tell application id "com.apple.Console" -- resolved at run-time
-- etc
end tell
One thing I’ve never been clear on with the ASObjC bridge, though, is does it matter what ‘current application’ actually refers to? I mean, can it just be any parent process (including launchd itself), or has it got to be some kind of regular “Application” (i.e., a bundle)?
The parent process in my case is going to be osascript. Is the ASObjC bridge still available here (I know: “try it and see!”)?
Yep. I’m still making a few adjustments after the “migration” from my old MBP, but no unpleasant surprises so far. I couldn’t see any way during the initial set-up to prevent the machine from being signed up to iCloud and FaceTime, but I think I’ve managed to neutralise them now. The only comments I have so far about Sierra itself are that I’m not at all interested in any of the features mentioned in the “What’s New” tour and Script Editor’s toolbar bug hasn’t been fixed. No doubt there are improvements beneath the bonnet. The iWork ’09 applications weren’t migrated across, but work perfectly well in Sierra after being copied over separately.
The machine itself is gorgeous, silent, and fast! Script Debugger and Xcode now open practically instantly instead of taking just over and just under half a minute respectively. There’s loads of workspace on the 27" screen, the picture’s great, and the Magic Mouse and Keyboard are cute and easy to use. And my favourite Mac store was offering 10% off the price of this particular model last week.