DocumentWindow has no Header(Template) property any more?

Docking/MDI for WPF Forum

Posted 8 years ago by Markus Springweiler
Version: 16.1.0631

I need custom content in my documents tab and there is only a Title property of type String. [1]

Previous release had Header + HeaderTemplate and there was also a QuickStart named "Docking Window Header" with progress icon and save button on tabs.


ToolWindows seem to have such opportunity through the short named property ToolWindowContainerTitleBarContextContentTemplate [2] but I found nothing similar for DocumentWindows -- and I thoroughly used Snoop on this.


There is not even a notion what has happened to these Header and HeaderTemplate properties in ms-its:C:\Program Files (x86)\Actipro Software\WPF-Controls\v16.1.0631\Documentation.chm::/Topics/Docking/Conversion/ConvertingTo20161.html !




[1] are you kidding at me?
[2] are you kidding at me?

[Modified 8 years ago]

Comments (3)

Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA

Hi Markus,

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

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.

Actipro Software Support

Posted 8 years ago by Markus Springweiler

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).

Posted 8 years ago by Actipro Software Support - Cleveland, OH, USA

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.

Actipro Software Support

The latest build of this product (v24.1.2) was released 2 months ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.