I have a KM macro (PrepareSearch) that coordinates two apps: BBEdit and Chute. The purpose is to populate the Find and Replace fields of the BBEdit search dialogue so that it can be applied to the current text document.
Chute has two menu items that are called by shortcuts: first invoked is ⌘B and then ⌘D. The app does some minor calculations and ⌘B puts on the clipboard what is to appear in the Find field and then ⌘D puts on the keyboard what is to appear in the Replace field.
The starting point is the app Chute. The KM macro fires off the ⌘B menu. It then brings BBEdit to the foreground and puts the cursor at the start of the document (with some Apple script) and then places the contents of the clipboard into Find field. The Chute app is then brought back to the foreground. ⌘D is fired off to get the Replace contents on the Clipboard and control is returned to BBEdit and the Clipboard contents placed in the Replace field.
The script has an assigned hotkey. When it is invoked by this hotkey, everything works perfectly. But Chute is also capable of initiating an AppleScript. When I do this, then it does not work properly. The AppleScript is very simple.
tell application "Keyboard Maestro Engine"
do script "PrepareSearch"
end tell
The macro does run. For instance, the cursor is placed at the beginning of the document. But the ⌘B and ⌘D actions are somehow placed in a kind of limbo. Then they run at the very end of the macro (when it is too late).
What is placed in the Find and Replace fields of BBEdit is just what happens to be on the Clipboard before the macro is started.
In the Chute app I can log what happens with time stamps. The ⌘B and ⌘D actions occur within a second of each other even though there are pauses in the KM macro of several seconds between the invocation of the ⌘B and the ⌘D actions.
It is all very bizarre. I cannot really figure out how this happens without a deep understanding of the mechanisms within Keyboard Maestro. My view is that it should not matter whether the macro is started by a hotkey or by an AppleScript that invokes the name of the macro. And yet the results are entirely different. There is something "wrong" with how things behave when Chute starts the macro by calling an AppleScript.