I have an AppleScript that does some window manipulation. I've been calling it like this:
set var winXCenter: ROUND(SCREENVISIBLE(Front,MidX))
set var winYCenter: ROUND(SCREENVISIBLE(Front,MidY)+100)+8
etc
call AppleScript macro as "execute macro," passing nothing but having the global vars available.
But it bugs me having to set five variables, then pass those variables to the AppleScript macro, then clear them later. What I'd prefer to do is this:
Then, within the subroutine, I want to set my variables to the outcome of those calculation strings. Is this possible? I tried this:
set var winXCenter: %Calculate%zzRGtemp_Xcenter%
But that fails to calculate. Is there any way to calculate the result of the calculation in the passed string?
-rob.
Yes, definitely. Here is one way to do this (when the calculation is in a Calculation field). The text in bold is the Variable containing the calculation string.
CALCULATE(%Variable%LOCAL__Xcenter%)
Calculate Contents of a Variable.kmmacros (3.5 KB)
Can you describe what you're trying to do with your macro? Is there a reason you don't want to use the native Manipulate a Window action?
When I wrote the macro, you couldn't use that action to manipulate an input prompt window—once that window is onscreen, all other input is blocked. I believe that still to be the case, hence my issue.
The AppleScript, which @cdthomer wrote for me, works around that by setting the window size for the window based on its title, even though the window isn't there yet, then waits for the window to appear.
I call the AppleScript asynchronously, and it just sits there waiting for the input prompt to appear. When it does, it moves and sizes it.
-rob.
1 Like
I see. Which particular input prompt are you trying to act upon?
Aha! I was trying it the other way around. Works perfectly, thank you!
-rob.
1 Like
Actually, what you were doing would work fine if you were in a Text/Token field. For fields with the little "C" on the right hand side it is:
CALCULATE(%Variable%LOCAL__Xcenter %)
And if you were in a text/Token field, with the little "T" on the right hand side it would be:
%Calculate%LOCAL__Xcenter%
(Which is what you were already trying.)
I only know this because I was trying to work out something similar this morning.
What makes this very useful in Calculation fields is that the Maths can be extended so, you can do something like this:
CALCULATE(%Variable%LOCAL__Xcenter%) + 345
1 Like
Prompt for User Input is one case, the other is when using Display Text in a Window. As far as I know, those windows are also invisible to the Manipulate a Window action.
They have a window title ("Keyboard Maestro - Display Text"), but they're not owned by any foreground application. I also tried setting the owner to Keyboard Maestro Engine, but that also fails:
The error message in the log is:
2023-10-16 09:28:17 Manipulate Window could not find any matching windows in macro “Center next engine window test” (while executing Resize Window Named “Keyboard Maestro - Display Text” to Pixels).
The only way I was able to manipulate these text windows (which I use for instructions, etc.) was via Chris' AppleScript.
-rob.
1 Like
Hey Rob, I’m thrilled my AppleScript has worked so well for you. FWIW though, KM10 introduced a new action: Set Next Engine Window Position, that allows you to position those two items natively. You might want to look into using it, since it works better than my AppleScript. I’ve actually deprecated that AppleScript in my personal macros in favor of this new feature.
I'd actually moved to that for 95% of the window moves in the macro, but I have one particular one that's giving me trouble—it involves an input prompt and a text window, and the input prompt is then redrawn after the text box appears. But I'll play around with it some more, as this was the last spot I was using the script.
-rob.
Also, the new action can't position macOS windows, like the Open or Save dialog, right?
Edit: I also still need your script for its other functionality, which is to watch and wait for a window to appear before then raising it—this is the only way I can get the input prompt to have focus again after opening my help window.
-rob.
Am I missing something? This seems to do what you're after:
I must've been doing something wrong, it's working now. I do still need the bit of the AppleScript that watches for a window and raises it once it's present, though.
Thanks for all the help, everyone—the move/size portion of the AppleScript has been banished from the code.
-rob.
Again, am I missing something? The above example sizes the next window.
You are, but it's specific to my macro. I display an input prompt, then open an HTML input form behind it, then redisplay the input box after removing one button.
But the HTML input form winds up with the focus, not the input box (which is floating above the form). I can position the input box all I want, but I can't make it active without the AppleScript.
Without the AppleScript, the "Find matches" box on the HTML form has focus, and you can't type without first clicking in the input box.
-rob.
1 Like
