Title bar does not appear for single ToolWindowContainer within non hosted floating window

Hi Anton,

Sorry but I'm not seeing that.  Are you on the latest version?  Also, can tell us how to reproduce it in our samples?

I'm on 17.2.0661.

Could you please guide me on how to get your samples to check if I can reproduce with them?

I installed the samples and checked 'Simple IDE' demo. I cannot replicate the issue in this demo project.

I'm still seeking for advice what may potentially caused the title bat is missing in my project - it was there with previous ActiPro verions. Any advice is appreciated.

When you install the controls, as long as you left the default install options, there will be an Actipro WPF Controls group in your Windows' all programs list.  That group will have a link to the big sample project with hundreds of samples in it.

As for the title bar being missing, the only thing I can think of without having a simple repro example's source is if you perhaps modified our default Styles for some Docking/MDI controls in your application.  Have you done anything like that?  If so, please comment them all out so that the defaults take place. 

We also have options like DockSite.ToolWindowsHaveTitleBars and ToolWindow.HasTitleBar where if you set those to false, it would hide the title bar.

In fact I can reproduce the issue in your sample application. In 'Simple IDE' demo there are ToolWindows like Solution Explorer or Document Properties. They behave eactly as I described in original message.

When I pop out a single Solution Explorer window it does not have a title bar. I mean the title bar every window has in windows OS - which has icon and everything. It does have some toolwindow title bar though. Now when I dock it to Document Properties, the normal window's title bar appears for the group. While both toolwindow title bars remain in place.

My concern is that usual window title bar. It used to be there for toowindow even when it is not docked to anything. How do I bring it back?

Can we arrange a live support session for this? I believe I would explain the issue much clearer.

Hi Anton,

Ok thanks, I understand what you mean now.  Yes the WPF Windows that host floating dock hosts now all have WindowChrome applied as of the 2016.1 version's major updates.  When a single ToolWindowContainer is floating, it will use its own ToolWindowContainer title bar as the Window's title bar.  We tell Windows to treat that ToolWindowContainer title bar as a normal Windows title bar so double-clicking, drags for Aero snap, etc. all work as expected.  But it will not render an additional Window title bar in that case, since that would be duplicating things.  It only adds a Window title bar when there is more than one ToolWindowContainer in the floating dock host, or if tabbed MDI is in the floating dock host.  This is the same as what Visual Studio does and is by design (not a bug).  

I see. The issue to me is that this behavior is different to what I have seen in version 12.x and in version 17.1.x. However in 17.1.x I was unable to drag window using WindowChrome. It is an issue for me because my customers are kind of used to WindowChrome. Are you saying it is impossible to bring the chrome back in 17.2? Probably I can tweak some style or something?

Maybe just for clarification you could link to an image that shows the difference.  I want to be positive we're talking about the same thing.

The 2016.1 version is where we rewrote many of the internals of the Docking/MDI product and reimplemented all the entire UI styles/templates.  So anything that you see now in 2017.2 should be roughly the same as 2016.1 and later, unless you were using the "legacy" (pre-2016.1 API) version of the Docking/MDI still in 2017.1.  

But even comparing 2012.1 to 2017.2, both render a ToolWindowContainer title bar when there is a single floated ToolWindowContainer, and a WindowChrome title bar gets added if you have more than one ToolWindowContainer in a floating dock host.

Sent images via email.