ToolWindow prevents visibility of child components by Microsoft Coded UI Test

Hi Andrew,

When testing tool windows, make sure DockSite.ToolWindowsSingleTabLayoutBehavior=”Show” is set so that tabs are forced to show. When a tab is hidden (a single tool window in a container), different UI automation peer code path kicks in and has the tool window’s content be a child of the container instead. But this causes Coded UI to fail since Coded UI doesn’t seem to properly use the altered GetChildrenCore() results from the automation peer.

Thanks for the advice.  Forcing the tabs to "show" now enables Coded UI to to see the children.  I will discuss this issue with our developers as in this case we don't want the tabs to show.

Perhaps you could set that option on only when doing Coded UI testing and off otherwise.

I posted this problem on

• https://connect.microsoft.com/VisualStudio/feedback/details/920920/coded-ui-fails-because-it-doesn-t-seem-to-properly-use-the-altered-getchildrencore-results-from-the-automation-peer

Their response was this:

• The root of the problem seems to be the Pane DockingToolWindowExample (which is not appearing in the Navigation Tree). Now what is happening is that CUIT is able to search till DockingToolWindowExample. However beyond that when it queries for it's children, UIA isn't returning any. I checked this using pure UIA code without CUIT. The correct thing to do here would be to fix the AutomationPeer of DockingToolWindowExample control to return the button as it's child.

Please could you advise.

Hi Andrew,

I just pasted your original DockSite code above into a Window and ran the application.  Then I ran VisualUIAVerify.exe and expanded out the UIA tree for this Window in there.  When I got to the ToolWindowContainer node in the UIA tree, I saw it had four entries: dropdown button, auto-hide button, close button, and the content area button.  So to me, that says that UIA is seeing the content area button ok.  I'm not sure what tool they are using where they see something different.

Thanks for the response.

The tool I am using is Coded UI Test in Visual Studio 2013. The entries are visible using such tools as VisualUIAVerify, as you say. However, playback of a CUIT recording will launch the example but then it fails to find the button and so the test fails.

Also, attempting to "Locate the UI Control" from the "UI Control Map" in VS 2013 fails to locate the button which is recorded as a child of DockingToolWindowContainerExample. Note the DockingToolWindowExample layer is not seen as part of the recording.

Hi Andrew,

We are considering doing some rearchitecting work in the Docking/MDI product and as we do so, will try and update UIA and work with Coded UI Test to see if things can be improved in that area.

I look forward to being able to move forward with this.  Thanks again.

We have encountered the same problem.
No control is found inside the docking:ToolWindowContainer.
Our investigation revealed that probably the Children are not correctly returned.
We hope that it does not take another 5 months until the problem is solved.

<docking:ToolWindowContainer x:Name="MetaToolWindowContainer" AutomationProperties.AutomationId="SingleParameter.Metadata.Control.MetaToolWindowContainer" >
 <docking:ToolWindow x:Name="MetaToolWindow" Title="{x:Static properties:Resources.MetaInformationTitle}" CanClose="False" ImageSource="../Resources/Images/Properties16.png" > 
  <StackPanel x:Name ="ToolWindowStackPanel" >

Hi Christoph,

Did you set the ToolWindowSingleTabLayoutBehavior property as we described above?  When we use this XAML with Coded UI Test, we are able to access all the TextBox controls:

	<docking:DockSite ToolWindowsSingleTabLayoutBehavior="Show">
		<docking:SplitContainer>
			<docking:ToolWindowContainer AutomationProperties.AutomationId="LeftToolWindowContainer">
				<docking:ToolWindow x:Name="leftToolWindow1" Title="Left 1">
					<TextBox x:Name="leftTextBox1" />
				</docking:ToolWindow>
				<docking:ToolWindow x:Name="leftToolWindow2" Title="Left 2">
					<TextBox x:Name="leftTextBox2" />
				</docking:ToolWindow>
			</docking:ToolWindowContainer>
			<docking:Workspace>
				<docking:TabbedMdiHost>
					<docking:TabbedMdiContainer AutomationProperties.AutomationId="TabbedMdiContainer1">
						<docking:DocumentWindow x:Name="document1" Title="Document1">
							<TextBox x:Name="documentTextBox" />
						</docking:DocumentWindow>
					</docking:TabbedMdiContainer>
				</docking:TabbedMdiHost>
			</docking:Workspace>
			<docking:ToolWindowContainer AutomationProperties.AutomationId="RightToolWindowContainer">
				<docking:ToolWindow x:Name="rightToolWindow" Title="Right">
					<TextBox x:Name="rightTextBox" />
				</docking:ToolWindow>
			</docking:ToolWindowContainer>
		</docking:SplitContainer>
	</docking:DockSite>

As long as your setup is similar, you should be able to find the child controls ok.  Without that ToolWindowSingleTabLayoutBehavior property set, we do alter the UIA Children but Coded UI Test still doesn't seem to find the children if no tabs show.  That's why as a workaround, adding that property setting helps when there is a single tool window in a tool window container.

Yes with ToolWindowSingleTabLayoutBehavior property set to "Show" the controls are found by CodedUI test.

But then an unwanted tab is displayed.
Is there a workaround to make the icon and the text invisible.

Another problem occurs when the DockingWindow is moved from the right edge to another location. No child control can be found afterwards. The recording with the Coded UI Test Builder results in a new tree. A new Automation-Id is assigned to the UIToolWindowContainerPane, e.g. "Toolwindow container 9a57037b-99c2-42a9-9c86-add1e4f5f36b".

Hi Christoph,

Sorry but you would need that tab visible for the Coded UI Test to run properly if there is no second attached tool window.  Perhaps you can flag it on only when you need to run tests.

If you change the layout then yes, new ToolWindowContainers may be created and others destroyed.  That will alter your visual tree and probably break Coded UI Tests.  I would not recommend changing the layout during a Coded UI Test for that reason.