HI jr348,
Will it work if you update the template and run the test with the Update Name Mapping during test run option enabled? You can find more information about this option here:
I don't believe there is... templates are applied at the time the mapping is generated so I don't think you can make that change.
You probably don't have to go quite so extreme to delete and recreate nameMapping. For that matter, this is what "Aliases" do for you... so long as you maintain the Alias as is, you can move and reorganize and redefine NameMapping as much as you want. The automation code references Aliases, not NameMapping.Sys for object identification.
Thanks for that.
The Aliases are OK so long as the name mapping structure does not change too much.
I'm in the process of removing unecessary extended find objects and increasing the number of properties to make our suite more faster and more reliable. Removing extended find means the mapped objects are also in a very different location in the mapping tree. The Alias doesn't seem to work in this case.
It would be good if the Alaises can be orginised in a totally arbritary way and create our own folders/sections.
We've done the "Remove Extended Find" stuff... and you can maintain the existing Alias while correcting that.
For example... let's say you have this.
NameMapping.Sys.MyApp.MyPanel.MyButton
Aliases.MyApp.MyPanel.MyButton
The item in bold has the Extended Find turned on. You can, then, do this.
NameMapping.Sys.MyApp.MyPanel.MySubPanel.MyButton
Aliases.MyApp.MyPanel.MyButton
Where extended find is turned off and the sub panel is inserted. This will STILL work. The Alias does not have to match the mapping in hierarchy so long as the child objects are still in the tree. This is how Aliases are intended to work where you can "telescope" long hierarchies to be more easily utilized.
HI jr348,
Will it work if you update the template and run the test with the Update Name Mapping during test run option enabled? You can find more information about this option here:
