This seems to be a very fabulous Macro - and since I am very late to the party and there is nothing mentioned about which Version of KM is compatible my questions are:
Can I use this Macro with Version 10.2 ?!
Or is this Macro unusable for me until I upgrade Keyboard Maestro ?!
I canāt think of anything in the macro that would prevent it from working with v10.2, but there might be something Iām overlooking. I no longer have access to v10.2, so I cannot test to confirm. If you download and try it, please report back with your observations. Thanks!
first thing I have to mention is that the Help Text Window will not get closed when I press the Done Button of the Main Prompt.
another thing is the Macro gets canceled and throws a timeout error when I press the Console Button and brings the Console Application to the frontā¦ if I understand it correctly the Console should be there in Background and not being in the foreground.
because of that the Console.app doesnāt get closed, too when closing the Main Prompt ā¦ it also keeps staying open and will get the frontmost Application if I revive the Macro and clicking just the Done Button to close everything up. Quitting the Console.app manually isnāt a thing really - but if there is something like an automated workflow like this Macro which has to close up afterwards - and I think itās intended to function this way - it gets annoying over time and sucks ā¦
Iāve seen an Action (maybe it was the Dictionary Action where you tempt to store the Value for the Error) in which you used %jsELT_dict% for the Dictionary Name Field which I am seeing at least on my Machine .. I am wondering if thatās correct because itās highlighted in this for Keyboard Maestro typically yellow/light orange color ā¦ Maybe I am missing something about that but isnāt that a likely unsafe thing ?!
speaking of Settings used in the Macro I find that it is cumbersome to find the settings for the Dialog and Helper window positions ā¦ havenāt found them, yet ā¦ I think you should make a change and put everything related to settings in one big bit structured Group and use nested groups for specifying between each settings Type and put a comment before every Settings type group explaining for which type of setting it is for and if there are things changeable by the user defining them also ā¦
Thatās all I have for now ā¦ maybe there will come more ā¦ weāll see
Itās now dish washing and cooking time for me ā¦ I am getting hungry so I am AFK
That's not what I see; and I don't know why this might be occurring for you. As you can see below, the help window should close if the Action, Console, Reduce, Help, or Done button is selected. (If the Help button is selected, the help window will reopen.)
Maybe you could try running the AppleScript in the Script Editor (or Script Debugger) and see if the Help window closes.
( expand / collapse AppleScript )
try
tell application "System Events"
tell application process "Keyboard Maestro Engine"
tell (first window whose name is "Keyboard Maestro - Display Text")
tell (first button whose role description is "close button")
perform action "AXPress"
end tell
end tell
end tell
end tell
end try
Again that's not what I see; and I don't know why this might be occurring for you. Also, no one else has reported this issue to me. Maybe it's related to Keyboard Maestro v10.2, but that's only speculation.
To see the expected behavior, refer to the second video in the Engine.log Tool OP.
I will say, the macro actions required for this feature are a bit complex. I do have a question: When you. open the Engine.log manually in the Console app do you see the Search field?
This index is saved so that Engine.log Tool can open to the respective failure/timeout if:
If the hot key trigger includes the Shift key (ā§), or
the %TriggerValue% includes recall
Thanks for that comment, but the macro has not been designed for users to change those window positions. There are a few macro Settings and they are listed in the header comment.
If you want to mess with the window positions, you'll have to carefully change values in this block of actions:
Note that the first is a Group action and intentionally collapsed; but FYI here's the expanded group:
The variables local_MainDialogWidth and local_HelpHeight were very carefully set based on the main dialog size, the help window content, and my design goals. As I've released new versions of the macro, I've had to adjust these values because I've added some content to the help window.
Only just a quick and short reply since I donāt have the time for more details ā¦
Iāve seen your PM and I think that youāve nailed it ā¦ since my Localization is German maybe you should consider building a workaround into the Macro that handles the Localized Strings properly based on the Localization of the User.
Speaking of the Dictionary- thatās what I thought it might be the case of how you Store the informationā¦ but I was complaining about the way you defined the Dictionaryās Name in the Macro Action since itās showing up in a complaining state (the color is not white as it normally should be - because Iām using dark mode only).
Thanks for mentioning Danās Macro ā¦ I have this also in my toolbox.
It might be a localization issue for you, but before I take that on, I'd like to confirm it's the root cause. Please refer to my questions above. Thanks.
Besides the localization issues it turns out that the Display Text Window is not in focus and that it is the key to the issue for not closing it. Here I remind you on the Post from @Tomās Action Manipulate a Display Text Window which I use in most of my macros that include the Display Text Action ā¦ it allows me do display the window and then close it within the macro without moving the mouse and clicking it beforehandā¦
Maybe you could borrow some code from there to fix this issue from the Macro.
Speaking about the Console window .. yes I see the Searchbar when opening the App. Alwaysā¦
I Oren read about issues with the Console Application when it was automatedā¦ but I never had any issues on this topic before your macro came into my life ā¦
Maybe this could also be an issue with using KM 10.2 on Monterey 12.7.3 - I donāt know ā¦ yes I know that there is a newer Version 12.7.4 of Monterey ā¦ but I refused to update because I have also issues with other applications that I want to fix beforehandā¦ there will maybe be also the need installing everything from scratch with a clean install since I think that the Last Bartender 4 update crashed a lot on my Mac by installing the beta instead of the official version.
I complained this issue to the developers but no response from them yet ā¦ I also reverted the update using Time Machine and made a restart. But I know still have issues like displaying the hidden bar whenever I am in the menu bar and even quirks like selecting hidden Menubar Applications ā¦ - just to mention what I am currently have to live with ā¦ this is f* me up ā¦ maybe I complain about this to the developers of Bartender.
I am using this Application since my first day I switched over completely from windows years ago - and there was never an issue like this ā¦
Sore dude for not talking about the topic ā¦ back to topic again ā¦
Yes ā¦ this could be the action I was speaking aboutā¦ - and now I can tell you that you can actually see that the editor is yelling about how you referred the dictionaryā¦ it seems to work but the editor is still yelling because you arenāt using the correct syntax in the Token.
As I wrote about this I was not at home in front of my Mac ā¦ therefore I wasnāt able to post any Screenshotsā¦
I hope your questions are answered with this reply ā¦
The other thing we were talking about in PM is in the making ā¦ weāll see how quick I can get this done for you, too.
After reading your last post and rereading your prior posts in this thread (#19, #23, #25), it's now clear to me that you are providing four categories of feedback:
Misunderstandings about the macro design
Suggested macro changes
Keyboard Maestro Editor behavior
Macro behavior that is not working as designed (on your mac(s))
1. Misunderstandings about the macro design
No, when selecting the Console button the macro is designed to open Console.app and find the failure/timeout displayed in the macro dialog. Once this is completed, the macro cancels itself and Console.appshould be in focus. This is demonstrated the OP, Video #2.
Similarly, when selecting the Action button, the macro will complete the respective task and cancel itself. In this case, the Keyboard Maestro editor will be in focus. See the OP, Video #3.
On a related note, suppose you are viewing the fifth from last failure/timeout in the macro dialog (in this case the dialog would indicate: LATEST-5) and you press the Console button. As described above, the macro would do its prescribed tasks and cancel. If you'd like to restart the macro initially displaying the fifth from last failure/timeout, you can use the alternate hot key trigger (one that includes ā§) or start the macro from another (or Alfred) and specify Recall in the With Parameter.
Generalizing the macro to allow easy modification of the window positions is not something I'm planning to do. But you'll see in the above post, I did provide the actions that you could modify if it becomes a priority for you.
3. Keyboard Maestro Editor behavior
Actually, the syntax that I'm using is one of the permitted variants. You'll see this mentioned in the wiki (Variables).
You can also use a short form of just %Variable Name% to include variables as long as the variable exists and has a value and there is no corresponding text token, although generally it is better and clearer to use the longer form %Variable%Variable Name%.
I don't normally use the short form, but I make an exception for the Set Dictionary Value action. Regardless, you see the same Set dictionary field appearance when you use the longer form.
4. Macro behavior that is not working as designed (on your mac(s))
Above in #24 I started to address your observed issue. There I mentioned that I'm not able to reproduce the issue you are seeing but suggested that you run the following AppleScript in the Script Editor (or Script Debugger) and see if the Help window closes.
( expand / collapse )
try
tell application "System Events"
tell application process "Keyboard Maestro Engine"
tell (first window whose name is "Keyboard Maestro - Display Text")
tell (first button whose role description is "close button")
perform action "AXPress"
end tell
end tell
end tell
end tell
end try
The above AppleScript is what is being used currently in the macro.
Here's another similar script that I've successfully used elsewhere and just tested in the macro. It worked as expected. I suggest that you also try it.
( expand / collapse )
try
tell application "System Events"
tell application process "Keyboard Maestro Engine"
tell (first window whose name is "Keyboard Maestro - Display Text")
tell (first button whose title is "OK")
perform action "AXPress"
end tell
end tell
end tell
end tell
end try
Okay, thanks for the link. From there here's a third approach that works in the macro but but is slightly more complicated because it does require a Type a Keystroke action after the Execute an AppleScript action.
Here's the above AppleScript code:
( expand / collapse )
try
tell application "System Events"
tell application process "Keyboard Maestro Engine"
tell window "Keyboard Maestro - Display Text"
tell button "OK" to set focused to true
end tell
end tell
end tell
end try
If none of those work, then maybe there's some strange interaction that is occurring on your mac(s). Worst case scenario, close the Help manually.
If this is the desired function then I am sorry for misunderstanding It ā¦ But if you reread the whole statement from about this again you probably should get it that this is not going to happen on my machines and where my misunderstanding comes from - and since this seems to be a core function of your Macro this is seriously a huge bug ā¦
Edit: speaking of the huge bug i think this tends to be the issue based on the localization and we are discussing the implementation already via PM.
Many many thanks for this ā¦ appreciate this help ā¦
I am only using the title of your section because my iPhone doesnāt get the whole thing ā¦ but back to topic - thank you for reminding me of the short form for the Token - I must have forgotten about that because I donāt have ever used this in all the years I am using Keyboard Maestro. And I will also do it like this in the future.
Yeah the color is still there because the editor has no information about the Value since it is a Local Variable. Okay ā¦ getting it my Macro editor sometimes shows me that indicating color and sometimes not ā¦ something strange thing is going on here.
For the first and second Variant I gave you the answer yesterday telling you that It will not get closed ā¦ maybe youāre right that there is something strange going on ā¦
By the way thanks for option three ā¦ I will integrate it to test when Iāve set up everything from scratch again ā¦
I am going to delete my sync File this time and donāt reenable syncing until I am absolutely sure that my Macros are set up correctlyā¦ maybe I messed something up or there is something strange is going on with my sync fileā¦
But first I have to try to sleep a few hours ā¦ had a horrible night ā¦
Upon further review, and common understanding, let's move this issue to the fourth category: 4. Macro behavior that is not working as designed (on your mac(s))
Maybe it's localization, but maybe not. Now that we are on the same page, let's rule out something more fundamental.
When I was testing this macro I noticed that the Console.app Find feature can be painfully slow if the Engine.log is huge. (I did do some edge case testing by dumping thousands of events into the Engine.log).
You can get the Engine.log event count in the main Engine.log Tool main dialog. For example here's what I see:
If your Engine.log is huge (or even if it is not), to simplify testing, please do this:
Within the Keyboard Maestro editor, select Help > Open Logs Folder.
When the Finder opens, rename Engine.log to Engine-2024-03-20.log
Close the Finder.
Trigger the Engine.log Tool macro.
Select the Console button.
Summarize your observations.
These steps will help us troubleshoot the issue you are seeing on your mac. (By the way, if you have easy access to multiple macs, please try these steps on the other macs.)
Suggestion: include this thread's URL in the Comment action, right below the "revised" section to make it easier to find this thread. I saw that you added a link at the bottom, but 1) maybe people will not go all the way down to find it, and 2) the link you included sends the person to the forum itself (general), not this thread.
I noticed that Discourse doesn't care much about the title so you can even include this URL and it's still redirecting the person to the right thread: https://forum.keyboardmaestro.com/t/macro-engine-log-tool/33797 (in case you don't want to include the version in the URL)
When a macro is not easily found using a forum search (e.g., something I contribute within a thread), I do include such a link. But in cases like this, IMO this is an unnecessary additional step of maintenance because the macro can be easily found using built-in Discourse features.
As you noted, I do add the following at the end of the Version History.
The main dialog has been changed such that all buttons, with the exception of Done, can be selected by typing the first letter of the button label. Done can be selected by pressing <esc>.
When the Console or Action buttons are selected, the main dialog no longer closes. Note that it can easily be dismissed with the <esc> key. The Engine.log can be forced to reload, by holding down Control (ā) when the Console button is clicked. (This could be useful when monitoring a macro under development, however, a more efficient method would likely be the use of tail -FEngine.log available by holding down Command key (ā) when clicking Done.)
With help from@ComplexPoint, added an optional small window that displays the the name of the macro that contains the action that failed or timed out. (There will be a noticeable delay before this small window appears. For more information, see this thread.) By default, this small window will appear for every viewed failure/timeout, but that can be changed with a new SETTING named local_ShowMacroWindow. As the macro is running, this state can be toggled by holding down Option key (ā„) when clicking the Action button. In addition, this small window can be opened on demand for the currently viewed failure/timeout, by holding down the Command key (ā) when clicking the Action button.
Added seven additional options with modifiers: 1-3) the three modifiers mentioned above; 4) retreat or advance by 5 failures/timeouts; 5) retreat or advance by 10 failures/timeouts; 6) delete all log items except the latest n where n = 100 by default; 7) save the latest displayed Failure/Timeout to the Clipboard.
Modified the AppleScript used to close the Help window. The revised version is easier to understand; it might help address an issue reported by @Nr.5-need_input.
If running macOS Mojave or older, the main dialog vertical dividing lines are slightly shorter.
Updated the Help window: 1) added the seven new options, 2) changed the primary font color to a darker grey, changed buttons to red, changed modifiers to a darker grey, and 3) increased the vertical space between bullets.
There's no maintenance involved. As I mentioned, Discourse doesn't really care about the title of the thread. Even if the URL doesn't include the title of the thread, what matters is the number at the end. So as long as the thread is this one and you just update the version, the URL will never change, meaning you just add it to the original macro and won't need to change it ever again.
As you can see, the url below isn't the same as the one on this thread, but if you visit it, it will show you this thread:
https://forum.keyboardmaestro.com/t/macro-engine-log-tool/33797 (what matters is the number 33797)
Even if I completely change the title: https://forum.keyboardmaestro.com/t/rainny-day/33797
So since you already provide the version at the top of the comment action, you can use a generic link such as https://forum.keyboardmaestro.com/t/macro-engine-log-tool/33797 (without including the version) and having it at the top makes it even easier to find the thread
There's a little. When you first create a macro, you don't know the Discourse URL. So if you want to include it with Version 1.0, you'd have to create a new Macro thread (presumably without the macro), then update the post with the macro (after you've added the link). No, this isn't much, but why add even this little extra maintenance when a macro like this can be easily found using the forum Search?
Also, if one were to include a link and the link text differed from the actual macro version, yes Discourse doesn't err, but less savy Discourse users could get confused.
This seems like a good time to post a reminder that, in a tutorial, I've shared how I created and use an Alfred Workflow to launch Engine.log Tool. I do this particularly when I want to quickly use one of the alternate functions. Either way, this can be done without taking my hands off the keyboard.
After invoking Alfred, if I type elt, the above three entries appear. There are three, rather than just one, so that all of the alternative functions can be listed in the three entry subtitles:
So to invoke Engine.log Tool normally, I just press <return>; optionally to use one of alternate functions, I add a <space> and the listed abbreviation. For example, elt d deletes the Engine.log and produces a dialog similar to the following:
I've updated the OP with Version 8.1 of Engine.log Tool: Per the suggestion of @alltiagocom, included a forum link at the top of the macro. There is no functional change.
One thing I believe could be included is a button to copy the current message to the clipboard, which could be useful for example to share it here on the forum.
I'm aware that the "Console" button can be used to do to that, but it's an extra step that could be removed, especially because it takes longer than a button that just copies the message to the clipboard immediately.
And the user could even decide if it shows a notification or not after copying. I always like to have it set that way when I copy things to the clipboard, like this: ā XYZ copied to the clipboard!
So the main macro, right after the comment action, could have an action to set a variable to true or false and that would trigger the notification after hitting the Copy to Clipboard button (or not). This would make it easy to change that behavior in the future without diving deep into the macro and try to find the notification.
And it could have another variable action to customize the message being displayed in the notification.