If the target application is in the background in the moment when the image is found, then you might need two clicks: one to bring the app to the foreground, a second one to actually click the image.
(Some applications receive clicks when in background, others donβt.)
If this is the case here, the just put your Click action inside a Repeat loop, and maybe throw in a very tiny pause.
The button click problem has been reported numerous times. Most
of the responders to the reports had experienced the problem
themselves. When I first had problems with button clicks, I
searched and found previous cases. The cases were either unsolved
or had very complicated workarounds. The workarounds differed. I
used QuicKeys for eighteen years, and I can't recall a single case
of not being able to click a button within a macro. KM has
something inherently wrong with button clicking.
Macros are supposed to save time. Looking through my macros to
find the ones that needed button click workarounds will not save
time. For what it's worth, my fixes were to use the Applescripts I
posted or to avoid the button altogether by using a sub-menu item
or a different approach that generated a different window that
could perform the same function with a different button that KM
could click. For example, many of the items in Thunderbird's
preferences window can also be accessed via Account Settings, and
the windows and buttons are quite different. KM might not be able
to click a button in the Preferences window but have no problem
with a similar button in the Account Settings window.
Something else of note. Apple can prevent buttons and menus from
responding to anything but true mouse clicks. Screen Sharing is
the best known case. Screen Sharing also prevents the creation of
keyboard shortcuts. I can't imagine third-party application makers
deliberately blocking "clicks" from macros, but I suppose it's
possible.
Your post taught me something I didn't know, about an alternative to the button click action, so thanks.
Yes, I too have noticed anomalies in KM's behaviour, including the mouse. I make a list in a macOS Notes file and occasionally I dip into that list and post a message on this forum from my list. But even in those cases where KM is behaving improperly I just find my workaround and live with it. That's one off the beautiful things about programming, i.e., the computer is never frustrated that it's having to perform "workaround" code every minute of every day. So even in those cases where KM is defective, I don't feel the need to gripe because there's always a workaround, and there's a decent community here who can help you find it.
Although I'm aware of all of the input, something has come up, and I'm not going to be able to re-engage until Monday. I appreciate all of the help, and don't wish to appear as though I've dropped off the face of the earth.
One quick response: The page in question is part of the FACTS (previously RenWeb) SIS (Student Information System). You can't get to the page without login credentials. So direct testing is not an option. But thanks for being willing.
Since multiple people are now involved, and since I don't wish to end up wasting everyone's time with something that turns out to be a stupid assumption about something that I thought to be irrelevant, but which a more expert user would see to be a fatal error, I'm going to step back and be extremely pedantic.
The context is the web front end to a student information system built on an MS SQL database. It's behind a login screen, and cannot legally be accessed by people who are not employed by my organization.
I use "click on found image" triggers elsewhere in my interaction with this database. Most of the time, they work as intended.
The physical context includes a MacBook Pro laptop and an LG Ultra HD monitor. The latter functions as my main screen. The former functions as my second, reference screen. For example, as I'm working this problem, Safari is open on the main screen, and is where the action happens, while the KM Editor is open on the adjacent laptop screen. So, I try to be meticulous about specifying screens in my macros. I've considered undocking while troubleshooting this problem, but paradoxically, that would introduce a variable that would be absent from the operational context (and would also be tedious).
I've created a new test macro that contains only the actions related to this problem.
I've assigned a hot key trigger, rather than triggering it from the KM editor, to avoid the issue of whether the target app is actually active when I trigger the macro (especially given that the KM Editor is on a different screen from the browser).
In my test macro, I created a "click on found image at absolute position" action, and it worked correctly, which proves that the image does function as a button, and that KM is capable of clicking it. Of course, I can't use absolute position routinely, because the location of the image varies slightly depending on the position of the browser window.
I took a fresh screenshot of the image, and replaced the single step in the test macro with a "Find image on Screen" (main screen) action, with Display enabled. When I triggered the macro (from the active browser window on the main screen) it briefly highlighted the button in green, and threw no errors.
I added a "Click on Found Image" step
... and it worked.
ARG! Normally, I am happy when things work, but the euphoria is dampened by not knowing why it works now, but not before. I will now add one action at a time to my test macro until it either breaks, or my test macro becomes my fully functioning operational macro.
I want to thank everyone who helped with this. From my perspective, it was not a waste of time. If nothing else, I now have a better understanding of variables. And clicking on found images is an action that I must use throughout this interface. Time honing that procedure is well spent.
I'm not sure if you problem has been completely resolved, but in rereading your OP, it occurrs to me that you may be encountering the same KM design flaw that I did.
The design flaw that I recently found is that the current (as of KM 8.2.4) Pause Until Action has a design flaw that does NOT allow you to identify which image was found, and, even worse, does NOT always return the proper FoundImage token, WHEN you have multiple Found Image Conditions, and you want to match the first one that appears.
If you are still looking for a solution, then this macro may help:
Developments at work have pulled me off of this project for a few days, but I will explore this when I return to it. Thank you (and others) for your input. This is a remarkably helpful forum.
Hmmm. I've run across a variant of this problem in a different context. I created Click at Found Image macros to allow me to use the keyboard to switch between mailboxes in Mail. The macros all worked as expected, then failed a few minutes later. The image on my Desktop had changed, which subtly changed the color in the Mail navbar. I went to System Preferences > Accessibility > Display and enabled Reduce Transparency. Now the macros work again. I think that the translucency of apps in Mojave may be messing with macros that depend on found images.
Another issue, with Mojave+, is OS and/or app theme. Obviously images can appear differently in Mojave Dark mode than in Light Mode. Some apps/web pages autodetect/adapt, others don't. Chris, I wonder if @CJK's method of getting/setting Sys Pref would work with SP > General > Appearance? Or might there be a KM token for this, @peternlewis?