Ever since the Sonoma update all my window manipulation macro's have been behaving erratically. I know about other threads where that is being discussed and possible workarounds like repeat loops suggested, but they're not really working.
So I wanted to try something else: capture the screen dimensions first in variables, and then move/resize to those variables, to see if that makes a difference, but I'm doing something wrong:
You only need to tokenize variables in Text fields. Coordinates are entered into Calculation fields, so you can remove the tokenization and simply enter the variable names.
I know, but I was testing if the SCREEN function was part of the problem of the erratic window behaviour I've been experiencing since Sonoma (and never before). So I wanted to calculate the dimensions beforehand and then apply those. But to no avail.
I believe there has been another thread about this subject, which I can't find right now. I have erratic behaviour also. But it is temporarily fixable by modifying your macro. If you put your macro into a loop that repeats the action like this:
Yes, this results in the window moving several times until it reaches the full window size. But it seems to solve the problem for now. At least for me.
Thanks for the compliment. I think the problem may be that The Architect doesn't have Sonoma installed yet on his development Mac and therefore hasn't experienced this issue.
And as solutions go, this one is kinda funny because it makes the window "dance."
It is not a Sonoma issue - it is a macOS bug that sometimes animates the changes, and that when animating the window size changes does not handle the size being changed while the position animation is in progress (or vice versa). It long predates Ventura, but when it happens may be more or less prevalent in different applications and different versions of macOS.
Keyboard Maestro 11.0.2 resolves it by slowing down the change so that the move happens and then 0.3 seconds later (after any animate) the size change happens. This is reliable (hopefully) but unfortunately slow.
I cannot do the equivalent of the until loop that @Airy describes internally (I tried!) because if I keep a reference to the window, then the system lies to me about the position/size of the window, and if I were to refind the window (as Airy’s action effectively does) each time and if the front window were to change while that resize is happening, then the action will start acting on the new window. You could see this using the action that Airy posted by triggering the macro and then as it is resizing change the front window. With timing, you'll get the first window partially changed and the second window changed fully.