I was content with High Sierra, and against my better judgment, upgraded to Mojave.
Applescript worked fine before (I’m just transferring data to Apple’s Numbers, nothing fancy): I could simulate a paste from clipboard, etc.
With Mojave, scripts invoked from Xojo apps just fail, even tho the same script runs fine from the Script Editor. I’ll skip over all the other headaches I’ve tried to work around.
MBS seems to have a solution, as usual:
dim target as NSAppleEventDescriptorMBS = NSAppleEventDescriptorMBS.descriptorWithBundleIdentifier("com.apple.iWork.Numbers")
dim e as integer = NSAppleScriptMBS.DeterminePermissionToAutomateTarget(target, "****", "****", true)
In a simple test app, all’s good. The first time you get that annoying “MyApp wants control etc” dlog which did not happen under High Sierra. Fine. Security. I get it. You dismiss it once, then re-executing the above returns OK with no more pestering dlogs. The OS is convinced you’re allowing control over Numbers.
When I paste the exact same code into my production app, all I get is an errAEEventNotPermitted error, no opportunity with a dlog to tell the OS that YES, I WANT THIS. It’s as if the OS has cursed my one single app and refuses to even display the pestering dlog (yes, I pass true in NSAppleScriptMBS.DeterminePermissionToAutomateTarget).
I’m at wits end with Apple’s latest (not even, I bet Catalina is even worse) OS releases. Any ideas on what the heck might be wrong?
Internal settings stored for that application. Take Apple’s NSUserNotifications for example, which work much better in macOS 10.14 than the newer UserNotificationsUserNotifications (whoever came up with that). However once an application has used UserNotificationsUserNotifications, NSUserNotifications fail silently and I’ve not been able to figure out why.
I want to revert my 10.14 customers back to NSUserNotifications, because UserNotificationsUserNotifications can cause crashes (even Obj-C & Swift developers experience the crashes), but we’re unable to do so, because of some undocumented and hidden setting.
I would suggest checking the “Privacy” settings in System Preferences to see if there’s anything in there.
Edit: If you use App Wrapper, you can have App Wrapper insert the plist entries and sign your debug build when debugging.
Not sure which “two entries” you are referring to. The only AE-relevant entry in Xojo’s plist is NSAppleEventsUsageDescription, and this does not appear in any debug app, and the simple one runs fine, my main one fails as described.
I see what you found Emile, thanks. The test debug.app has no applescript-pertinent entries and runs fine, so i don’t think this is the issue.
Per Sam’s suggestion, yes indeed, i did find my app listed under Privacy > Automation, with Numbers checked under it, and ironically, that is the one app that does not work as noted above. And you can’t delete these entries, and unchecking-rechecking made no diff. What a headache.
Welcome to the party of stupidity - a bit late. You need to make sure that the app you are targeting for the AppleScript is launched BEFORE you do the AppleScript. Otherwise, you will get “permission denied” without the dialog. That took me a long time to figure out.
Numbers has been running the whole time. I just took the code I posted above from the test app that works, made a button with the same 2 lines in a brand new test app, and it doesn’t work, errAEEventNotPermitted error.
Can you make some source code for testing? Except for the problem with the not running apps that I fixed long ago my apps work fine on Mojave and Catalina. I’m using AppleScript for Filemaker, Mail and Outlook.
Thx Beatrix, appreciate it. No code signing (I never release my apps, for internal use in the lab only), but neither is Christian’s DeterminePermissionToAutomateTarget.xojo_binary_project which runs fine out of the box.
This goes in the entitlements not the plist, it’s for App Sandbox or Harden Runtime. You need to also make sure that the value is a boolean. I made a mistake with one version of App Wrapper, where App Wrapper understood it as a boolean, but when the system API wrote out the plist it wrote it as an integer (which worked) but was rejected by the App Store police.