App wants to access control...

General
1

I’m running MacOS Mojave. I’ve written an applescript, launched by a pushbutton, that essentially works fine:

tell application “Keyboard Maestro Engine”
do script “scriptname”
end tell

When I first run my program in debug mode, it fails to operate. However, if I previously have run a shell script from another pushbutton:

dim s As Shell
s = New Shell
s.Execute( "osascript -e ‘tell application ““Keyboard Maestro Engine”” to do script ““somescript””’ ")

Then I get the following MacOS dialog:
“presstest2.debug.app” wants access to control “Keyboard Maestro 9.0.5.app”. Allowing control will provide access to documents and data in “Keyboard Maestro 9.0.5.app”, and to perform actions within that app."

I click “OK”. After that my apples script runs fine. Both “Keyboard Maestro 9.0.5.app” and “Keyboard Maestro Engine”, are white listed in my Accessibility listings.

Question: Is there something I can do in my system or Xojo app that will obviate having to run the shell script and typing “OK” before the apple script will successfully run?

Thanks.

2

No. Welcome - a bit late - to the new world of having the macOS ask for everything. It protects you, you know?

3

[quote=488717:@Ed Kleban]I’m running MacOS Mojave. I’ve written an applescript, launched by a pushbutton, that essentially works fine:

tell application “Keyboard Maestro Engine”
do script “scriptname”
end tell

When I first run my program in debug mode, it fails to operate. However, if I previously have run a shell script from another pushbutton:

dim s As Shell
s = New Shell
s.Execute( "osascript -e ‘tell application ““Keyboard Maestro Engine”” to do script ““somescript””’ ")

Then I get the following MacOS dialog:
“presstest2.debug.app” wants access to control “Keyboard Maestro 9.0.5.app”. Allowing control will provide access to documents and data in “Keyboard Maestro 9.0.5.app”, and to perform actions within that app."

I click “OK”. After that my apples script runs fine. Both “Keyboard Maestro 9.0.5.app” and “Keyboard Maestro Engine”, are white listed in my Accessibility listings.

Question: Is there something I can do in my system or Xojo app that will obviate having to run the shell script and typing “OK” before the apple script will successfully run?

Thanks.[/quote]
You can get some relief from this by notarizing your app, but it can’t be done for debug builds.

4

[quote=488717:@Ed Kleban]s.Execute( "osascript -e 'tell application ""Keyboard Maestro Engine"" to do script ""somescript""' ")
Then I get the following MacOS dialog:
“presstest2.debug.app” wants access to control “Keyboard Maestro 9.0.5.app”. Allowing control will provide access to documents and data in “Keyboard Maestro 9.0.5.app”, and to perform actions within that app."[/quote]
There used to be a time where any application just could execute AppleScripts to Automate other applications such as: tell application X to do Z.
That’s no longer the case starting with macOS 10.14. It’s become a bit trickier to use with Xojo, since not everything is built in.

You might want to have a look at this example project: Xojo Code Example: Using Applescript for Automation (macOS)
This example project shows:

  • How to use AppleScript for Automation (by providing an Info.plist with NSAppleEventsUsageDescription - otherwise nothing will work at all)
  • How to determine if the application has permission for AppleEvents / Automation (AEDeterminePermissionToAutomateTarget)
  • Explains how to deal with the permission results
  • In case you determine the application has no permission: How to open System Preferences at Privacy - Automation (so that the user can allow the app)

Absolutely… especially if it’s not just an own/personal/in-house-only application.

I don’t agree with you on that :wink:
I’d agree if you’d have written: “can’t be done ‘out of the box’ for debug builds” (because Xojo has no built-in CodeSign for macOS).
However, that absolutely is possible if you’re doing that on your own…

That’s why I encourage everyone to CodeSign (with Hardened Runtime) each and every DebugRun on macOS, allowing you to develop and debug as close to a Release Build as possible.
How to do that? There is this Thread that might be of interest. And it’s implemented in this example: Xojo2DMG.

Combine the two (do proper handling of Automation with Info.plist / NSAppleEventsUsageDescription and determining permission) and CodeSigning the DebugBuilds - and you’ll get as close as you can to the “built and distributed app” even while debugging.

Or just accept the facts, and click on “allow” every time you’re starting a new DebugRun. But then: test toroughly how a built and distributed application works…

5

It won’t be long for Apple to discover users are codesigning debugged apps and prevent that from their rules.
The goal of notarising applications is to distribute them, as I see that; distributing debugged applications probably doesn’t make much sense to them (to me neither)…

6

Hmm… No, I don’t think so. On the contrary… It wouldn’t surprise me if at some time in the future macOS won’t run any non-codesigned executable (debug builds included).

Yup.

I don’t understand what you mean by that.
CodeSigning ? Notarization
You could/should codesign any local DebugBuild (or don’t - and get the effects described by the OP).
You should/have-to notarize if you’re going to distribute a (beta/final) build (for the sake of your end users).

Anyway, that 's going a bit OT now. I hope my previous answer has helped to explain what’s going on with AppleScript/Automation, how one can/could deal with it on current macOS systems.
CodeSign is involved and related to what the OP is describing. It can be ignored (at least for now), or done properly. Notarization only comes in play when it comes to distribution.