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?
Did you put special AppleScript entry (entries ?) in the plist application ?
(people in this forum always talk about that for the recents macOS versions ).
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.
The test code could not be simpler: the 2 lines at the top of the thread, new project, one window, one button, i even added:
com.apple.security.automation.apple-events = YES to the plist
No dice. But if I try Christian’s simple example project: DeterminePermissionToAutomateTarget.xojo_binary_project
it works fine. In my project, with the exact same code copy and pasted, it fails with an error. I even tried it with a new admin account and same problem. This is COMPLETELY messed up.
How are you invoking your scripts, just calling embedded .scpt files?
Of course, not. I’m using the same code that you posted in my solution. I have over 80 scripts in my app. As usual, you must be doing something different. Is your app code-signed in debug-mode?
If I have time tomorrow I’ll update my AppleScript example so that you can test. It can only be something simple.
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.