|
Generally, analog automation is limited - e.g. the big problem with macro recorders / screenshot based utilities is "what if the resolution changes, what if the user is using a different OS and that has different button sizes." Screencapture based methods generally suck and are brittle - you can do stuff like try to define the screen capture so it only captures the region of interest, but it's a pain in the rear end. The quickest and dirtiest way of automating windows UI is to get out a program like autohotkey or autoit. Native UIs will generally have something like a "controlid" or a "classname" for stuff like buttons in windows (and you may be able to see that in spy++), so rather than using coordinates, you'll be able to do stuff like "wait for window to exist containing a certain classid, click on button with certain classid" using the autohotkey script itself. If you recognize where the controls are by class, and position the cursor using this object recognition, it will be much more durable than using screencapture based methods. Similarly, verifying results by using screenshots is usually a bad idea and should only be done if there is no other option. Under the hood, many native applications windows support MSAA (https://en.wikipedia.org/wiki/Microsoft_Active_Accessibility / UIA for .NET (https://en.wikipedia.org/wiki/Microsoft_UI_Automation). These apis are intended to help stuff like screen reading software, etc. For whatever app you're trying to automate, automation decision tree is something like: a) Does the app have a COM interface or CLI interface that I can use without loving with UI automation? b) Does app support MSAA / MUI and have class names for the objects? c) gently caress it, are coordinates good enough, or do I want to do some kind of other hack? Vast majority of apps fall under a) or b).
|
#
¿
Jan 4, 2021 15:15
|
|
|
|
| # ¿ May 10, 2024 13:26 |
|