1.2 "Timer Duration" now allows fractional values (i.e. 0.5) 1.1a Fixed a type in the HTML file. 1.1 Added the "Restore Window Focus" parameter. 1.0 Initial Release.
INSTALLATION
Upgrading an existing version:
If you are upgrading an existing version, delete the old macros before importing the new ones. There should be no breaking changes in the new version.
Downloading and Installing:
Download the macros, unzip them, and double-click the .kmmacros file. It will import 3 macros into the group "Display Large Text Notification":
Display Large Text Notification
This is the main macro. Call it as a subroutine.
Display Large Text Notification - Demo
See this macro for some brief examples.
Display Large Text Notification Cleanup
Used internally.
Display Large Text Notification - Reveal Macro Palettes
Hopefully you won't ever need this. Read the comments in this macro for an explanation.
May I ask a question before downloading it? In your example that says "Close and Copy buttons and Timer" did it insert the newline itself, or does the user have to insert the newlines manually? I need to ask because your subroutine includes only one visible line for "Text". Passing a multi line variable is possible in a single text box, but it's not obvious to some people.
Sorry I didn't respond to this earlier - for some reason I didn't get an email notification.
If you specifically want newlines, then I would recommend using a "set variable to text" to set the multiline text, then use that as a parameter. Several of the demos do that.
If the text doesn't fit on the screen, it wraps automatically.
This is a very nice addition to Keyboard Maestro. Thank you!
Is there any way to create a setting that prevents the notification window from stealing the focus when it is displayed? I have a macro that runs continuously and it occasionally calls this macro. If I typing in another application this macro can steal the focus and my typing is blocked and I get error beeps until the Display Text window times out.
I tried to solve this when working with @martin's macro. I am not a html, CSS, javascript expert and could not find a solution.
You're the expert on that action, so I believe you.
However when I want a window to display text without grabbing the focus, I use Display Progress Bar which allows you to display a line of text on a window without grabbing focus. And it's easy to close programatically, as well.
Barring an "official" solution, I've had a quick play and immediately preceding your "Custom HTML Prompt" call with this async AS action may solve the problem:
tell application "Keyboard Maestro Engine"
try
set startWinID to id of window 1
on error
set startWinID to 0
end try
set winID to startWinID
repeat until winID ≠startWinID
delay 0.1
try
set winID to id of window 1
on error
set winID to 0
end try
end repeat
do script "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
<!DOCTYPE plist PUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\">
<plist version=\"1.0\">
<array>
<dict>
<key>Action</key>
<string>SelectWindow</string>
<key>MacroActionType</key>
<string>ManipulateWindow</string>
<key>TargetApplication</key>
<dict/>
<key>Targeting</key>
<string>FrontWindow</string>
<key>TargetingType</key>
<string>Front</string>
</dict>
</array>
</plist>"
end tell
Demo -- change hot key to something unique, run with a window in another app active:
Note that palettes are also engine windows, which is why this needs a unique trigger to avoid the Conflict Palette. There might be a way to work round that if it's an issue.
Logs the id of the frontmost Engine window (0 if none present), and when that changes (new HTML prompt [or, grrr, palette, etc]) sends the KM "activate front window of front application" action to bring your "working" window back into focus.
I added this script call and it does help considerably. I reduced the delay to 0.02 seconds (not sure if this actually helps). I can now be typing in a separate application with multiple rapid asynchronous calls to "Display Large Text Notification" occurring. I still get occasional beeps when this occurs but focus always returns very quickly to the app where I am typing.
The smaller the delay, the more frequent the check for the arrival of the HTML Prompt. The more frequent the check, the quicker focus will be returned to your active window. But the more frequent the check, the more OS resources devoted to doing the check.
So it's a balancing act -- make the delay as short as you can, but not to the point where it impacts the other things you are doing.
