I am having an issue where when I run the same macro containing specific move and click locations, more than once in a row, it usually does not end up clicking in the correct location and instead clicks a bit away from where the click is supposed to occur. This mostly happens in floating windows within Digital Performer. I am identifying the windows in the macro and always setting up a relative click location to one of the corners of the window. I am pretty confident that the macro is aware of the window it needs to be clicking in because it does not matter where on my screen the window is loacted, it is simply not finishing in the right location consistently. I AM able to run the macro two or more times in a row it seems, if I interact with the application a bit by dragging around the window or clicking in various parts of the windows. If I simply shake the mouse cursor, that is when the next time I run the macro, that it is NOT successful. I made a screen recording to demonstrate the issue that is affecting me in a number of macros that I am frequently using and not getting consistent results from. At 2:10 in the video, that is where you will see the click not arriving in the correct location. I have also included the macro itself.
Thank you for any help that can be provided.
I looked at your code and tried to figure out why it happened. I couldn't see the reason, but maybe you will be just as satisfied with a fix, instead of figuring out why it happened.
My idea for a fix is to stop using "relative to the front window's centre" and start using "relative to the found image's centre". And then use the following image (you will have to copy it yourself, not use the copy below)...
If you move the mouse relative to this image, instead of relative to the centre of the window, the chances are pretty high that you will end up working. (If you use relative to the found image's centre, you will probably need offset coordinates of about 20, -30, but that's just a guess.)
I'm still perplexed and curious about why it's happening. I can't see any reason for it yet, but there's a high probability that the change I'm offering you above will fix your problem.
Thank you for your advice on this issue. I have VERY successfully used the click-at-image option in numerous other macros. It has worked very well, even with the very small aspect of graphics in Digital Performer. Using the move and click is so much quicker and was hoping to use that but this is where we are LOL. It's just so odd that when it's not hitting its target, it's off by what seems the same amount.
Some apps have good visual handles for using "relative to found image." I picked that green block from my personal experience using it.
Quicker than finding an image? Finding an image is extremely fast. Considering that you have lots of Pause actions in your macro, Find Image won't impact you at all.
I stared at your video and your macro for over 10 minutes. I could not see the cause of the anomaly. I'm not sure what to do. Perhaps we need to wait for someone else to examine it. But I'll take one more look and let you know if I see anything.
By "Quicker" I was referring to the programming trial and error time. Not the timing when the macro is running. There is alwyas a bit of tweaking with image selection, especially in my case where I often , but not in this case, have to provide the image both un-selected and when it's selected and is colored differently.
Rats, my theory had good rationale. You see, you have lots of Pause actions. I was suspicious that when your macro was failing, it was because you had two copies running at the same time, and one was interfering with the other. My suspicions were enhanced by your claim that it happened only when you didn't "do other things" (which take time) and that suggested to me it was a timing issue caused by multiple copies running at the same time.
In any case, even if this wasn't the cause of the problem, you probably should keep the semaphore lock to prevent two copies from running at the same time.
Yes, that is what I meant. KM and Spaces don't work well together because Spaces doesn't have a documented API for apps like KM to access. I'm not saying that Spaces is likely to be the culprit, but if I were in your situation I would definitely test this macro after disabling all your desktops. Another thing I would do if I was you was disable the second monitor and move your app to the first monitor (along with modifying your macro to use the main display.) Debugging is all about eliminating possibilities, and since I don't have your apps, your hardware or your configuration, this would be up to you. If I had your setup, I would be testing this out, even if the chance that this will fix it is only 10%.
Or you can just live with the workaround I gave you and not worry about finding the cause.
Or you can wait for someone else to chime in. The choice is yours. I'm just trying to help.
Thank you for all of these suggestions.
The hoops I had to jump through to get the Mac is to commit certain apps to ONLY exist in certain spaces was a nightmare. Very unintuitively implemented. So I won’t be undoing what I have setup LOL. Also, I have a third display too
I’ll go with the image detection but feel like there is something software wise with this behavior. KM is clearly seeing the floating widow since I can locate on any of my displays—but why it’s coming up a centimeter from the target is baffling me.
Thank you again for all of the insight you’ve provided!!
If you watch the video closely, look at the actual position of the window - each time it is opened it is moving up 20 or so pixels (basically the size of the title bar).
My guess is that that move is what is causing the problem, that it is saying it is in one place, but then moving the window.
I looked at your macro, but I don't actually know which click is the one that is going wrong so it is hard to make a specific suggestion. Especially since your clicks appear to be relative to the center of the window, which would be similar places for both the main window and the panel window. You say "click relative to the bottom right corner of the window", but none of your clicks are relative tot he bottom right corner in the macro you posted.
Obviously, ensure that there is a large enough pause for the window to have appeared and to be in the final place.
I would try logging the window position (FrontWindowFrame), or having the mouse move to the top left or bottom right corner of the window and see where that actually is, maybe use the Highlight Location action to indicate the locations.
But my guess remains that the issue is related to the window moving position each time it is opened, or failing that that the front window is considered to be the main window not the palette window.
Note that the main window will generally be the window with the text focus, or the main application window, so if the palette window does not have keyboard focus, that may affect whether Keyboard Maestro considers it to tbe the main window.
I think you might have caught the issue!!
I made MOTU aware of the window creeping up the screen with each subsequent opening...I wonder if its movement is kind of non-standard and so the mac thinks the window is where it last was...since it wasn't moved by me the user, and that is why the click target is misaligned.
Regarding the bottom right vs the center of the window. I changed it at some point when troubleshooting the issue so perhaps I wrote something after I had mad the video.
This is why I was asking you about Spaces. Using Spaces causes pop-up windows to appear in different places. But you declined to test my theory, so I dropped it.
Hi-
It is only the audio and midi plug-in window in my program, Digital Performer that is having the vertical window “creep”.
I tried many other types of windows in that program and they all stay anchored in their location. But the Audio Plug-In windows are not staying put.
I think this may be a programming issue with Digital Performer and will follow up if I am able to confirm
Now you know the root cause, try changing back to "relative to bottom-right corner" for that particular click action -- the window looks to be fixed size so you should always be clicking in the same place in that window.
That depends if the post he wrote was implying that the problem went away, but I interpreted the post as saying "I think you may understand why it's failing." If I'm correct, then switching to the lower right corner won't help.
Hi all-
Switching to click at image is the solution for now. There is an issue with the window in the app I’m using creeping up the display with each subsequent opening of that window. Keyboard Maestro isn’t seeing the window move or that window is not reporting its actual position such that clicking relative to ANY corner of the window is not working.
