The control search in Coded UI Test playback is essentially a breadth first search. For extension plugins that have in-built search capability, the plugin writer can implement its own search logic. What typically remains the same is the way the search is done for the top level window of the application.

 Consider a top level window UI object such as

       <TopLevelWindow ControlType=”Window” Id=”UICalculatorWindow” FriendlyName=”Calculator” SpecialControlType=”None” SessionId=”36635974″>

          <TechnologyName>MSAA</TechnologyName>

          <WindowTitles>

            <WindowTitle>CalculatorX</WindowTitle>

            <WindowTitle>CalculatorY</WindowTitle>

          </WindowTitles>

          <AndCondition Id=”SearchCondition”>

            <PropertyCondition Name=”Name”>Calculator</PropertyCondition>

            <PropertyCondition Name=”ControlType”>Window</PropertyCondition>

          </AndCondition>

          <Descendants>

                <UIObject ControlType=”Button” Id=”UISubtractButton” FriendlyName=”Subtract” SpecialControlType=”None”>

                  <TechnologyName>MSAA</TechnologyName>

                  <WindowTitles>

                    <WindowTitle>CalculatorX</WindowTitle>

                    <WindowTitle>CalculatorY</WindowTitle>

                  </WindowTitles>

                  <AndCondition Id=”SearchCondition”>

                    <PropertyCondition Name=”Name”>Subtract</PropertyCondition>

                    <PropertyCondition Name=”ControlType”>Button</PropertyCondition>

                  </AndCondition>

The top level window has a Name property value “Calculator” and a list of window Titles “CalculatorX” and “CalculatorY”. The recorder auto-generates these window titles for scenarios where the title of the application top level window changes across different actions performed on the controls within this window.

During the playback search, in the first phase, the playback enumerates through all windows under the desktop to match for a window title “Calculator” i.e. the Name property value in the above UICalculatorWindow object.
If it fails to find any window with title “Calculator”, it then moves to the second phase where it tries to match any window with title “CalculatorX” or “CalculatorY”.

In each phase, a similar heuristic is applied i.e. first search within Maximized window, then search within Minimized windows (depending on the Playback.PlaybackSettings.SearchInMinimizedWindows) and finally apply smart match (depending on the Playback.PlaybackSettings.SmartMatchOptions)

Now consider an application where the window title changes by performing some navigation click actions on hyperlinks in the left pane (which causes the right pane’s content to refresh). Assume the user is hand-coding the test scenario and has statically added all the hyperlinks in the left pane to the UIMap. All these hyperlink controls and the top level window would have been auto-generated with only one WindowTitle i.e. the title of the window when the controls were captured in UIMap (say, TitleA) 

If the user runs through the test scenario and has an action on the any of these hyperlinks while the window title has actually changed (from TitleA to TitleB), the search will fail.  To fix this, the user needs to manually append the TitleB to the list of window titles for the hyperlink’s top level window in the UIMap.

Note, if you are in VS2011 RC bits or later, it is not required to update the window titles for each of the inner hyperlink controls. Just the top level window’s window title list update will suffice. (This was a product bug that has been fixed in VS2011 RC). Without this fix, the user would have required to update the window titles of all the inner hyperlink controls to include TitleB.