DocumentWindow has no Header(Template) property any more?

Hi Markus,

For the Header/HeaderTemplate discussion, let's move that to your other thread and talk more there:

https://www.actiprosoftware.com/community/thread/23400/too-many-properties-are-still-of-type-string#111947

In 2016.1, there are five places you can put custom contextual content, all described in the Contextual Content topic in the documentation.

1. Tool window auto-hide tabs

2. Standard MDI title bar

3. Tabbed MDI tabs

4. Tool window docked tabs

5. Tool window title bar

The documentation topic tells you the properties to use to access each of those.  One reason we have five properties (one for each usage location) is that you don't always want to show the same custom content in all locations.  Some might be appropriate to have it and some might not.  Since all of the properties are DataTemplate-based, you can reuse the same DataTemplate across the properties that should share a template.

As for the conversion documentation missing regarding the Header/HeaderTemplate change, that was an oversight on our part (sorry!) and we will add some documentation for the next build.

While TabbedMdiTabContextContentTemplate definitely is a good start, I have 2 problems with it:

1. It is always right aligned. Most of time this is good (for adding custom state icons), but this is bad when the old Header property was a TextBlock with bold or colored spans.
2. Bindings with ElementName do not work (like before). Instead of Binding to elements of the same xaml file they now find elements of the surrounding parent.

Overall the new component has definitely improved and I'm already a fan of the AdvancedTabControl. But as every rewrite-from-scratch it still has some bad bugs on edge cases -- I'll have to look if I can extract small standalone projects for reproduction or if I'll have to send you the complete EXE (quite large, but good Snoop-able).

Hi Markus,

We did our best to handle most legacy features in a good way in the rewrite, but sometimes in cases like this, we might not realize how important a particluar edge feature is to a customer.  There were issues with the old header features in general since they could lead to bad, inconsistent UI, and didn't have the ability to change their appearance based on UI location. 

That being said, we definitely would love to get more detail from you as to what you used it for and some screenshots would be fine.

For samples, please always just send new small sample projects (in a renamed .zip file extension) since it's too difficult to sort out important pieces from large projects.  But in this case, a screenshot or two is hopefully fine.

For the bindings issue, yes that is correct.  Since the control can move around, DataTemplates are now used so that we don't get visual-is-parented-elsewhere issues.  But that will prevent ElementName references from working.  {x:Reference} references may work in some cases but we didn't try that.  The data context of the data template is whatever your docking window's DataContext object is, as long as it isn't a UIElement.  The reason the data context there has to be a non-UIElement again is due to visual parenting issues when changing layouts.