Forum Discussion

chainmailguy's avatar
chainmailguy
Occasional Contributor
9 years ago

Incorrect Targets Identified in Record/Playback of Keyword Scripts

Using TestComplete 11.20 with Windows 8.1 I'm finding that keyword tests that are recorded with an XY component are not being correctly targeted as shown in the Test Visualizer after recording or playback. Sometimes the recorded Visualizer images are correct, sometimes not. There seems to be an XY offset applied to the coordinates that is repeatable, but incorrect enough to make the tests click in the wrong place.

 

Specifically the issue occurs when I try to check the checkbox of an Infragistics UltraTree control with the clickItemXY command. May also occur with other XY-related commands but this remains untested.

 

- Issue occurs on VM and physical machine.

- Issue occurs with a repeatable XY offset

- Issue does not occur with commands that do not use XY coordinates

- There are no commands available to me that will check or clear a checkbox without using XY (ie. cbCheckItem does not work with Infragistics controls)

- The project will not be modified to us a non-Infragistics control

- Changing window size or screen resolution does not affect the issue

- Faking out the clickItemXY command by manually calculating in the offset is a non-option.

 

 

What am I missing?

 

clickItemXY
infragistics
XY
  • chainmailguy's avatar
    chainmailguy
    9 years ago

    It seems the problem *was* resolution-related.

    When setting screen resolution in Windows there are 3 things I can change: screen resolution, pixel height for groups of items, and a slider for adjusting screen object size. The slider was set to a non-default value, which caused TestComplete to improperly locate items on record and again on playback.  Resetting this slider to its default value and restarting the machine fixed the issue.

     

     

  • Colin_McCrae's avatar
    Colin_McCrae
    Community Hero
    9 years ago

    Faking out the clickItemXY command by manually calculating in the offset is a non-option.

     

    May I ask why?

     

    I have a Delphi custom tree control and I have to work out the co-ordinates of the checkboxes to use it properly. The custom code (in the tree control) looks for a click on the tree object (NOT the node, the parent tree object) and it's this click that triggers the custom code (which triggers checks up and down the tree for partial selections of a full node).

     

    To do this, I have to find the node, grab it's "RECT" (from memory) property. This contains left/right/top/bottom co-ordinates (sub properties) which give me the relative co-ordinates to apply the click to the tree object. The Node object does not have a "Click" method (also going by memory here) so I have to do it this way.

     

    Same with some grids.

     

    It's not nice I admit. But there is, literally, no other way to do it. As long as you are in control of the co-ordinates (which you can be) then they are OK as a last resort.

     

    Also - the recorded clicks with co-ordinates, I'm not sure what their position is relative to? The parent object, the screen, not sure? But the point is, are you 100% certain the application opens in exactly the same position, at exactly the same size, when you open it via your test? (Again, position and sizing is something I control in my scripts for exactly such occasions.)

     

    And if someone runs your test on a machine with a different monitor, or at a different resolution (or anything else that alters the scaling), is it not doomed to failure with hard-coded co-ordinates? At least if you calculate them properly in script a resolution change will not break your test. (If you set it up right.)

  • chainmailguy's avatar
    chainmailguy
    Occasional Contributor
    9 years ago

    It seems the problem *was* resolution-related.

    When setting screen resolution in Windows there are 3 things I can change: screen resolution, pixel height for groups of items, and a slider for adjusting screen object size. The slider was set to a non-default value, which caused TestComplete to improperly locate items on record and again on playback.  Resetting this slider to its default value and restarting the machine fixed the issue.

     

     

    • Colin_McCrae's avatar
      Colin_McCrae
      Community Hero
      9 years ago

      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 ......

    • mes6073's avatar
      mes6073
      Contributor
      9 years ago
      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.