I am styling a Window, but I noticed this strange behaviour of WindowChrome (in .NET FW 4.0, from external Microsoft.Windows.Shell dll).
I set the WindowChrome with AllowTransparency = true and WindowStyle = None.
If I set the WindowChrome's ResizeBorderThickness <= 7 everything works perfectly, but if I do
ResizeBorderThickness="8"
or more, when the Window is Maximized I can't drag it from the last top pixel near the top edge of the screen, and for each +1 exceeding 7 I must start dragging 1 pixel more down from the edge.
This is annoying 'cause it disable a common behaviour when closing a window, forcing me to set it to 7 or less.
Can someone explain me this behaviour?
Thank you!
The window doesn't have a strange behavior. Instead of it, the window has two strange behaviors.
This behavior is due to the edge to resize is still active when the window changes to its maximized state. Indeed, this edge is always active. Setting the ResizeBorderThickness property, WindowChrome reserve that amount of pixels to control the behavior of resizing the window. Given that in maximized mode the resize events aren't allowed, then you will notice that these pixels don't allow any kind of behavior. This is precisely because WindowChrome reserve exclusively those pixels that control the behavior of resizing.
What is the solution? You need to notify WindowChrome must change to establish the ResizeBorderThickness property to 0 when the window is maximized. This can be done simply by setting WindowChrome again by a Trigger in xaml:
Note: This can also do so in run-time code
Take care. Actually this behavior isn't due to the value set in ResizeBorderThickness but this is due to set the property WindowStyle=None. When this property is set, the window takes on a strange behavior when maximized:
The upper left edge of the window is not positioned at the point (0,0) of the current screen, but rather erratically becomes negative (in your case, on the Y axis the value seems to be -7).
The size of the window takes the size of the current screen, when the normal behavior should be that the size of the window takes the size of current work area (current screen except task bar, etc...) of the current screen.
This strange behavior that takes the window makes that 7 pixels reserved for 'WindowChrome' aren't visible in the current screen (with ResizeBorderThickness="7", obviously), and therefore gives you the feeling that the property ResizeBorderThickness="7" works properly, when it isn't. In fact, this justifies the behavior when ResizeBorderThickness takes the value 8 or more.
What is the solution? It is necessary to force the window when maximizing a size and position on the work area of the current screen. Warning: if you only do it for the primary screen, the maximize event doesn't work properly for multiple screens.
The code that solves this problem I solved by calling an external API:
Defining the classes and structs:
And finally defining the functions that add the hook WndProc to the window:
With CompatibilityMaximizedNoneWindow API, you simply call the API in the constructor of the window, something like this:
And the second strange behavior must be resolved. You will notice that the code to work, you must add reference PresentationFramework and the namespace System.Windows.Interop.