in reply to Assist human unobtrusively in a 3rd party Windows GUI

While it's not a "test the GUI" application, Win32::GuiTest probably holds the answer. Using Win32::GuiTest you can dig through windows and dialogues, see controls (including buttons) and poke stuff. Seems like exactly what you want.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
  • Comment on Re: Assist human unobtrusively in a 3rd party Windows GUI

Replies are listed 'Best First'.
Re^2: Assist human unobtrusively in a 3rd party Windows GUI
by Corion (Patriarch) on Dec 13, 2020 at 07:04 UTC

    To expand a bit, Win32::GuiTest includes the spy.pl and spy--.pl scripts, which dump the structure of available windows. If you can find the "RESET" button through this, you can automatically click it and then restore the focus to the original window. My advice is to not send mouse clicks but to use keyboard navigation/hotkeys or to send window messages with the ID of the target control to activate it. Be sure to log all the actions of your assisting program to a file so you can find what situation caused the program to act unexpectedly, later.

    If the application does paint its own controls, such as to have "fancy" buttons (for no good reason), you will have to take screenshots and compare the screenshots, which also can work but is fragile if the font or screen scale changes.

    Another low-effort thing to try is AutoHotkey, which has its own quirky programming language. I wouldn't want to write any form of logic in it, but if AutoHotkey can do it then you can later replicate the mechanism AutoHotkey uses with Perl.

[reply]
[d/l]
[select]
      My advice is to not send mouse clicks but to use keyboard navigation/hotkeys or to send window messages with the ID of the target control to activate it.

      I am not sure what you mean by this? We (my fellow users who are affected by this) have not been able to find any kind of keyboard sequence that would have the effect of clicking upon this button. If we had found such a thing, then I could push a keyboard button to send a keyboard macro. Pushing a single keyboard button would be less terrible than it is now (move hand to mouse, move cursor to "reset", click it, move cursor back to original window, click, put hand back on keyboard). I suspect that you are telling me something about the GUI_Test UI that I don't understand. send window messages with the ID of the target control to activate it sounds like what I need to do.

[reply]

        Ooof - if the application is not accessible in the sense of being navigable by keyboard alone, then yes, you will need to send mouse clicks (or window messages of the type WM_CLICK).

        If you can find the control ID of the button (using the spy.pl program), you can make your click-sender somewhat more resilient by sending the window message to that control, otherwise you need to send it using x/y coordinates and need to hope that nothing changes the layout of the window (font choice, font size, zoom/scaling settings, ...)

[reply]
[d/l]
[reply]

In Section Seekers of Perl Wisdom