Coded UI Test relies on unique identification properties of controls to form a resilient search condition during recording. In WPF you can data bind properties of a control and its children collection of ItemsControl such as ListBox, ComboBox, DataGrid, TreeView, etc. An earlier post here describes the problem in more detail. Coded UI Test makes a best attempt to recognize this problem and reports an error during recording. When I say best attempt, it relies on certain heuristics to deduce this based on the amount of information provided by UI Automation layer. It may not work well for Datagrid rows or rich data templates.This post lists out a series of verifications you can do at your end if ever you hit this error while recording. If you see any discrepancies in the behavior, or certain scenarios which are unhandled, feel free to post your comment. We will analyze it and see if they can be incorporated in the heuristic.

1. Check if Automation Name of the item element looks like a default object .ToString() of a Class Type (e.g. System.Xml.XmlElement) i.e. has '.' somewhere in the middle of the string (not first or last char)

2. Check if sibling are of same control type and name i.e. previous and next sibling. For Datagrid scenario, check for extended siblings of the dataitem, around 10 siblings (previous/next). For expandable
items (such as MenuItem, TreeItem), check if it’s parent/child are of similar control type and name.

3. Check if the item has a TextBlock child. The additional conditions are -

    A. TextBlock exists only in UI Automation’s RawView tree and not in ControlView tree.
    B. There should be exactly one such TextBlock in the children list.   
         For performance reasons, we navigate only through first 3 children to look for this TextBlock child. So the heuristic would miss out if the TextBlock is somewhere beyond the 3rd child, which is rare though.

4.  Once such a TextBlock child exists as per conditions in [3], check if this TextBlock’s Name is NOT equal to the ItemElement’s Name (so the item element will have some name like System.Xml.XmlElement and the TextBlock will typically have a good name which is the visually text seen in UI).

If all the above 4 conditions are satisfied, the item is deduced as data-bound.