Drag/Dropping Window to Maximized Cuts Taskbar (BorderOnly Deco) #11685

ArchLeaders · 2023-06-07T07:17:14Z

Discussed in #11222

^{Originally posted by ArchLeaders May 3, 2023}
I'm setting up a custom window chrome for my application, but I'm getting some weird behavior with the drag/drop to fullscreen action in Windows 10.

Setting WindowState to WindowState.Maximized works just fine, but when I drag the window to the top of the screen and drop it cuts out the task bar and about 7 pixels off the side of the window.

window-behaviour.mp4

Is there a way to intercept this behavior and call whatever Avalonia does to fullscreen to the correct bounds instead? Or just another way to fix this?

Avalonia Version: 11.0.0-preview6 and 11.0.0-r1.1
OS: Windows 10

The text was updated successfully, but these errors were encountered:

ArchLeaders · 2023-06-07T07:27:32Z

I should also mention that the other window decoration properties did not work in my case, the main issue being the window drop shadow. The only solution I could find that would remove the system chrome while retaining the shadow (border), was using BorderOnly with a custom resize border and drag region.

timunie · 2023-06-07T08:12:17Z

Window has a property called OffScreenMargin. Can you try to apply this to your inner Content?

<Window xmlns="https://github.com/avaloniaui"
        ... other namespaces etc ... >
   <Grid Margin="{Binding $parent[Window].OffScreenMargin}">
     ... Content ...
   </Grid>
</Window>

ArchLeaders · 2023-06-08T00:40:14Z

Window has a property called OffScreenMargin. Can you try to apply this to your inner Content?
<Window xmlns="https://github.com/avaloniaui"
        ... other namespaces etc ... >
   <Grid Margin="{Binding $parent[Window].OffScreenMargin}">
     ... Content ...
   </Grid>
</Window>

No luck with that sadly, still cuts the border when drop/dropping to fullscreen (same effect as before)

cyraid · 2023-06-14T20:50:01Z

Apparently my bug report got deleted? It was when it's maximized and no chrome it gets cut by 8 pixels or so in a maximized state.

rprimora-pricer · 2023-06-21T15:04:23Z

I experience the same issue. I think you are right for the pixels. It should be 8px which is the padding applied to the Window when it's maximized.

It's as if this way of maximizing resizes the Window without padding and then internally changes state to maximized.

ApaulMyLittleAirport · 2023-07-09T03:30:03Z

Margin="{Binding $parent[Window].OffScreenMargin} ，This one really works, thank you!!

rprimora-pricer · 2023-09-22T08:37:36Z

I have looked closer at the issue today and managed to get a working code.

In your constructor add the following code block:

this.GetPropertyChangedObservable(WindowStateProperty).AddClassHandler<Visual>((t, args) =>
{
    /// I am doing this only for Windows.
    if (OperatingSystem.IsWindows())
    {
        /// If the state is maximised we will enter our code block.
        if (args.GetNewValue<WindowState>() == WindowState.Maximized)
        {
            /// Get the screen from the window.
            var screen = Screens.ScreenFromWindow(this);
            /// This is the part where we check if the actual height is more than the working area cos that would
            /// mean the window has gone over the taskbar.
            if (screen.WorkingArea.Height < ClientSize.Height)
            {
                /// We set the client size of our window to be exactly the size of our working area.
                ClientSize = screen.WorkingArea.Size.ToSize(screen.Scaling);
                /// This is the last piece of the puzzle. If we maximize the Window by setting the state
                /// then this position will be correct. But, if the state is set as a result of dragging the window
                /// to the top then the position will most likely be less then 0 ( it will be (-7,-7) in our case).
                if (Position.X < 0 || Position.Y < 0)
                    Position = screen.WorkingArea.Position; // <-- This is needed because you might have your taskbar in a different position (Left | Right | Top | Bottom).
            }
        }
    }
});

I really hope Avalonia solves this issue.

ArchLeaders · 2023-10-04T18:21:45Z

I have looked closer at the issue today and managed to get a working code.

In your constructor add the following code block:

