This is more of a technical question rather than a script question. But, I’m wondering if anyone here has ever run into a similar issue, or if possibly I’m just dealing with macOS system issues and it’s time to reformat and reinstall macOS on my 2020 M1 MacBook Pro. Side note: None of these issues show up on my Intel 2014 Mac mini (both systems are running Monterey 12.6.8).
I’ve had issues (on the M1 MacBook Pro) that I posted here (Script Error Issue Question), where a script saved as an application by Apple’s Script Editor would result in an error, but the exact same script saved as an application by Script Debugger, would not throw the error.
Today I received a different error (see image), but it’s the same situation as above. This script (posted by peavine in post #30 here (Help Learning AppleScript)) saved as an application by Apple’s Script Editor results in this error, but the exact same script saved as an application by Script Debugger, does not.
I’ve included screen shots of the Get Info windows of both the Script Editor saved application and the Script Debugger saved application, just in case they may be of help.
I guess I could just continue on, making sure that any script applications that I run on the MacBook Pro are saved in Script Debugger, but thought I’d post this in case there is an easy explanation.
Hey Homer,
you mentioned something regarding a resource or book for Applescript and awhile back, I came across this book. I quickly skimmed through it at book store. Looked good from what I saw.
Keith
Apple Training Series: AppleScript 1-2-3, 1st Edition. by Sal Soghoian and Bill Cheeseman.
I’ve just leapfrogged several macOS versions from Mojave to Ventura, so I can’t say for certain if the following applies to Monterey. But it probably does.
The values of properties, globals, and “top level” variables (ie. variables set in the implicit or explicit run handler) are considered to be persistent properties of a script. In a script which actually runs (as opposed to being loaded as a library), the values of these variables are saved back to the script file at the end of each run. This changes the script file’s modification date, and probably its size and contents. Where the script’s been saved as an application, this could cause macOS’s security system to see the application either as a new one or one that’s been interfered with since it was last authorised to do something with security implications.
I seem to remember Shane saying that scripts saved from Script Debugger have some sort of setting which prevents “persistent” variables from being persistent. This could explain why applications saved from Script Debugger aren’t giving you the problem you’re seeing.
Otherwise possible solutions are not to save the scripts as applications, but to run them from, say, the system Script Menu, which then becomes the responsible application. In addition to this, I personally try wherever possible (and sensible) to use only local variables. These are variables which are explicitly declared as local or which are set and used inside ordinary handlers and aren’t declared as globals or properties at the top of the script. The easiest way to arrange this is to put the code you’d normally have in the run handler (or not visibly in a handler) into an ordinary handler and just have a call to that handler in the run handler. So instead of …
set fred to 7
set bill to 8
add(fred, bill)
on add(n1, n2)
return n1 + n2
end
… you’d have:
main()
on main()
set fred to 7
set bill to 8
add(fred, bill)
end main
on add(n1, n2)
return n1 + n2
end add
Thanks, I tried a couple of things based on the information you provided.
Even though the application created in Script Editor throws the error, running the script from within Script Editor does not, the script runs successfully.
When the Script Menu is added to the menu bar and the script is run from there, it also runs successfully.
So, I think I’m going to chalk this up to one of those macOS mysteries that, although it now has a few workarounds, will possibly never be fully explained.
I’m on Ventura now, but I’ve encountered Privacy & Security issues with AppleScript apps on Monterey as well. I’ve attempted to determine what causes such issues but never could establish a clear pattern. Saving an AppleScript app with Script Debugger usually fixed matters, and, as a last resort, I create a new AppleScript app with the same code but a different name.
The reliable solution, as Nigel suggests, is to run AppleScripts as scripts whenever possible. Unfortunately, there are occasions where an app is required and a script won’t do the job.
BTW, Script Debugger has Bundle & Export settings, and I wonder if these make any difference?
I’m trying my best to not get overwhelmed by Script Debugger. In addition to what you posted, its Preferences include: General, Editor, Text Substitutions, Themes, Execution, Building, Dictionary, Key Bindings, and Software Update.
So far, I’ve left everything at the default settings. It’s working, I’m learning and I have no immediate need to rock the boat.
FWIW, I’ve quoted below from Script Debugger help, although I don’t know if this is pertinent to the matter at hand.
Code Sign Apps. This popup menu lets you choose to sign applets using one of the valid signing identities stored in your login keychain. When running under a version of macOS before Big Sur, the first option is Do Not Sign, allowing you to turn off signing altogether. If you are running Big Sur or later, applets will be saved as universal Intel/Apple silicon versions, and will therefore require signing. In this case the first option will be Sign to Run Locally, meaning applets will be signed, but with no signing identity specified.
I checked on my Ventura computer, and Script Editor does have an option to “Sign to Run Locally” when exporting an AppleScript app. I agree that this seems a good practice.
Unfortunately, AppleScript apps that use System Events typically will not run on my computer and instead issue the not-authorized dialog. I exported my test app and added System Events to Accessibility but that didn’t make a difference. I finally got my test AppleScript app to run without error by deleting it from Accessibility and then doing a drag-and-drop of the app on the Accessibility pane. I think that was just a one-off, though.
