Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
Asser82 opened this issue Nov 26, 2019 · 13 comments
Milestone

Comments

@Asser82
Copy link

@Asser82 Asser82 commented Nov 26, 2019

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

@arpitmathur arpitmathur added this to the Future milestone Nov 26, 2019
@vatsan-madhavan

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Nov 27, 2019

Can you reproduce the problem in a simple RibbonWindow application?

@Asser82

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Nov 28, 2019

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.

grafik

@vatsan-madhavan

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Nov 28, 2019

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

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Nov 28, 2019

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

@Asser82

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Nov 28, 2019

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

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Dec 2, 2019

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:

grafik

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

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Dec 2, 2019

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

Have you tried setting WindowStyle.None?

@Asser82

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Dec 2, 2019

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

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Dec 2, 2019

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

@vatsan-madhavan

This comment has been minimized.

Copy link
Member

@vatsan-madhavan vatsan-madhavan commented Dec 2, 2019

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

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Dec 3, 2019

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

This comment has been minimized.

Copy link

@weltkante weltkante commented Dec 3, 2019

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

This comment has been minimized.

Copy link
Author

@Asser82 Asser82 commented Dec 3, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.