As a mobile app, Overcast always launches in the same inconvenient size and position on the Mac, so I made a simple macro to automatically move and resize it. And because it's a translocated app, the trigger has to be matched by bundle ID. What happens, though, is it will trigger unexpectedly and often. Initially, I 'solved' this by adjusting the timeout cancellation to 30 seconds. This prevented duplicates of the running macro building up, but it was bugging me that it was still triggering so often when it oughtn't to be.
So I tried another simple solution that I thought should work, which was to use the Try/Catch action and the All Running Applications token (and I've only just this moment noticed the All Running Foreground Applications token, which would be better) to check whether Overcast is in fact running. That check is much faster than waiting for the 30-second timeout to cancel the macro, but it doesn't always fail when it ought to...and that's what has me confused now.
Admittedly, this isn't a huge issue, but it is still bugging me. Any thoughts appreciated.
Macro screenshot (sorry it's a little messy—I was testing some more)
You haven't got a background app called Hovercash, have you? I suspect your regex is looser than intended -- tightening that up and moving to %Application%Foreground% may be enough to solve your problem.
I obtained Overcast from the App Store to try a few things out.
I can confirm that Keyboard Maestro flags Overcast as a translocated application – but I'm not sure that it really is. Moving Overcast out of the Finder and back again doesn't make any difference, and of course a direct download from the App Store installs an app straight to the Applications folder, where it belongs, anyway. Running sudo xattr -rd com.apple.quarantine /Applications/Overcast.app in the terminal should clear a translocation quarantine flag but results in "Operation not permitted" for the files inside the app bundle.
In any case… I had no problem with the following:
Create a macro group that is set to be available only to Overcast.
Create a macro that uses the Manipulate a window action.
Many thanks for this. I did originally start out with a hot key trigger to resize and reposition the app window, but that got old very fast, which is why I changed it to trigger on launch. And the macro as is doesn't have any issues at all triggering when it's supposed to; it just keeps triggering when it isn't supposed to and I'm uncertain as to why.
Many thanks again. But as I said, my macro is already working when expected. The issue is that it keeps triggering unexpectedly when Overcast has not actually been launched.
It looks to me as though your macro is testing for (1) the front window of Overcast + (2) the running applications list – without specifying that Overcast should be the active application. This could lead to false activation. Also, if test (1) is valid, test (2) should be superfluous.
In my experience, when the app is shown with (⚠️ Translocated!!), Keyboard Maestro's link to it is lost once the app is quit, so this method would require relinking the translocated app to the trigger every time, which rather defeats the purpose. I fought with this a lot already in a another macro for a different translocated app.
My macro tests whether Overcast is actually running by checking if overcast appears in %Application%Foreground%. If it doesn't, then the macro should cancel, which it does—sometimes. I don't see how this test could possibly result in a false positive based on whether it's in front or not. If Overcast is running, the rest of the macro works as intended. There is no second test; the Pause Until action is necessary because mobile apps can take longer to launch, and, because the launch time is variable, Pause Until is more reliable than Pause for x seconds.
I'm sure that @Nige_S is correct and that the problem lies in my regex.
Thanks, yeah, I use the same shortcut. I didn't ask that question very clearly, but the forum usually (though not always) converts the png to jpeg, which means a lot of ugly white space rather than nice, clean transparent backgrounds.
For me, that is not happening in this case. My macro has worked every time.
Your regex expression "overcast*", with the asterisk, is a match for "overcas" followed by zero or more appearances of the letter "t". "Overcast" would do just as well.
But anyway… I think you may have misunderstood try / catch a little. Your Cancel Just This Macro action is what happens when there is a catch, sure.. but the catch only happens if the try fails. When conditions result in false rather than true, that is not a failure. It is just one possible result. If there is something that the macro tries to do but cannot, that is a fail.
Right, the macro not working has never been the issue. The macro will continue to work when the app is actually launched; however, the macro will then carry on triggering randomly when it isn't supposed to. If you look at the engine log in my first post, you'll see that the macro triggered repeatedly thinking Overcast was launched when it wasn't. This was a problem before using Try/Catch and regex; I eventually added these actions in an attempt to make a better solution than just timing out since the Keyboard Maestro icon can get rather distracting always telling me that a macro is running when it shouldn't be for 30 seconds and then I have to check to make sure some other macro hasn't broken or run out of control.
Ah-ha!! So it does! I would swear that I tried that previously without success. Regex is new to me, so I've been searching and reading and experimenting with varying results. This could well be the solution, and I'll keep an eye on the logs for a day or so to be sure.
When I was testing, the try consistently failed at the Search Variable action if overcast didn't exist in %Application%All% (this was before I found %Application%Foreground%), but perhaps this is not the best way to force a failure. Though hopefully now with the correct regex and %Application%Foreground, it will behave a little better.
@kevinb's already explained why it is a bit loose. If the app is called "Overcast" then search for exactly that:
(?m)^Overcast$
"Using the multiline option so that ^ and $ match line beginnings and endings respectively, find any line that is exactly Overcast."
In this case it is -- when the regex action fails (falseif we were using an "If" action) to find a match it throws an error and we're off to the "Catch" block.
Neither can I -- but it can be difficult to tell from only screenshots. Can you upload the actual macro so we can check the various action options?
Sure, but I was specifically addressing "Keyboard Maestro's link to it is lost once the app is quit", which I did not find to be the case with my test macro.
In case you don't yet know about it: regex101 is very useful.
Ah! I see now.
And neither can I… now I understand the macro better. It turns out I am not as clued in when looking at a png as I am when looking at a macro in KM's editor.
Fair, although since the primary question has been 'why does this macro keep triggering when it shouldn't?', I felt I should reiterate to make sure we weren't talking at cross-purposes, though I should have specified further for clarity. Threading the needle on giving enough information without being excessively verbose can be challenging for me.
The only reasons I can think of are that either for some reason Overcast is quitting/relaunching (ie it's a legitimate, though unexpected trigger) or that something else with the same bundle ID is launching (perhaps an Overcast-related background process?).
Check for the first by keeping an eye on what's happening, see if there's a pattern. That does assume that the "unexpected triggers" are unexpected because Overcast is already running.
If those "unexpected triggers" are firing when Overcast isn't running, hopefully the combo of only checking %ApplicationName%Foreground% and the tighter regex will help. What you could also try is a match against %ApplicationName%1% -- if the macro is triggered because Overcast launches, the frontmost application will be Overcast.
(You'll have to reset the "Execute Macro" action.)
Yes, but what worries me is something like "Overcast Helper", "Overcast-Updater", or similar are triggering the macro. I don't know if the bundle IDs of such sub-apps would be the same as Overcast's and so trigger the macro -- if so we need to make sure they don't false-positive the regex.
I suspect your regex is looser than intended -- tightening that up and moving to 
I just repeated what I was able to make work in another of my macros.
Moving Overcast out of the Finder and back again doesn't make any difference, and of course a direct download from the App Store installs an app straight to the Applications folder, where it belongs, anyway. Running 
