Thanks for the update Jim!
The previous version is my goto tool for tracking down errors so I’m really looking forward to using version 2 with its enhancements.
Snappier name too 
1 Like
I've updated the OP with Version 2.1 of Engine.log Tool:
- Bug fix: Progress bars were being displayed even if Engine.log Tool was being run silently from another calling macro.
WOW I'm in love, thank you!
1 Like
I've updated the OP with Version 3.0 of Engine.log Tool:
- Streamlined the main dialog, added a Help button, and moved the instructional information to a help window.
1 Like
I've updated the OP with Version 4.0 of Engine.log Tool:
-
If the Command key (⌘) is down when the Console button is selected, a truncated version of the Engine.log will be opened in a configured text editor. Three settings (and default) have been added: local_TextEditorLogEntriesCnt (500), local_DescendingEntries (1), and the text editor (TextEdit) in an Open a File Folder or Application action.
-
If the Command key (⌘) is down when the Done button is selected, a Prompt With List appears with four options:
- Reveal the Engine.log in the Finder
- Save Last Displayed Failure|Timeout to the Clipboard
- Save All Displayed Failure|Timeout to the Clipboard
- Save All Displayed Failure|Timeout to the Clipboard (descending)
- Run 'Engine.log Tool' in Test Mode
- Quit
-
Updated the Help to include the Command key (⌘) options. The Help window is now overlapped slightly to save vertical footprint.
-
Added a setting: local_BoundaryAlert : 0|1|2|3; default 1 : when attempting to go after that the latest Failure|Timeout or before the earliest using the Next > or < Previous, respectively, a audible and/or visual alert can occur.
2 Likes
I've updated the OP with Version 5.0 of Engine.log Tool:
-
Modified the behavior when the Command key (⌘) is down when the Console button is selected (a feature added in Version 4.0):
-
The output file directory was changed from ~/Desktop to /tmp,
-
setting local_DescendingEntries was dropped and setting local_DescendingIsDefault was added, and
-
the Open a File Folder or Application action was changed from TextEdit to Default Application. The Open a File Folder or Application action can be changed to a specific text editor if one wants to override the Default Application.
-
-
If the Command key (⌘) is down when the Reduce button is selected, the delete Engine.log option will be initiated.
-
If the Command key (⌘) is down when the Latest button is selected, a Prompt With List will appear that includes the most recent Failures|Timeouts (up to a maximum of 95). When a selection is made, the main dialog opens with that item displayed.
-
If the Command key (⌘) is down when the Done button is selected, the Prompt With List items have been rearranged:
- Save the Last Displayed Failure|Timeout to the Clipboard
- Save the n Displayed Failure|Timeout to the Clipboard
- Save the n Displayed Failure|Timeout to the Clipboard (descending)
- Reveal the Engine.log in the Finder
- Run 'Engine.log Tool' in Test Mode
- Cancel Macro
-
If the Engine.log doesn’t contain any Failures|Timeout, the process to add one of each has been simplified. Also, the Timeout is now added without generating a notification.
-
Changed local_LogTailCount default value from 1000 to 5000.
-
Added a Cancel Macro option to each of the Prompt With List actions.
-
Updated the Help to include the new Command key (⌘) options.
1 Like
I've updated the OP with Version 6.0 of Engine.log Tool:
-
If the Command key (⌘) is down when the Done button is selected, added an option to invoke the Terminal command tail -F Engine.log.
-
If this macro is run from another macro using the Execute a Macro action (or via AppleScript), and With Parameter is specified, the following keywords have been added:
clipboard : bypass the macro dialog box and save the latest failure or timeout to the clipboard
editor : bypass the macro dialog box and open the Engine.log in a text editor
reduce : bypass the macro dialog box and go to the Reduce Prompt With List
reveal : bypass the macro dialog box and reveal the Engine.log in the Finder
select : bypass the macro dialog box and go to the Failure|Timeout Prompt With List
tail : bypass the macro dialog box and run the Terminal command tail -F Engine.log
-
Updated the Help window.
I've updated the OP with Version 7.0 of Engine.log Tool:
-
Added a new setting local_DialogVariables : 0|1; default 0 : when the main dialog is displayed, the Time, Action, and Description variables will be included. Note that this value can be toggled by holding the Control key (⌃) when the < Previous, Next >, or Latest button is clicked.
-
Bug fix: If the macro trigger includes the Shift key (⇧), the macro correctly recalls the previously displayed Failure|Timeout. (That feature was broken in Version 6.0.)
1 Like
Since Engine.log Tool can be triggered normally or in 15 alternate modes, Alfred is an ideal method to trigger the macro. For specific information, please refer to this post within a tutorial thread that I had previously shared.
Hello Jim (@_jims) 
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 ?!
Thanks for building such great tools
Greetings from Germany
Tobias
1 Like
Hi, @Nr.5-need_input; I hope you are doing well!
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!
Yes, it’s getting better from day to day … thanks
Will do … tomorrow when back home…
Greetings from Germany
Tobias
1 Like
Hello Jim (@_jims)
A first report from me after my first inspection:
-
truly an outstanding Macro - great job
-
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
Greetings from Germany
Tobias
Hi, @Nr.5-need_input. Thanks for testing Engine.log Tool and for taking the time to provide feedback.
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?
The macro actions will not function as expected if the Search field is not visible.
The only thing I'm storing in the jsELT_dict dictionary is the ErrorIndex (1 = latest failure/timeout; 2 = failure/timeout before that, ...).
The dictionary value above is displayed using the invaluable macro, Variable Inspector Prompt and Dictionary Editor, by @DanThomas.
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.
Hello Jim (@_jims)
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.
Bye for now … I’m in a hurry …
Greetings from Germany
Tobias
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.
Are you referring to this action?
Sorry, I don't understand your point/issue.
You're welcome. I use it often.
Hello Jim
About your questions in post #24:
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.
Greetings from Germany
Tobias
Hello, @Nr.5-need_input,
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.app should 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.
2. Suggested macro changes
I addressed this suggested change above in #24.
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. 
Hello Jim
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 …
Thank you and Greetings from Germany
Tobias
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.)
Thanks, @Nr.5-need_input. Best wishes; here's to better sleep! 