If you do have to go this route then I suggest not moving the call into the KME tell block -- keep it separate. So the original code would be changed to:
tell application "Keyboard Maestro Engine" to set kmInst to system attribute "KMINSTANCE"
tell application "Keyboard Maestro Engine"
set theLink to getvariable "localLink" instance kmInst
end tell
It looks clunky, but it will be a lot easier to automate such a change via search and replace.
Check that it works first, though!
Works for me. For what it's worth, I have no scripting additions installed.
Wait, it works for you now? You're the one who started the thread saying it didn't work ... but now it's fine?
-rob.
i have only two standard additions:
Digital Hub Scripting.osax
StandardAdditions.osax
The laptop Mac is a test machine, and I keep it pretty clean—outside of Moom, the only other third-party thing that's always running is NextCloud, and I've tried the macro with it disabled (no change).
-rob.
I created a brand-new account on the laptop, logged it, worked through the setup, then installed the test macro from this thread. It fails with the same errors as seen on my normal account.
I am so completely out of ideas, I don't know what to try next.
-rob.
Here's what I'm seeing with KM 10.2:
This works in KM's "Execute AppleScript" action:
tell application "Keyboard Maestro Engine"
set foo to getvariable "test"
end tell
But when I run two commands in the same action, I get "Keyboard Maestro Engine got an error: "test" doesn’t understand the “getvariable” message. (-1708)". It doesn't matter whether it's the KMINSTANCE command or something else:
tell application "Finder"
get front window
end tell
tell application "Keyboard Maestro Engine"
set test to getvariable "test"
end tell
Same with setvariable.
test is a global variable, and those work fine, as you don't need to set the environment. Does your original script still error out? (I'm guessing it does.)
That is a very interesting finding, and I can recreate it on my macOS 27.2 machine. This runs fine in Tahoe:
tell application "Finder"
set theWindow to front window
set windowName to name of theWindow
end tell
tell application "Keyboard Maestro Engine"
set test to getvariable "test"
end tell
display dialog windowName & test
But in Golden Gate, it throws the "I don't understand" error if both blocks are present. Remove the getvariable block, and the window info is displayed. Remove the windowName block, and the test value is displayed (with proper editing of the display dialog line for each case).
What the heck.......
-rob.
Sorry…I meant Nige’s suggestion fixed the issue for me, original bug still there in the absence of that coding change,
Working fine here (still macOS 27.0):
@jbb, @JW123 -- how did you get to Golden Gate? @griffman did a clean install -- did you? While it's possible that it's random GG users seeing this it is far more likely that you all have something in common that those of us not seeing this don't.
@griffman -- for completeness, can you try the latest script with the tell blocks reversed?
tell application "Keyboard Maestro Engine"
set test to getvariable "test"
end tell
tell application "Finder"
set theWindow to front window
set windowName to name of theWindow
end tell
display dialog windowName & test
how did you get to Golden Gate?
@Nige_S I forgot to mention that I’m on the 27.2 public beta. Not sure if it started there or with 27.0. Anyway, I also upgraded to 27.0 through a series of public betas.
Does your original script still error out? (I'm guessing it does.)
@griffman Not sure which script you mean here. The one with just one command works, even if it’s getvariable.
FWIW.
Using tell app id bundle id shouldn't make a difference, but the error doesn't seem to make much sense either.
Instead of writing:
tell application "Keyboard Maestro Engine"
end tell
Maybe:
tell application id "com.stairways.keyboardmaestro.engine"
end tell
Also maybe try including or removing:
use scripting additions
If the alternate tell app syntax doesn't work, maybe the case it was meant to address will ring a bell with someone else.
The first workaround was originally offered by Shane Stanley as a way to stop a seemingly similar, but clearly not identical, error from occurring where a tell block addresses the host application.
"It’s a quirk of AppleScript. When you write a simple ASObjC script, anything addressed to current application gets passed to AppleScript to resolve. But if you address the host application first, then it is defined as current application (the “traditional” behavior of AS), and subsequent attempts to use ASObjC fail.
The error when running Script Debugger looks like this:
The Golden Gate error reminded me of this issue where something can't find a method because the context has changed.
Other maybe/maybe not relevant tidbits:
Apple Language Guide describes standard additions, where system attribute lives, this way:
"If a script uses use scripting additions, AppleScript may optimize scripting addition commands, sending them to the current application instead of the current target (it) when it does not change the meaning to do so. For example, random number does not need to be sent to another application to work correctly, and will always be sent to the current application when imported with use. Without a use scripting additions command, AppleScript must use a less efficient dispatching scheme, so explicitly declaring them is recommended."
(Scripting Additions normally, I guess, loads automaticaly. If there is another use statement , it needs to be declared explicitly, in which allows for "optimization".)
Maybe "optimization" or the "less efficient dispatching scheme" is somehow affecting context?
Anyway, it shouldn't matter if system attribute is in or outside the tell application block (current target) but it clearly does.
Also, "system attribute" itself is not as simple as it looks.
All by itself, it returns a list of environment variable names.
Given a four-character "selector" like "cpus", not in the list of environment variable, it calls a deprecated Carbon/Core Services API for querying the operating environment (superseded by NSProcessInfo) to return number of logical processors available.
Maybe this odd keyword is somehow involved in messing with context?
I wish I could offer clearer thoughts on this.
Safe Boot? Safe Boot is pretty ugly though, so I'm not sure it would tell you much regardless of the result. But perhaps worth trying.
And ... that works perfectly. What the heck is going on?
That didn't make any difference.
Nor did that. But changing the order fixes the issue in the sample script.
-rob.
I assume "perfectly" means it returns the name of the frontmost Finder window rather than an empty string or the name of an Engine window?
Which is a shame -- I was hoping it would be the latter!
Since this test doesn't require instance referencing it would be a good one to try in both Script Editor and a Terminal osascript to see if it is only problematic when executed from a KM Action.
If something is throwing out app identification/targetting and @CRLF's bundle ID fixes didn't work, you could always try referencing by path:
tell application "Finder"
set theWindow to front window
set windowName to name of theWindow
end tell
tell application "Macintosh HD:Applications:Keyboard Maestro.app:Contents:MacOS:Keyboard Maestro Engine.app"
set test to getvariable "test"
end tell
That assumes your system disk has the default name "Macintosh HD", so edit the path necessary.
Yes, I get the name of the frontmost Finder window, then the value in the test variable.
So you were thinking maybe AppleScript was confused over the tell application "Finder" command? Not sure I understand why that might be the output.
That fails with the usual "doesn't understand getvariable" error.
-rob.
I was thinking it was getting stuck in the context of whatever the first tell was (and the original Standard Additions call was behaving like an implicit tell). Effectively becoming:
tell application "Keyboard Maestro Engine"
set test to getvariable "test"
(*
these lines ignored at execution
end tell
tell application "Finder"
*)
set theWindow to front window
set windowName to name of theWindow
end tell
display dialog windowName & test
Which would either give you an "invalid index" error when the Engine had no windows open or the name of the frontmost KME prompt/display text/etc.
That's because your scripts will compile but not execute, and the closest I can get to reproducing your error is:
tell application "Finder"
set theWindow to front window
set windowName to name of theWindow
using terms from application "Keyboard Maestro Engine"
set test to getvariable "test"
end using terms from
end tell
display dialog windowName & test
...which isn't reversible.
It's the "will compile but won't execute" that's getting me. AS can obviously target the app well enough to see its Dictionary, but can't execute commands from that Dictionary at runtime...
Only other thing I can think of is translocation or sandboxing of KME. Can you check for both in Activity Monitor? The "Sandbox" column is hidden by default so right-click the column headers to show it, the path you can see by selecting KME and hitting the i button (or ⌘I, or View->Inspect Process).
Sadly, all is normal there as well—KME reports it lives in the KM bundle in /Applications, and the Sandbox column is "no."
-rob.
Such a train wreck. I stupidly updated to the macOS beta, and it caused so many errors that I basically had to restore from a Time Machine backup. Unfortunately, the Time Machine backup seems to want to only restore to the same beta, so I might be copying all of my files off of my Time Machine backup like some kind of peasant.
For me, this code runs fine in script editor
say "about to set variable"
tell application "Keyboard Maestro Engine"
setvariable "spellChecked" to spellCheckedValue
end tell
but run from inside a KM "do Applescript" it fails with the error others have been reporting.
I am currently undertaking the laborious task of reinstalling Mac OS 27 and will avoid any beta software. But I see that Mac OS 27.1, a proper non beta, is ready to be installed. I never want to have my main machine rendered useless again, so can anyone report if there are errors in the mac OS 27.1 release?
** Edit, I wiped my Mac, installed Mac OS 27 via a USB drive, and restored my files. I will MUCH more careful when updating in the future.
Interesting. “spellChecked” is a global variable. But @griffman and @jbb have said global variables work fine and they were having problems only with local variables…
So, this is another variation of the problem.
I have used both the Beta and official release of macOS 27.0 on multiple Macs without these issues (as have others in this thread) so this is a very mysterious and hard to track down issue.