Window overflows to second screen after it is snapped to desktop top

[Asser82]

Hi there,

I am using a Window with a custom WindowChrome. This caused many bugs over the last year. The initial bug was, that when the window is maximized the window size is calculated bigger than the screen, so that part of the window content is clipped at the edges.

To overcome this I added a margin between the window and its content, when the window is maximized. After that I had problems with wrong window size calculations with undocked task bars, multiple monitors and different dpi scalings. After several iterations I resolved such issues by handling WM_GETMINMAXINFO.

Now a new bug arrived, that says that a black border is visible on the second screen, when the window is maximized by snapping it to the top of the first screen. The border does not appear when I maximize the window by double clicking the caption or by pressing the maximize button. Is this a bug? If not, is there a way to detect that a window is maximized through snapping, to handle it differently?

Thanks,
Arthur

[vatsan-madhavan]

Can you reproduce the problem in a simple RibbonWindow application?

[Asser82]

It is not a RibbonWindow, but a default Window. I had now time to create an isolated application for that issue: https://1drv.ms/u/s!AqVYMDsfZK_qiEdM1dad2bEPrB6d?e=d94gRx

You need two screens to reproduce. Maximize the window by double clicking the caption or through the maximize button => All OK. Now maximize the window by dragging and snapping the caption to the desktop top => Note the black border on the second screen.

[vatsan-madhavan]

Thanks for the clarification @Asser82. I understood the description the first time around that your problem is related to a Window + WindowChrome.

Given this understanding, I'm still asking whether you are able to reproduce your symptoms in a RibbonWindow ?

From your description, I'm noting that you have some customization of window message processing going on in your application. Unpacking the source of potential problems in such an application is always tricky. RibbonWindow is WPF's canonical implementation of customized window chrome which employs WindowChrome, and some of the same kind of additional window message processing to ensure that rendering in the non-client area works well.

If you are able to reproduce your symptoms with RibbonWindow, then we can be confident that the problems you are seeing are inherent to WPF. If you are unable to reproduce these problems in RibbonWindow, then these problem may very well be application bugs (although that wouldn't necessarily rule out these being WPF bugs; it may still give us a better framework to help you).

[vatsan-madhavan]

If you have a repro project/zip file, please attach it here directly.

[Asser82]

I will have to test it with RibbonWindow on monday or so. The minimalistic sample with the default window is in the link above. It was not possible for me to attach the ZIP directly, without getting some kind of don't support or not possible error.

If it all takes too long to resolve, I will have to switch to a widow implementation from a third party library like the Telerik RadWindow, where the WindowChrome class is not used at all. It should not be that difficult to realize a custom window border that matches the application's style, without loosing functionality. There are so many boards on the internet, where people struggle to realize the same and go through the same problems.

[Asser82]

The RibbonWindow does not improve anything. By trying out the RibbonWindow with this code

RibbonWindow window = new RibbonWindow();
window.Show();

and maximizing the window afterwards, the first thing that the user sees is a clipped icon and buttons that have a reduced height:

Now the developer must start to add an outer border, to move the icon and the buttons into the view. This border must be adapted when the WindowState changes, because in the non maximized state no outer border is needed and everything is OK.

If I add this border, I have to adapt the window chrome, to have the same visible and functional caption height in maximized/non maximized state. And so on, and so on. By doing all this kind of stuff at some point I reach the same configuration like the one with the default window.

[vatsan-madhavan]

See https://devblogs.microsoft.com/oldnewthing/20120326-00/?p=8003

Have you tried setting WindowStyle.None?

[Asser82]

See https://devblogs.microsoft.com/oldnewthing/20120326-00/?p=8003

Have you tried setting WindowStyle.None?

I have read this blog post, as many others. It describes, why it is this way, but not, how to get things done. So it is useless from my point of view.

Yes, I have tried to use WindowStyle.None. It removes this specific problem with the border while introducing others. Like the window extending below the desktop task bar when maximized and the window drop shadow being removed, which does not look good, when windows overlap.

Drawing the drop shadow by myself inside the window with AllowTransparency=true is also a bad solution, because the drop shadow is still visible when the window is maximized and it also does not work well with the view, which is presented, after the window is snapped to the desktop's right side. Additionally, we obseved degraded performance after setting AllowTransparency to true.

A complete working example for a Window that uses WindowChrome, does not clip anything from the title bar when maximized, allows to be dragged and resized, respects the task bar in docked/undocked state, works with multiple monitors with different resolutions and scalings and has a drop shadow that works well with snapping/maximizing would be very much appreciated.

[Asser82]

Basically I need the source code for the Visual Studio 2019 Shell Window. It is WPF based and it works as expected.

[vatsan-madhavan]

Basically I need the source code for the Visual Studio 2019 Shell Window. It is WPF based and it works as expected.

😄

Paging @chabiss, @diverdan

[Asser82]

OK, after spying around in the VisualStudio assemblies, I found a class called Microsoft.VisualStudio.PlatformUI.Shell.Controls.CustomChromeWindow in Microsoft.VisualStudio.Shell.ViewManager. When I see, that the VisualStudio team needed 1800 code lines including a massive interop message handling of messages like WM_WINDOWPOSCHANGING, WM_WINDOWPOSCHANGED, WM_NCCALCSIZE, WM_NCHITTEST, then it becomes clear, why it is not possible to achieve this expected behavior by just applying WindowChrome to a window. Looks like we need a third party chrome window implementation.

[weltkante]

Looks like we need a third party chrome window implementation.

Or feed back some of the bugfixes/workarounds the VS team did locally into WPF framework ...

[Asser82]

My boss now told me to stop dealing with this topic, because there are more important things to do. In the meantime, I have found a nice blog, that describes all the pain and proposes a promissing solution. It is not perfect, but quite good, after my initial tests. It does not react well on task bar collapsing state changes, after the window is maximized, and the initial position after being dragged out of maximized state is not optimal, but these two problems seem to be solveable. Everything else seems to work fine:

https://www.source-weave.com/blog/custom-wpf-window

[sygmond]

Thank you @Asser82! After hours of looking for a solution regarding using WindoChrome WPF Window Maximize on a second monitor that is not the main monitor, I got the right solution from the project you linked! Just 2 lines of code made my day!

[MadhumithanJayapathi]

Hi @sygmond ,Could you please share the fix as the link to the project has been expired and I have been searching for so long

[sygmond]

@MadhumithanJayapathi I wish I pasted in here those 2 lines of code two years ago because I'm not entirely sure what those 2 lines are anymore. I could probably create a sample project with the solution I ended up with for the project I was working on at that time, but I'm very limited in time. If you give me 1-2 days, I can do that. I used also Jot lib to save the location and state of the window and restore it when the app is reopened. Is it possible to wait? If not, I can paste pieces of code but I will not be sure if are related to the fix or if the pasted parts are complete.

[MadhumithanJayapathi]

@sygmond Thanks for your response. Sure I am able to wait, I am working in a different task now. Thanks in advance!!!

[sygmond]

@MadhumithanJayapathi I created a sample WindowChromeMultiscreen that it handles different situations and monitor layouts. It saves also the location of the window. I hope it helps fixing your issue.