I have this small macro that I've been using for a couple of years now.
Recently I've updated both Path Finder and KM, so I'm not sure if the problem relies in one or the other (or anything else, even).
As you can see from the log, it takes 7 seconds to execute the "Activate application" action (with Path Finder already open) and another 13 seconds just to check if a menu item exists and is marked.
After that, KM is also unable to select the menu item, even though it's there, unchecked and enabled.
Can anyone help me?
2023-11-29 20:24:09 Execute macro “PathFinder - Dual Browser - Enable” from trigger Editor
2023-11-29 20:24:09 Log: PathFinder - Dual Browser - Enable: Activating Path Finder
2023-11-29 20:24:16 Log: PathFinder - Dual Browser - Enable: Cheking Dual Browser menu item
2023-11-29 20:24:29 Log: PathFinder - Dual Browser - Enable: Clicking Dual Browser menu item
2023-11-29 20:24:29 Action 19263 failed: Select Menu Item failed because the menu item View➤Dual Browser is disabled
2023-11-29 20:24:29 Select Menu Item failed because the menu item View➤Dual Browser is disabled. Macro “PathFinder - Dual Browser - Enable” cancelled (while executing Select “Dual Browser” in the Menu “View” in Path Finder).
Since you've upgraded the other app, I recommend that you recreate all your actions from scratch (just the actions that reference your app.) It's possible, I believe, (I'm 80% sure) for an upgrade to cause the app name selection box to point to the wrong/old version.
I haven't figured it out yet, but 7+13=20 and I see you have 20 seconds as a timeout on your Activate action.
The action timeout set for Activate a specific application is 20 seconds, and it's never hit.
However, the Activate a specific application slowness is inconsistent, sometimes it happens, sometimes it doesn't. What happens all the time is the slowness on the "Checking menu item part".
If you look at these video, you can see what I mean. What's weird is that even just to start the macro it seems to me that it takes longer than usual, at least in the first case. But again, even this is inconsistent
What do you have the Engine.log file open in? Console?
I just tried, a sometimes the log change shows immediately and other times it is noticeably delayed.
I normally use
tail -f Engine.log
And when the Console display of the log entry was delayed, the tail -f showed the message appearing immediately. So that is probably just an update issue in Console and not related to the issue. The image is not clear enough for me to read the times, so I can't actually see if the time between the appearance is consistent with the timestamps in the log. In any event, I strongly suspect that delay for “starting” is just the delay for Console updating the log window from the file change.
As for why Path Finder takes time to come to the front, that I don't know.
The delay in looking for the menu stat may just be that the menu response from Path Finder is slow, using a menu path will reduce the search of the menus to just the specific menu which may be quite a bit faster.
Thanks for the hints Pieter and sorry, I thought the GIF player would be larger.
I tried again with tail and using the full path, but it didn't make any difference.
In this video I run the two macros: CleanShot 2023-11-30 at 11.52.43 · CleanShot Cloud
In the first case Path Finder is activated almost immediately, while in the second it takes 6 seconds just to log the start of the macro execution.
In both cases it take 13 seconds to check the menu.
Is it safe for my macros to downgrade to the latest version of KM 10 to test if it makes any difference?
Oh god! Your suggestion was right, Pieter.
In my last video you can see that I changed from "Dual Browser" to "View>Dual Browser" but I didn't switch the action configuration from "with this name" to "with path".
As soon as I did that, the macros started to be blazing fast again.
It's curious that they weren't slow at all until a while ago, even using the "with this name" configuration, but I guess that's just how computers work: sometime things break and you really don't know why
What was causing the delay at the start was that the editor was asking the engine for the condition result
So the engine is busy scanning the menus.
And you can see this in the video at 0:39 when the macro actually starts - as well as the macro starting, the editor reports the results of searching the menu, changing to “(currently false)”.
The issue is the scanning performance of the menus - it is possible that the system or the target app are being very slow at returning menu results, or the menu structure is very large (or potentially recursive).
