I just upgraded my testcomplete to the latest release 15.75 and my very first attempt at recording and then running (playback) is giving me the behavior depicted in the image below. i am recording a click on the document type combo box and the Account text box but when I run (playback) the recording it is clicking on the Tran Code combo box and the Amount text box. Is anyone else experiencing this behavior with the new release?

i edited the name mappings for two objects that were getting incorrectly selected during the recording process so that their properties include the WPFControlName and then re-recorded the keyword test and it successfully chose the correct objects this time. i know i had recorded numerous other keyword tests before now where it didn't need me to manually edit the mappings. who knows how many other properties will get "confused" from here on but, for now, i'm going to just deal with them as they arise. i think something changed that is causing the recording process to look at some properties before others but i can't prove anything.

recorded objects do not equal playback objects

17 Replies

dhundley
Regular Contributor
9 days ago
i edited the name mappings for two objects that were getting incorrectly selected during the recording process so that their properties include the WPFControlName and then re-recorded the keyword test and it successfully chose the correct objects this time. i know i had recorded numerous other keyword tests before now where it didn't need me to manually edit the mappings. who knows how many other properties will get "confused" from here on but, for now, i'm going to just deal with them as they arise. i think something changed that is causing the recording process to look at some properties before others but i can't prove anything.
- scot1967
  Champion Level 1
  9 days ago
  I am glad the "fix it and move on" strategy suggestion worked. I remember being able to set these priorities at one time but I can't remember how I did it. I'll post back if I find it.
  
  👍 I am sure a few likes on the most helpful posts here would be appreciated. 👍
  
  Have a great day!
scot1967
Champion Level 1
9 days ago
This is a reference to a known issue with dpi settings. This may not apply in your case if you are not using things like X/Y coordinates or other methods of identification involving any relationship to the screen size...

https://support.smartbear.com/testcomplete/docs/testing-with/specifics/testing-on-different-dpi-settings.html

I am not aware of any issues with object recognition between Win 11 and Win 10 where objects have been identified using unique object property values unless it is related to the behavior of the tested application (a Win 10 version verses a Win 11 version).
scot1967
Champion Level 1
9 days ago
It would help to have a clear screen shot or a text list of the object propertied used in the name map (for both the correct and incorrect target objects). Also, X/Y clicks can be very flakey especially between different OS versions. Objects identified by unique properties are much more stable. However Win 10 and Win 11 may be changing the indexes or ordinals. Are you able to compare between the two workstations?
scot1967
Champion Level 1
9 days ago

i have on occasion reverted to using FindChild in some situations where i was constantly seeing indexes or ordinal numbers changing from one sign in to the next but, as i said earlier,, this just seems like it would be quite a large undertaking given how big the name mapping repo has become over the years

You may have to manually correct this and move on. That said I have learned over 10 years to avoid using indexes and ordinal numbers. 🫤

would it make any difference that my new workstation is running Window 11 whereas my old workstation (which i used to develop the automation for this application) was Windows 10?

Yes, this could cause a problem especially with record and replay. Win 10 and Win 11 render the screen differently and this can cause problems. I will see if i can find any specific references and send them your way.
- dhundley
  Regular Contributor
  9 days ago
  the check for name mapping updates button did not reveal anything. i'm curious if there is some way to "give weight" or preference to certain properties over others that TC uses to map objects? i believe if TC would favor the WPFControlName property when it has a value rather than the ClrFullClassName and WPFControlOrdinalNo properties then this issue would be resolved. Here is the object browser entry for the object that is getting mapped incorrectly when i am clicking my combo box
  
  now here is the object browser showing the object that it should have recorded. it has the same ClrFullClassName and WPFControlOrdinalNo as the incorrect object but they have different WPFControlName properties
  
  in most cases the Visible or VisibleOnScreen property would also be advantageous to be high on the list of favored properties but wouldn't help in this case because there is a visible object with the name TranCodeComboBox. but again, if the recording had mapped using the WPFControlName when i clicked the object there would not have been an issue.