this.GetPropertyChangedObservable(WindowStateProperty).AddClassHandler<Visual>((t, args) =>
{
    /// I am doing this only for Windows.
    if (OperatingSystem.IsWindows())
    {
        /// If the state is maximised we will enter our code block.
        if (args.GetNewValue<WindowState>() == WindowState.Maximized)
        {
            /// Get the screen from the window.
            var screen = Screens.ScreenFromWindow(this);
            /// This is the part where we check if the actual height is more than the working area cos that would
            /// mean the window has gone over the taskbar.
            if (screen.WorkingArea.Height < ClientSize.Height)
            {
                /// We set the client size of our window to be exactly the size of our working area.
                ClientSize = screen.WorkingArea.Size.ToSize(screen.Scaling);
                /// This is the last piece of the puzzle. If we maximize the Window by setting the state
                /// then this position will be correct. But, if the state is set as a result of dragging the window
                /// to the top then the position will most likely be less then 0 ( it will be (-7,-7) in our case).
                if (Position.X < 0 || Position.Y < 0)
                    Position = screen.WorkingArea.Position; // <-- This is needed because you might have your taskbar in a different position (Left | Right | Top | Bottom).
            }
        }
    }
});

I really hope Avalonia solves this issue.

Hey, thanks for this! I just tested it and it almost works perfectly.

One thing I noticed; when you check the height it should be multiplied by the screen scale. It didn't work on a 4K monitor because the check failed.

if (screen.WorkingArea.Height < ClientSize.Height * screen.Scaling) {
  // . . .
}

Visual it looks fine, but it seems to restrict actually using the taskbar. I'll mess around with it and see if I can fix that issue.

Thanks again for the research on this!

ArchLeaders · 2023-10-04T18:36:39Z

Visual it looks fine, but it seems to restrict actually using the taskbar. I'll mess around with it and see if I can fix that issue.

The taskbar seems to work fine if the window position is anything greater than 0, 0. I.e. if the taskbar is not docked to the bottom, or the position is hardcoded to 0, 1 or something.

I don't know enough about how windows work to say why this happens, but maybe it will be insightful to someone else.

rprimora-pricer · 2023-10-05T05:05:56Z

@ArchLeaders good catch on scaling. I'll check it out.

I am not sure about the usage of taskbar. What do you mean by this?

ArchLeaders · 2023-10-05T18:29:10Z

I am not sure about the usage of taskbar. What do you mean by this?

Might be a condition of my setup, but when the window position (this.Position) is set to PixelPoint(0, 0) I can't click on the taskbar (as if there is a clear panel covering it). There is also a small 1px-wide white line lining the left side of the taskbar:

Edit

For some reason I thought it worked if I set SystemDecorations="None", but it doesn't. Only the white line disappears.

timunie · 2023-10-05T18:54:01Z

@ArchLeaders how does latest nightly look for you?

Also probably check what FluentAvalonia does to get AppWindow working on Windows. They did a heavy lifting to get it somewhat work.

ArchLeaders · 2023-10-05T19:04:42Z

@ArchLeaders how does latest nightly look for you?

~~Can't seem to connect to https://nuget-feed-nightly.avaloniaui.net/api/download/symbols.~~

Edit

Nevermind, just needed to deleted and re-add the source instead of updating.

ArchLeaders · 2023-10-05T19:15:34Z

Latest nightly has the same issue as >11.0.1, there's a weird white border around the window and sizing isn't applied.

With this hack, sizing is weirdly off when dragging to fullscreen.

Clicking the maximize button (with and without the hack) results in it having about 7-8px of padding on the inside of the border.

Dragging to fullscreen without the hack seals it to the edge of the screen (without the 7-8px cutoff that it had previously)

(My other monitor is in the screenshot as a reference to the taskbar)

timunie · 2023-10-05T19:29:02Z

is there any minimal sample I can check on my computer?

ArchLeaders · 2023-10-06T02:18:31Z

Not currently, but I can put one together pretty quick.

ArchLeaders · 2023-10-06T18:58:16Z

@timunie I created a minimal reproduction using the latest nightly, hope this helps:

https://github.com/ArchLeaders/AvaloniaBorderOnlyWindow

Thanks for looking into this :D

rprimora-pricer · 2023-10-09T06:26:29Z

Latest nightly has the same issue as >11.0.1, there's a weird white border around the window and sizing isn't applied.

If you are refering to the white border on top part of the Window, isn't this the ExtendClientAreaTitleBarHeightHint set to something above 0?

ArchLeaders · 2023-10-09T07:26:44Z

If zou are refering to the white border on top part of the Window, isn't this the ExtendClientAreaTitleBarHeightHint set to something above 0?

Yes I am refering to that, I don't think that's the case though. Setting it to 0 has the same effect.

rprimora-pricer · 2023-10-09T07:30:09Z

@ArchLeaders Can you try and set it to -1?

timunie · 2023-10-09T07:36:26Z

