Conversion Problem from v14.2.610.0 to v16.1.0633.

Hi Roger,

I believe your company has a WPF Studio license so whoever is listed on the account can download the default styles/templates for the 2016.1 version from your organization's account page on our site.  I'd recommend you start there.  For the 2016.1 version, we completely rewrote the product, adding a lot of major new features along the way and making the internals much better.  While much of the public API is the same or similar, there are some breaking changes.  Notably, all of the styles/templates were redesigned to be simpler and easier to customize.  If you have those default styles/templates, then you can see how they look for the new version.

1) Those controls aren't used any more in the switcher.  StandardSwitcher's style is a lot more straightforward to customize now, but you will need the default style/template to see how to customize it.

2) Part of the updates was making the DocumentWindow and ToolWindow controls actually be the containers in UI of their own content.  In the old version, they rendered themselves in UI as tabs.  In the new version, separate tabs still represent them but the docking windows are the parent of their child content.  So instead of walking up to look for a TabbedMdiContainer, etc., just look for a DocumentWindow.

3) Sorry but I'm not sure what you mean here.  Could you provide more detail? 

3) We have CustomToolWindow class which derives from the ToolWindow.

/// <summary>
/// For customize toolWindow
/// </summary>
/// <seealso cref="ActiproSoftware.Windows.Controls.Docking.ToolWindow" />
public class CustomToolWindow : ToolWindow
{
/// <summary>
/// Initializes a new instance of the <see cref="CustomToolWindow"/> class.
/// </summary>
public CustomToolWindow()
{
this.DefaultDockDirection = Direction.Bottom;
this.AllowDrop = false;
}

/// <summary>
/// Gets or sets the default dock direction.
/// </summary>
public Direction DefaultDockDirection { get; set; }

/// <summary>
/// Gets or sets the default dock group.
/// </summary>
public string DefaultDockGroup { get; set; }

/// <summary>
/// Gets or sets a value indicating whether this instance is initially automatic hidden.
/// </summary>
public bool IsInitiallyAutoHidden { get; set; }

/// <summary>
/// Gets or sets the default dock relative group.
/// </summary>
public string DefaultDockRelativeGroup { get; set; }

}

This is xaml and we bind the properties between the Title and DrawingImage and the ViewModel.

We have build error on Title="{Binding Path=TranslatedText}".

<common:CustomToolWindow x:Class="ToolWindowView"

Title="{Binding Path=TranslatedText}"
DefaultDockGroup="ToolGroup4"
DefaultDockDirection="Bottom"
IsInitiallyAutoHidden="False"
>
<common:CustomToolWindow.ImageSource>
<DrawingImage Drawing="{Binding Drawing, Source={StaticResource build}}" />
</common:CustomToolWindow.ImageSource> 

Hi Roger,

Any Binding like that should not cause a build error.  I can see it showing a binding error in the VS Output at runtime if the DataContext inherited down to the ToolWindow doesn't have that property when the binding tries to execute.  But that shouldn't stop the app itself, it would just prevent the value from showing up properly.  Assuming you are setting the CustomToolWindow.DataContext at some point after the XAML loads, I would expect to see binding errors for the bindings in your XAML (since there is no data context yet and the bindings are executing) and then after the DataContext is set, the data woudl populate.

If you aren't using our MVVM features (DockSite.ToolItemsSource, etc.) then a better way would be to peraps create this tool window instance in code and set the DataContext to your VM before you ever open it (and thus load the XAML) in UI.