Incorrect Targets Identified in Record/Playback of Keyword Scripts

Which is fine.

You now have a working, but fragile, test.

If someone else does something to alter the scaling (or you forget to adjust your slider) or they change the size/shape of the control. Or alter it's position within the parent control, your test is going to break again.

As a general rule, hard coded numbers = bad. Hard coded co-ordinates = very bad. (There are some controls where you have little choice but to use co-ordinate based actions, but even then, you can usually calculate rather than hard-code.)

It may work now, but if I was code reviewing that, I'd reject it and have it calculate them properly.

Just sayin ......

---

chainmailguy wrote:

there are 3 things I can change: screen resolution, pixel height for groups of items, and a slider for adjusting screen object size.

 

---

As already mentioned, hard coded X,Y coordinates are rarely portable to different platforms for exactly the reasons you have already discovered. While hard coded X,Y coordinates are typically not recommended, there are some avenues available that will help mitigate risk. One suggestion would be to leverage the Window object 'Position' action to set the size and position of a top-level window or MDI-child window in combination with the DotNet Screen.PrimaryScreen property which returns an object containing properties relating to the screen resolution - 
Set screen = dotNET.System_Windows_Forms.Screen.PrimaryScreen (see Width Property (Desktop Objects for more information) - to then programatically define X,Y coordinates that conform to the current screen resolution of the system under test.