Could someone explain why certain objects change periodically when running tests. I have multiple apps that we run tests on so there are times a few weeks go by where we do not run particular tests. I run into a problem where the top level objects are recognized differently when I go back to run them, so I get the "Unable to find the object WPFObject("HwndSource: ShellWindow") error.
The script defines this as:
Object browser shows it now as:
WPFObject("HwndSource: Shell", "Entity Page")
It seemed at first a minor nuisance but now it has become a standard practice of having to change these each time we go back to run the scripts after time. No new builds have been applied so I dont know what would cause it to identify it differently. We do not use NameMapping, we define the objects in the scripts and use Find/FindChild to search the pages. The other strange thing is it is only the HwndSource object that changes. There are sometimes ten levels of objects below them that have never varied from the initial recordings.
A quick search of the help for WPFObject and related topics returns the following:
[ QUOTE ]
In fact, different implementations represent two different models: addressing by an object’s name and addressing by a class name, accessible name (or caption) and index. The model that TestComplete uses depends on the Use native object names for TestComplete object names project setting. Addressing by name seems to be more convenient, but it cannot be used if an object does not have a name defined in the application code, or there are two or more objects of the same name. Addressing by class, caption and index lets TestComplete’s engine uniquely identify an object, but it makes the script lines longer and less readable.
[/ QUOTE ]
It's entirely possible that you're running into some sort of conflict where there are two or more objects sharing the name in your application in which case using the class/caption method of identification is more reliable. I'd suggest altering your code to use class/caption.
In the meantime, I'd suggest also you investigate using NameMapping and aliases as it does simplify your code a lot and makes finding and manipulating application objects much more reliable.
Thanks yes I am aware of that in the help. This is why we use Name to identify, unless I am wrong in thinking the Name property that TestComplete displays in the Object Browser is pulled from the application code Name that the help refers to? My concern is why does TC start to use the class, caption, index when I have the projects set to use Name. The object in question is the main application window off of Sys.Process so I'm not sure how it could think there were multiple instances of this object and switch to the new recognition method. I could see it with pages with a ton of controls but this is the main application window.
I have tried NameMapping on other apps and have spent most of my time maintaining that from build to build so that is why we dont use it, I never found it was stable enough and we spent a lot of our time updating that rather than writing scripts.
The name is used from the application so long as it is explicitly called out in the application AND so long as there aren't two objects generated that have the same name. The project may be set to use name, but it only uses name if it is possible to uniquely identify by name. I've seen situations where, in my AUT, the name was either not explicitly called out by the developers or they duplicated the name in which case other criteria is necessary.
This is what I think TestComplete is doing. It's possible that there aren't two objects with the same name but, if during the processing of TestComplete's script execution one is in the process of being destroyed while another is being instantiated, this could cause a similar condition.
As for NameMapping stability, I've never run into that kind of problem so long as the application under test is not going through major re-writes of the hierarchy and component structures. Once your app development reaches a more stable state, NameMapping is a life saver...