![]() This was immediately followed by a second post: I wanted to post this asap so you can see all is not lost with Xojo but I’ve yet to figure out how to get Xojo to put the need extra permission into the ist file at build time, rather than having to do it manually. Now, when I run the app (the one whose ist I just edited) it executes the KM macro as intended. I’ve tried to do what you did and discovered that the Xojo log itself reveals the cause of the problem. It just so happened that a few years ago I had to develop a database app and Xojo was the easiest approach to use. I’ve owned Xojo for several years so this discussion caught my eye. A contributor (tiffle) to the Keyboard Maestro forum was able to help and for the benefits of people who might come to this thread in the future, I include his very complete response: (KM = Keyboard Maestro) ![]() While I got answers on this forum that pointed me in the right direction, they were over my head in terms of implementing what I was trying to do. ![]() This was not permitted although there were other AppleScripts that I could run that were permitted. I was trying to run from Xojo an AppleScript that would initiate a Keyboard Maestro macro. You may be able to talk your way around it, you may not.Īs Douglas Handy/Sam Rowlands/Christian Schmitz have alluded to, my fundamental problem of being able to have Xojo fire off some AppleScripts and not others is related to increasing security measures that Apple has introduced with Mojave and Catalina. You’ll face a higher chance of being rejected for using the “legacy” Sandbox entitlements, than being accepted. I would recommend you consider if it is worth it. Lastly: If you are considering the Mac App Store and the application you’re controlling doesn’t support “Scripting Groups”. I was going to do so when I wrote the article for my blog. The above process can be done with AW3, but I’ll confess that I haven’t tried yet. The above described process was pieced together with information from Apple’s developers forums (not their documentation) and tweaked until it worked. If AW4 was able to do what it needed without Apple Script, I would have given up and used the alternative method. I found this to be unreliable and to cause more problems that simply trying and capturing the failure message. There is API to check to see if your application can script an application, before you call the Apple Script.If the user clicked on “Don’t Allow”, a specific error is returned, at which point you can alert the user that they need to manually allow access for this functionality to work. Handle the result, you need to check for an error.For each build of the application, there should be a dialog box asking the user if they approve of it using Apple Script.Specifying which application that you’re sending Apple Events too, didn’t appear to make any difference.You can only provide one message, to encompass all of the applications that your app is targeting. Make sure you’ve specified a “Privacy Usage” message.Make sure it uses entitlements, as you need to provide the entitlement to be able to send Apple events.Code sign your application with the harden runtime option.I have not tested with the built-in Xojo functions or other libraries. I used my own NSAppleScript object from the Ohanaware App Kit to execute the Apple Script. ![]() I recently added Apple Script support to an alpha of App Wrapper 4 as it’s required to access certain features in DropDMG. Apple Script is on my list of articles to write for my blog, because of the steps required to use it modern versions of the macOS.
0 Comments
Leave a Reply. |