RibbonWindow chrome issues when scaling

Hi Cristian,

It looks like you're still on v2019.1. I wanted to mention that v2020.1 added a lot of features to WindowChrome, one of which allows easy extension of content into the title bar area.

For instance, in v2020.1 you can do this in your Window constructor:

public Window4() {
	this.InitializeComponent();
		
	var chrome = WindowChrome.GetChrome(this);
	if (chrome != null)
		chrome.TitleBarMergeKind = WindowChromeTitleBarMergeKind.ContentOnly;
}

That tells WindowChrome to arrange the Window's content area over the title bar area as well and seems to work great in high-DPI too.

I tried your code in v2019.1 but couldn't reproduce what you saw.  Have you tried using that new feature in v2020.1?  I'm curious if that works better for you.

Thanks for the reply. We're using a lot of modified styles (Docking, RibbonWindow, Ribbon, and so on) so migrating to v2020.1 would involve a pretty big overhead.

We've done a lot of testing today in order to try to figure out why this is happening only for high-dpi settings; it might have something to do with the way we've customized the styles, but no luck so far.

What I've noticed is that the ribbon tabs are displayed correctly when the window is docked (to either half of the screen) and also when the window's not maximized (but only after I manually force the Height property to a particular value, using tools such as Snoop). Any properties or triggers within the RibbonWindow style that could cause this behavior?

Kind regards,

Cristian

Hi Cristian,

I'm not sure what would trigger it in v2019.1.  Have you tried removing your custom styles for the Actipro controls to see if it makes any difference?

When maximized, there is a RibbonWindow trigger that sets the outerGrid.Margin.  I'm not sure that would really affect this though.

Are you able to make the gray title bar brush semi-transparent so that you can tell if the top of the tabs are rendering behind it or if they are being clipped.  If they are being clipped, I wonder if something in WPF is causing some element's GetLayoutClip() method along the way to clip them.  Although rare, we've seen issues in GetLayoutClip() in certain scenarios where it would incorrectly clip child controls and we'd have to override it to return null.  You'd have to sort out which element is actually clipping though first.

In v2020.1 we no longer have a separate RibbonWindow template.  It's using the WindowChrome default template in that version, so everything is a bit simpler.

Thank you for the suggestions. I followed your route and tried to replicate this behavior in a new project, from scratch.

After many attempts, it turns out the issue was caused by including the Ribbon and Docking components within a PixelSnapper component. As soon as I took them out, things started working correctly.

One more question though, which I think is related: again, under scaling, some of the ToolWindow components are showing unwanted borders:

https://www.dropbox.com/s/alrizjamxgl5t16/scaling_border.png?dl=0

I have been able to fix this setting the margins for the respective toolwindows to (-1), but I'm wondering why these are showing up?

Hi Cristian,

Earlier in the ticket you mentioned you are using 125% DPI.  That is not generally a good DPI to use since it will most likely render anti-aliased artifacts various places due to trying to draw a small portion of a line over a pixel boundary.  100% and 200% DPI are the best to use since you never run into these kinds of issues with those DPIs.  

The border you see could either be part of the ToolWindowContainerTabControl border or perhaps the border of content in your ToolWindow.

I was thinking the same - but had to check since some users are actually on 125%. Thanks for confirming this and thank you for the support!