Properties not more supported in new version?

Hi John,

In the 2016.1 version, we rewrote the Docking/MDI product mostly from scratch to allow it to have next generation features and have a much cleaner and concise style/template setup.  While most of the public API remained the same, there were some breaking changes like what you ran into and all those are described in the "Converting to 2016.1" topic in the Docking/MDI documentation that comes with the product.  Please check that for details on anything you run into.

For your questions, yes the HasOptions is now HasOptionsButton.  The TabBackground and TabForeground properties are gone because theming of tabs is now completely done by a new AdvancedTabControl.  The new DockSite.ToolWindowTabItemContainerStyle can be set to a Style that should flow down to all tool window containers.  Here's our default value for that property:

<Style TargetType="docking:AdvancedTabItem">
	<Setter Property="Header" Value="{Binding TabTextResolved}" />
	<Setter Property="HeaderTemplate">
		<Setter.Value>
			<DataTemplate>
				<TextBlock Text="{Binding}" TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
			</DataTemplate>
		</Setter.Value>
	</Setter>
</Style>

You could set other properties like Background there or completely redo the control template if you like (but that would be much more complex).

Hi,

thank you for your response. 8 months ago I reported a case

http://www.actiprosoftware.com/community/thread/23176/toolwindows-not-visible-in-codeduitest#111128. Is that behavior done correctly now?

Regards.

Hi John,

In the 2016.1 version, we rewrote the UI structure of the Docking/MDI controls to make them simpler and also redid all the UIA classes for each type to match the new structure.  I believe we did see some better results with Coded UI Test when we had looked at it.

Hi,

I tested again, the errors are unfortunately remained ... In some aspects, has become even worse and now it does not work: I create the toolwindow dynamic and add it to the container. I assign the AutomaitionId and AutomaitionName by code,  that has worked before, but now no longer:

            ToolWindowView messagesToolWindowView = new ToolWindowView
                                                    {
                                                        Title = (string)Application.Current.Resources["AllMessages"],
                                                        ViewModel = { Name = "MessagesToolWindow", DefaultDock = Dock.Right, DockGroup = "1", IsInitiallyAutoHidden = true }
                                                    };
            messagesToolWindowView.SetValue(AutomationProperties.AutomationIdProperty, "MessagesToolWindowAuId");
            messagesToolWindowView.SetValue(AutomationProperties.NameProperty, "MessagesToolWindowAuName");
            _toolItems.Add(messagesToolWindowView);

 The AutomationId is now something like "xxx.PART_DockHost__ToolWindowContainer"

Regards.

Hi John,

Can you tell me what type ToolWindowView is (a ToolWindow, ToolWindowContainer, etc.)?  ToolWindow doesn't have code to change AutomationId.  It will use its Title for the automation Name though.

ToolWindowContainer on the other hand will generate an automation ID if AutomationId isn't specified.  And the generated ID will look someting like the one you pasted.

We are happy to work with you to improve things if you see problems.  What would help most is if you could make a new very simple sample project that shows the issue you're having and send that to our support address.  In your email, reference this thread and rename any .zip file extensions so they don't get spam blocked.  Tell us what you would expect to see and what is wrong.  Then we'll debug with that and work with you.

Hi,

ToolWindowView is a subclass of ToolWindow. I found it now few levels lower. Although the logical UI tree is unchanged, the visual UI tree had changed massively... All my tests must be adjusted now.

Hi John,

Yes, in the older version the tool windows used to render the actual UI tabs of the container.  The problem there was that if there were no tabs visible (such as when a single tool window was in a container), UIA could never find the window. 

In the newer visual tree structure, each ToolWindowContainer has an AdvancedTabControl within its template.  The AdvancedTabControl's ItemsSource is bound to the ToolWindows in the ToolWindowContainer, so each AdvancedTabItem that is generated has the related ToolWindow as a DataContext.  ToolWindow is now a simple container (a ContentControl) that wraps the content it actually displays in UI.  Thus when a ToolWindow's content is displayed in UI, the ToolWindow itself is also guaranteed to be visible since it contains the content in UI.

Again if you run into any particular issues with the new setup, please send us a simple sample per our previous reply and we'll work with you.