dhundley
Regular Contributor
9 days ago

no.

not sure if i can do anything about this now. if we had thought to do this several years ago when we started creating this automation, that would have been the time to do this.

yes. i stashed my changes.

i set my options to match yours and attempted it again. no difference.

i have on occasion reverted to using FindChild in some situations where i was constantly seeing indexes or ordinal numbers changing from one sign in to the next but, as i said earlier,, this just seems like it would be quite a large undertaking given how big the name mapping repo has become over the years

nothing that i'm aware of that would cause this type of behavior

would it make any difference that my new workstation is running Window 11 whereas my old workstation (which i used to develop the automation for this application) was Windows 10?
- rraghvani
  Champion Level 3
  9 days ago
  That could be a possibility, moving from Windows 10 to Windows 11. Underlying framework objects, such as .Net may have changed, which may now have caused certain ID's to be different!
  
  In TC, there's a button I had often used to see if any name mappings had changed, that requires updating. It could help you identifying what needs updating?
  
  If your project has been going on for several years, it will be a big job to do code refactoring.
scot1967
Champion Level 1
9 days ago

now, if i go to my namemapping repo for that combo box element, for some reason it is using a combo box from a totally different form/window of my application while the combo box that should have been chosen is a grandchild of a listview (lv) object

I have seen this before. TestComplete is using the first match. Can you post the properties used to identify both objects? Right Click the object and check the namemap and also check the object browser. Compare the properties to see if you can spot the issue.

I can't say why it only started occurring recently. 🤔 Sometimes object identification will be flakey like this if the properties used to define the target object are not unique or the depth from the defined parent isn't set to search deep enough or new objects have been changed or added to the application object tree.
dhundley
Regular Contributor
10 days ago
Here's the latest update. I stashed my changes and reverted back to 15.74 and tried to re-record the keyword test. Same result.

Here is what the keyword test looks like right after i finished recording. focusing on just the combo box you can see what the screen looked like at the time i recorded that line

now, if i go to my namemapping repo for that combo box element, for some reason it is using a combo box from a totally different form/window of my application while the combo box that should have been chosen is a grandchild of a listview (lv) object also shown in the image below

if i replace the namemapping for ComboBox with the name mapping of DocDefCombo then my keyword test works for that line.

and here it is shown in the object browser window

the question i have to answer now is how many versions back do i need to go to see where this issue doesn't exist
- rraghvani
  Champion Level 3
  9 days ago
  Just a few pointers, have you changed the scaling of your Windows settings, as your toolbar seems to be large? This could cause issues when recording your AUT.
  
  Your alias name mapping seems to be huge. You should try to keep the structure as simple as possible.
  
  When you reverted back to the previous version of TC, did you also revert your project back too? The latest version could have made changes to the project, which is now causing issues.
  
  In Options, verify your Engines -> Name Mapping has the correct options selected (these are my settings).
  
  The issue you have described, is what I had experienced when I first started using TC v14. I prefer to always map my objects first, and provide the appropriate properties, so that TC can identify the UI controls without issues. However, I've now moved away from using name mappings and now using the Find method (via scripting). Reason behind this, is because our name mapping is becoming to huge to maintain.
  
  Have your developers made any recent changes to the application?
rraghvani
Champion Level 3
10 days ago
If your scripts were working in a previous version before you upgraded, then most likely the new version has broken it!

It's worth reporting it, if you think it's an issue, via https://support.smartbear.com/testcomplete/message/
catalin_ochisor
Occasional Contributor
10 days ago
Posting the code follwing your actions would help.
scot1967
Champion Level 1
10 days ago

so, the question now is, why did it create new mapped objects which turned out to NOT be the objects i clicked on during the recording.

Did TC use different properties to created the new mapped objects or just name them differently? Post back with the results of your rollback. I am interested in what happened. 🤔