<Window x:Class="AvaloniaBorderOnlyWindow.ShellView"
        xmlns="https://github.com/avaloniaui"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        Title="ShellView"
        Width="400"
        Height="400"
        d:DesignHeight="450"
        d:DesignWidth="800"
+       ExtendClientAreaChromeHints="SystemChrome"
+       ExtendClientAreaToDecorationsHint="True"
        SystemDecorations="BorderOnly"
        mc:Ignorable="d">

That works for me at least

ArchLeaders · 2023-10-09T07:36:28Z

@ArchLeaders Can you try and set it to -1?

@rprimora-pricer Same effect with ExtendClientAreaTitleBarHeightHint="-1".

ArchLeaders · 2023-10-09T07:37:28Z

<Window x:Class="AvaloniaBorderOnlyWindow.ShellView"
        xmlns="https://github.com/avaloniaui"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        Title="ShellView"
        Width="400"
        Height="400"
        d:DesignHeight="450"
        d:DesignWidth="800"
+       ExtendClientAreaChromeHints="SystemChrome"
+       ExtendClientAreaToDecorationsHint="True"
        SystemDecorations="BorderOnly"
        mc:Ignorable="d">

That works for me at least

Oh yeah that does work. I wonder why I never tried that before.

ArchLeaders · 2023-10-09T07:39:03Z

Still has an issue with resizing, but at least BorderOnly works.

rprimora-pricer · 2023-10-09T07:39:56Z

What issues you have with resizing?

ArchLeaders · 2023-10-09T07:40:49Z

Same as here: #11685 (comment)

(Taskbar is not clickable when dragging to fullscreen)

timunie · 2023-10-09T07:43:56Z

then please update your minimal sample to reproduce the mentioned issue.

ArchLeaders · 2023-10-09T07:45:42Z

Changes should be synced on github.

Now the main button changes the window state from the code behind (which works as expected)

But dragging with window to the fullscreen (or Win + ArrowUp) disallows the use of the taskbar.

rprimora-pricer · 2023-10-10T06:34:25Z

Same as here: #11685 (comment)

(Taskbar is not clickable when dragging to fullscreen)

Oh, I just saw what you meant by it. The hack does indeed fix the sizing but for some reason the Taskbar is not functioning. It is curious behavior.

Feels like a fullscreen gone wrong. I say this because normally in Windows to go fullscreen all you have to do is maximize the screen and set its bounds to be the same as the screen size. Windows will then hide the taskbar automatically. In our case, without the hack, when you drag a window for maximize same will happen.

timunie · 2023-10-10T10:44:05Z

can't reproduce using Windows 11 and your Button, but see the issue using [Win]+[Arrow Up]. Strange issue.

ArchLeaders · 2023-10-10T21:54:04Z

can't reproduce using Windows 11 and your Button, but see the issue using [Win]+[Arrow Up]. Strange issue.

Yes, the button works correctly on my end too.

rprimora-pricer · 2023-10-11T06:44:22Z

I found some more workarounds :)

Try adding this to a static class somewhere.

public static class WindowHelper
{
	[Flags]
	private enum SetWindowPosFlags : uint
	{
		HideWindow = 128,
		ShowWindow = 64
	}

	[DllImport("user32.dll", SetLastError = true)]
	private static extern int SetWindowPos(IntPtr hWnd, IntPtr hWndInsertAfter, int x, int y, int cx, int cy, uint uFlags);

	public static void FixAfterMaximizing(IntPtr hWnd, Screen screen)
	{
		SetWindowPos(hWnd, IntPtr.Zero, screen.WorkingArea.X, screen.WorkingArea.Y, screen.WorkingArea.Width, screen.WorkingArea.Height, (uint)SetWindowPosFlags.ShowWindow);
	}
}

Then in that workaround that I gave you add this:

this.GetPropertyChangedObservable(WindowStateProperty).AddClassHandler<Visual>((t, args) =>
{
    /// I am doing this only for Windows.
    if (OperatingSystem.IsWindows())
    {
        /// If the state is maximised we will enter our code block.
        if (args.GetNewValue<WindowState>() == WindowState.Maximized)
        {
            /// Get the screen from the window.
            var screen = Screens.ScreenFromWindow(this);
            /// This is the part where we check if the actual height is more than the working area cos that would
            /// mean the window has gone over the taskbar.
            if (screen.WorkingArea.Height < ClientSize.Height * screen.Scaling) // <- Part with scaling is your suggestion
            {
                /// We set the client size of our window to be exactly the size of our working area.
                ClientSize = screen.WorkingArea.Size.ToSize(screen.Scaling);
                /// This is the last piece of the puzzle. If we maximize the Window by setting the state
                /// then this position will be correct. But, if the state is set as a result of dragging the window
                /// to the top then the position will most likely be less then 0 ( it will be (-7,-7) in our case).
                if (Position.X < 0 || Position.Y < 0)
                {
                    Position = screen.WorkingArea.Position; // <-- This is needed because you might have your taskbar in a different position (Left | Right | Top | Bottom).
                    WindowHelper.FixAfterMaximizing(TryGetPlatformHandle().Handle, screen); /// <- Make the call here
                }
            }
        }
    }
});

