hierarchy is changing from time to during development

For a changing hierarchy, there are two ways of handling this.



First, you can use the FindChild method in your code to find your components and specify the depth of search in such a way as to account for any change in hierarchy.  You would have to call FindChild at a sufficiently low parent level to account for a number of variations.



Or, you could use the Extended find feature of NameMapping.  This operates similarly that you can associate a child object with a parent further up the hierarchy and check the "extended find" flag.  Then, if the object shows up anywhere in the hierarchy, it returns.



The caveat to both of these methods is a little bit over overhead to search for the objects.  



A tip to add then is also to make sure that you supply enough properties and values to NameMapping or FindChild to be able to pick out the specific object you want out of all the objects in the tree, especially if there are several that are similar.

Hi,



i know what you mean but,the hierarchy can change on a daily base and i just wanted to know if this is the right way to work?

it seems to me a bit weird that i need to maintain the object's recognition on a daily bases.is it customary?



thx

Just to give an example of what has been changed and cause the script to stuck:








Old-->Aliases["FusionDesktop"]["HwndSource_MainWindow"]["MainWindow"]["Grid"]["TabControl"]["Grid"]["ContentPanel"]["PART_SelectedContentHost"]["AssemblyViewTabControl"]["Grid"]["Grid1"]["UserControl"]["UserControl"]
New-->Aliases["FusionDesktop"]["HwndSource_MainWindow"]["MainWindow"]["Grid"]["TabControl"]["Grid"]["ContentPanel"]["PART_SelectedContentHost"]["AssemblyViewTabControl"]["Grid"]["Grid1"]["UserControl"]["WPFObject"]("ScrollableTabControlScreen")



How can i tell TC that there's suppose to be an extension to the object recognition which is ["WPFObject"]("ScrollableTabControlScreen") in this case?

Thanks Robert,



Yes,unfortunately that's what I thought :(...



Thanks 

This is the primary drawback to UI based automation in that you need a finalized UI in order to do much work.



However, there are methods that you can use where you don't need to map things out ahead of time and maintain the code.  You can abstract the UI components in such a way that, using a data-driven methodology, you can pass in the component names and properties and have the code dynamically find them and operate against them.  This takes a good bit more code work but, once such a framework is created, you are free to automate with only needing to update a data table (excel sheet, CSV, etc) when it comes to changing components.  Still means you need to maintain recognition daily but it's a bit less of a "hassle" in maintaining code objects.

Yap,sounds like a good idea.

I'll see how and if to implement that.it's a whole different approach



Thanks :)

"A tip to add then is also to make sure that you supply enough properties and values to NameMapping or FindChild to be able to pick out the specific object you want out of all the

objects in the tree, especially if there are several that are similar."



Hi robert,

Is there any other alternative to make this faster,

I am working of a wpfpivotgrid and trying to find out ScrollableAreaCell based on 

ValueItem.RowIndex and ValueItem.ColumnIndex