Mapping FindChild object to Alias?
I have a popup window in a Desktop app that script recording creates an alias for automagically. However, playing the script back doesn't work because it fails to find the popup object on subsequent ...
Forum Discussion
Maybe I'm missing something here, but I'm not really seeing the benefit?
You can assign an alias to an object in your code whenever you want. If it doesn't exist, and you try and do something with it, that something will fail.
In my book, you should always sys.refresh before trying to do something with it.
And you should also check it exists/is visible/is active, before trying to do something with it.
So assign the alias but use helper functions to check check existence/availability before using. I don't really see how a function that seaches your entire application (and the search criterea could get VERY complicated depending on your application and how the controls are named/set up. No way I'd get away with simply searching for a name!). Plus, searching the entire app every time you want a control is horribly inefficient in an application/site of any size.
Personally, I use a combination of mapping, & aliases (hugely condensed to more closely resemble how the application actually looks to the user) along with helper/finder functions. I map/alias to a fairly high level (say - page/tab sort of level) and then use helper functions to find the detail.
Works well for me and my maintenance is minimal.
"I use FindChild quite a bit to patch up a broken automation until I can get around to fixing the name map"
Exactly the problem! "Broken Automation due to namemapping". This is the problem we are avoiding.
On Paper it sounds good.. and if your app is like Calculator where it all names itself nicely.
Here's an example of a dev express control's Fullname:
Sys.Process("MyApp").WPFObject("HwndSource: root").WPFObject("root").WPFObject("Grid", "", 1).WPFObject("FloatingContainerBorder").WPFObject("Grid", "", 1).WPFObject("FloatingContainerBody").WPFObject("border").WPFObject("Grid", "", 1).WPFObject("PART_ContainerContent").WPFObject("Grid", "", 1).WPFObject("DockPanel", "", 1).WPFObject("dockLayoutManager").WPFObject("spreadUserControlLayoutGroup").WPFObject("spreadUserControlLayoutPanel").WPFObject("DockPanel", "", 1).WPFObject("spreadLadder").WPFObject("gridControl").WPFObject("gridView").WPFObject("HierarchyPanel", "", 1).WPFObject("RowControl", "", 22).WPFObject("CellsControl", "", 1).WPFObject("LightweightCellEditor")
Here's how it namemapped itself:
Aliases.MyApp.Spread.root.Grid.FloatingContainerBorder.Grid.FloatingContainerBody.border.Grid.PART_ContainerContent.Grid.DockPanel.dockLayoutManager.spreadUserControlLayoutGroup.spreadUserControlLayoutPanel.DockPanel.PriceLadder.spreadLadder.gridView.HierarchyPanel.RowControl.CellsControl.LightWeightCellEditor
Here's how it looks with FindChild:
Sys.Process("MyApp").FindChild("Name", "WPFObject(""LightweightCellEditor"")", 99999)
I'd take FindChild ANY DAY OF THE WEEK over the other two methods for multiple reasons...
1. It is much more readable and concise when sifting through code. It's insane to try to manage all those in-between objects.
2. When (not if) the grid object system (DevExpress in this case) gets updated, it ALWAYS changes the fullname somewhere in the middle. This in turn breaks the name mapping. Imagine now I have about 50 mapped items, and while some might figure themselves out when parents are fixed, most do not because the changes are later in the object string. With FindChild, I rarely need to change anything because it only care about the beginning and the end, the rest is dynamic.
3. It always gets the "latest" refresh on demand so if the properties have changed within the app, like color or data, it will automatically grap the latest data when I do the lookup.
4. There is surprisingly little to no performance difference between namemapping and doing live lookups. This shocked me the most and when I saw how fast it was I've never looked back.
Namemapping is a no-go for our testing because of the extreme length of object names and volatility of the changes. One slight change anywhere in the fullname will break far too much. I am surprised this doesn't affect more people.
Using my Accessor function above, I can simplify it more by giving a nickname to that FindChild call. In this case the obvious name could be "LightweightCellEditor". Granted that may be too generic as there will be other grids that will also have this name, but this was just an example. Usually for similar objects there is one identifying factor that makes it unique. For example, 2 buttons that are side by side:
Set BuyButton = standaloneWindow.FindChild("NativeClrObject.Name", "buyButton", 999999)
Set SellButton = standaloneWindow.FindChild("NativeClrObject.Name", "sellButton", 999999)
Sometimes you even need multiple FindChild calls in one line as there may be 2 grids that use "gridControl" but somewhere in the middle, their parent wrapper is unique:
Sys.Process("MyApp").FindChild("Name", "ordersUserControl", 9999).FindChild("Name", "WPFObject(""gridControl"")", 99999)
Sys.Process("MyApp").FindChild("Name", "filledOrdersUserControl", 9999).FindChild("Name", "WPFObject(""gridControl"")", 99999)
That is still much more plausible than the original fullname or name map.
"One slight change anywhere in the fullname will break far too much. I am surprised this doesn't affect more people."
It used to affect me. I was mapping objects using Full Name, too. But if you're doing that, there's no difference between directly addressing the object and using an alias, apart from the alias name.
What I've taken to is to map an object using its VBObject name (WPFObject for you, it looks like), then setting it to find on any level. No "dot" anything in the address. That way if any of the intervening layers change, I can still address the object, assuming the developers didn't change the Name.
The only time I've had issues now is when the control is in an array and the array id changes somehow (which has happened a couple of times now, and has me stymied), or when I'm using a control that is still mapped the old way I used to do it (Full Name). Then I either fix the map directly then and there, or I throw in the patch I posted and move on until I can fix the map later.
I still don't know if I'm doing it right with using Name and Find On Any Level (or occasionally a conditional blending of properties when Name isn't unique enough), but it seems to be working so far. I'm starting to think that if one can master Name Mapping, one will master TestComplete.
I've had a few of those too..
where
Spreader
name mapped to:
Sys.Process("MyApp").WPFObject("HwndSource: root").WPFObject("root").WPFObject("ContentControl", "", 1).WPFObject("Grid", "", 1).WPFObject("SpreadGrid", "", 1)But that has the same problem..even worse if they change one of the objects in between, it will break the mapping. Plus I have to remember at what midpoint this alias maps to. So I have to constantly look it up to build paths under it.
Whereas:
Set Spreader = Sys.Process("MyApp").FindChild("Name", "WPFObject(""SpreadGrid"", """", 1)", 9999)Never fails.
I'd rather spend time making new tests, not maintaining old ones.
Once I stopped using namemapping, I think I finally started to master TC
"There is surprisingly little to no performance difference between namemapping and doing live lookups"
Is not my experience with websites.
I have a page where I have to search out objects within a table. It's way too dynamic to map. So I map page/tab/frame/table shell. And thats it. Anything within the table (each cell may or may not contain many multiple controls of different kinds) is dynamic. So I use helper/finder functions on those. They are slow compared to using mapped objects. but I don't have any choice. And thats searching from table level (which is mapped) down. The DOM at that time contains several of these tables, all very similar, on different tabs. But only one would be visible.
I'm not even sure a helper function that searches from sys level down would work. Maybe in two or three steps, but that would be even slower.
Hence my using a mixture of both.
And when mapping, the Alias map should be a MUCH more condensed version of the full name map. It should not contain mid-layers like panels and frames which the user doesn't care about. If a mid-layer (such as a container panel) changes or is added, and breaks the alias, I just fix the name map, which is normally easy. It only gives me problems if there is a HUGE structural change. In which case, you probably started building your automated tests too early. We usually wait until the core structure of an application is pretty stable before we do.
My full test suite for the last web application was about an 8 hour run (triggered automatically overnight by the build process). That was using a combination of high level map and lower level helper functions. I hate to think how long it would have taken using helper functions only.
Horses for courses I suppose. If it works for you, stick with it. :)
I made many a mistake with name maps (or object repositories) in the past with QTPro .... (auto-map entire page ..... *shudder*)