I tried it on many screens and it works. Before it worked only on primary screen.

timunie · 2023-10-11T08:26:26Z

@rprimora-pricer I think instead of searching for several workarounds, it would be better to fix it in source. So if you want to, do this:

Add your sample to src/samples/Sandbox
Apply the "fix" in Win32 project
File a PR if you found a valid fix

Still up to you, if you want to do a PR. I don't want to force you. Any help is appreciated ❤️

emmauss · 2023-10-12T17:22:17Z

could you test with, #13228

ArchLeaders · 2023-10-13T20:06:15Z

could you test with, #13228

@emmauss doesn't seem to have any effect.

ArchLeaders mentioned this issue Jun 8, 2023

Drag/Dropping Window to Maximized Cuts Taskbar NX-Editor/NxEditor#1

Closed

MikeCodesDotNET added the bug label Jul 3, 2023

maxkatz6 added the area-x11 label Jul 9, 2023

timunie added the os-windows label Oct 10, 2023

emmauss mentioned this issue Jul 12, 2024

Win32 - Fix window size and position for border only window when maximized through OS means #16297

Merged

3 tasks

maxkatz6 closed this as completed in #16297 Jul 17, 2024

Drag/Dropping Window to Maximized Cuts Taskbar (BorderOnly Deco) #11685

Drag/Dropping Window to Maximized Cuts Taskbar (BorderOnly Deco) #11685

Comments

ArchLeaders commented Jun 7, 2023

Discussed in #11222

ArchLeaders commented Jun 7, 2023 • edited Loading

timunie commented Jun 7, 2023

ArchLeaders commented Jun 8, 2023

cyraid commented Jun 14, 2023

rprimora-pricer commented Jun 21, 2023

ApaulMyLittleAirport commented Jul 9, 2023

rprimora-pricer commented Sep 22, 2023 • edited Loading

ArchLeaders commented Oct 4, 2023

ArchLeaders commented Oct 4, 2023 • edited Loading

rprimora-pricer commented Oct 5, 2023

ArchLeaders commented Oct 5, 2023 • edited Loading

*Edit*

timunie commented Oct 5, 2023

ArchLeaders commented Oct 5, 2023 • edited Loading

*Edit*

ArchLeaders commented Oct 5, 2023

timunie commented Oct 5, 2023

ArchLeaders commented Oct 6, 2023

ArchLeaders commented Oct 6, 2023

rprimora-pricer commented Oct 9, 2023 • edited Loading

ArchLeaders commented Oct 9, 2023

rprimora-pricer commented Oct 9, 2023 • edited Loading

timunie commented Oct 9, 2023

ArchLeaders commented Oct 9, 2023

ArchLeaders commented Oct 9, 2023

ArchLeaders commented Oct 9, 2023

rprimora-pricer commented Oct 9, 2023

ArchLeaders commented Oct 9, 2023

timunie commented Oct 9, 2023

ArchLeaders commented Oct 9, 2023 • edited Loading

rprimora-pricer commented Oct 10, 2023

timunie commented Oct 10, 2023

ArchLeaders commented Oct 10, 2023

rprimora-pricer commented Oct 11, 2023 • edited Loading

timunie commented Oct 11, 2023

emmauss commented Oct 12, 2023

ArchLeaders commented Oct 13, 2023

ArchLeaders commented Jun 7, 2023 •

edited

Loading

rprimora-pricer commented Sep 22, 2023 •

edited

Loading

ArchLeaders commented Oct 4, 2023 •

edited

Loading

ArchLeaders commented Oct 5, 2023 •

edited

Loading

Edit

ArchLeaders commented Oct 5, 2023 •

edited

Loading

Edit

rprimora-pricer commented Oct 9, 2023 •

edited

Loading

rprimora-pricer commented Oct 9, 2023 •

edited

Loading

ArchLeaders commented Oct 9, 2023 •

edited

Loading

rprimora-pricer commented Oct 11, 2023 •

edited

Loading