This is just an example, mind you. If you want to use an external file to store the specifics, that will work along with this, you'd just need to structure that file to be able to read the data in and use it appropriately. The example I have here is hard-coding the strings but it should, I hope, demonstrate the concept. The documentation for the FindChild method can be found by clicking here.
Let's say that I have an application with a form. On that form is a button for saving the data on the form. I want to find that button and click it. It would look something like this.
function findChildExample(){
var myApp, myForm, buttonSave;
myApp = Sys.Process('myApp');
myForm = myApp.FindChild(['class','Caption'],['form','Data'],2); //FindChild will find a child object up to two descendants deep with the class 'form' and the caption 'Data'
if (myForm.Exists){ //if the form is found
buttonSave = myForm.FindChild(['class','Caption'],['button','Save'], 2); //FindChild will find a child object up to two descendants deep with the class 'button' and the caption 'Save'
if (buttonSave.Exists) {
buttonSave.ClickButton(); //Click on the button if it is found
}
}
}
This is just an example, mind you. I'd probably separate things out into a POM of sorts. If you want to use an external file, you could use something like an XML or a CSV file to define your objects you want to work with, giving each a name designation and a set of properties and values to search for. But... in truth, I see this as re-inventing the wheel. The NameMapping/Aliases structure of TestComplete already does a lot of this. If you are deliberate and careful in the properties you use for mapping your objects, you shouldn't need to edit your mapping frequently. And, even when you do, there's only one point of contact to do the edits to make sure that the rest of your automation continues to work.
One item of note: I do, even though I use NameMapping, use the FindChild method to find things. On many forms and pages in the applications we are testing, there are tables of dynamic data. When we add a new data record into the application, a new row with new cells is added. But that data is not guarenteed to be there every test run. The table is, but the data rows may not be. So, we map the table as a "static" object... but we use FindChild when we need to find a particular cell within that table with particular contents. I think you'll find that most folks utilizing TestComplete's NameMapping feature end up using a similar hybrid structure where static application components are mapped but dynamically generated data components are "found" using FindChild.
