New WindowChrome does not work correctly on Windows 7

[batzen]

• Minimize/Maximize/Close is missing (Office 2010 and Windows 8 theme)
• Maximized window: Wrong borders (margin around window content, all themes)
• Maximized window: Black corners (Office 2010 and Windows 8 theme)

[maurosampietro]

Now when docking on top of the screen or maximizing on Windows 7 with Office 2010 themes, the glass frame turns black

[batzen]

I can't reproduce this on my windows 7 laptop.

[maurosampietro]

After some research i'm sure the problem is related to multimonitor configuration.
I'm working with extended screens. The problem is not showing if you clone screens.

Turns out the problem is not showing up on the current master branch, but only on the develop one. This means somehow the problem can be solved.

Windows 8 theme:

Office 2010 theme:

[maurosampietro]

Since you may not have another monitor, i'm looking for a solution in ControlzEx code right now.

[batzen]

I guess it can be fixed by reapplying the ugly window move workaround.
I removed that workaround because I wanted to find a solution which does not require these ugly workarounds.
As the issue does not surface on windows 10 with multiple monitors I might re-add the workaround by encapsulate it in a OS version check.
Will try to reproduce the issue on my laptop using multiple monitors.

// WindowChrome handles the size false if the main monitor is lesser the monitor where the window is maximized
// so set the window pos/size twice
var monitor = NativeMethods.MonitorFromWindow(this.handle, (uint)MonitorOptions.MONITOR_DEFAULTTONEAREST);
if (monitor != IntPtr.Zero)
{
    var monitorInfo = NativeMethods.GetMonitorInfoW(monitor);

    var x = this.IgnoreTaskbarOnMaximize ? monitorInfo.rcMonitor.Left : monitorInfo.rcWork.Left;
    var y = this.IgnoreTaskbarOnMaximize ? monitorInfo.rcMonitor.Top : monitorInfo.rcWork.Top;
    var cx = this.IgnoreTaskbarOnMaximize ? Math.Abs(monitorInfo.rcMonitor.Right - x) : Math.Abs(monitorInfo.rcWork.Right - x);
    var cy = this.IgnoreTaskbarOnMaximize ? Math.Abs(monitorInfo.rcMonitor.Bottom - y) : Math.Abs(monitorInfo.rcWork.Bottom - y);

    // Fixes nasty bug when window is partially covered by taskbar and WindowStyle is not none
    // - move x by 1
    // - move back to originally desired location
    if (this.AssociatedObject.WindowStyle != WindowStyle.None)
    {
        NativeMethods.SetWindowPos(this.handle, new IntPtr(-2), x + 1, y, cx, cy, SWP.SHOWWINDOW);
    }

    NativeMethods.SetWindowPos(this.handle, new IntPtr(-2), x, y, cx, cy, SWP.SHOWWINDOW);
}

[maurosampietro]

Ok, i also found this scenario was already handled here:

https://github.com/ControlzEx/ControlzEx/blob/7cbcd9e3fff7745654f6ea4ce43ce50902ed6499/src/ControlzEx/Microsoft.Windows.Shell/WindowChromeWorker.cs#L750

Can i consider this workaround reintroduced?

Since you were trying to find another way to solve the problem i'd like to say i noticed that when maximing in this context, the window overflows to the other screen by some pixel (from code i saw something like 8 pixels). Visual studio google chrome etc, immediately resize the window to be contained on the screen and this may be the key to solve the problem. I tried to do this with no result though... ControlzEx is rather complex

[batzen]

The comment above that code, talking about the workaround, is from Microsoft.
The code contained in ControlzEx which is located in the Microsoft.Windows.Shell folder is copied from referencesource and has just fixes applied by jan karger and me.

If you use NonClientFrameEdges, which is mentioned in the comment, you get black space depending on which one you choose. So using it is no solution we can use.

I will have a look at this issue as soon as I got time.

[maurosampietro]

This problem is still there, nothing changed.
Please wait for issue solved confirmation before closing.

[batzen]

I tested it on windows 7.
Closing happens automatically when i commit my changes.

How did you test it? By using the nuget package? The current nuget version does not contain the fix. Only the source version does.

[maurosampietro]

i downloaded both controlzex and ribbon linked and tried.

[batzen]

That's strange.
Will have a look at it again as soon as I got time.

[batzen]

I tested this on Windows 7 again by using the showcase application from https://ci.appveyor.com/api/buildjobs/lbkkf8o3jh1y519f/artifacts/build/Fluent.Ribbon.4.0.0-dev0323.zip and I can't see any issues.
Could you try the same and tell me if you are seeing any issues?

[maurosampietro]

Sadly yes the problem is still there minimize/maximize/close buttons even disapper and titlebar turns black. Is there any way i can help you reproducing this? How are your monitors set up?

[batzen]

Laptop display: 1600x900
External display: 1920x1080 (marked as primary screen)
Windows 7 SP1 64 Bit
.NET 4.5.2

The issue you describe is exactly what happened on my laptop before i applied the fixes.

Honestly I don't know how you could help me reproduce it...
The problem with these WindowChrome issues is that i can't fix them when i can't reproduce them because fixing them always involves a lot of trial and error...

What might help would be a screen record of the issue and some spy++ recording.

[maurosampietro]

From Fluent.Ribbon's point of view i'm glad the library do not show this problem sistematically. I will investigate this next week in details and let you know.
Have a good weekend

Mauro Sampietro
Inviato da iPhone

Il giorno 22 gen 2016, alle ore 16:02, Bastian Schmidt notifications@github.com ha scritto:

Laptop display: 1600x900
External display: 1920x1080 (marked as primary screen)
Windows 7 SP1 64 Bit
.NET 4.5.2

The issue you describe is exactly what happened on my laptop before i applied the fixes.

Honestly I don't know how you could help me reproduce it...
The problem with these WindowChrome issues is that i can't fix them when i can't reproduce them because fixing them always involves a lot of trial and error...

What might help would be a screen record of the issue and some spy++ recording.

—
Reply to this email directly or view it on GitHub.

[sfmc]

I'm just trying out the Fluent Library, and might be experiencing the same bug. Thought I'd add some comments in case it helps. Specifically: when I drag and dock the window border to the top of my screen (to maximize the application), the window does not maximize correctly.

As you can see, the window is cut-off (right and bottom), and seems to have a sense of memory to where its prior rightmost position was. It makes it easier to reproduce if you double click on the top border to make the window fit the screen vertically first.

This bug is easily repeatable, and occurs with the sample applications from Fluent.Ribbon.3.6.1.236, on windows 8.1, both the .net 4.0 and 4.5 applications. I have two monitors, 1920x1080 and 1920x1200. I also use a virtual desktop manager, and if I toggle desktops and toggle back, the application looks perfect. This makes me thing there is some sort of global refresh/repaint that is missing on the maximize operation.

I would love to use this library - it looks great!

[maurosampietro]

@sfmc please try the last developer version. You should not experience this problem with the theme you are using in the screenshot.

Mauro Sampietro
Inviato da iPhone

Il giorno 27 gen 2016, alle ore 15:46, sfmc notifications@github.com ha scritto:

I'm just trying out the Fluent Library, and might be experiencing the same bug. Thought I'd add some comments in case it helps. Specifically: when I drag and dock the window border to the top of my screen (to maximize the application), the window does not maximize correctly.

As you can see, the window is cut-off (right and bottom), and seems to have a sense of memory to where its prior rightmost position was. It makes it easier to reproduce if you double click on the top border to make the window fit the screen vertically first.

This bug is easily repeatable, and occurs with the sample applications from Fluent.Ribbon.3.6.1.236, on windows 8.1, both the .net 4.0 and 4.5 applications. I have two monitors, 1920x1080 and 1920x1200. I also use a virtual desktop manager, and if I toggle desktops and toggle back, the application looks perfect. This makes me thing there is some sort of global refresh/repaint that is missing on the maximize operation.

I would love to use this library - it looks great!

—
Reply to this email directly or view it on GitHub.

[sfmc]

Thanks, I'll try this out later - once I install VS2015

[batzen]

You can also download the latest preview binaries from https://ci.appveyor.com/project/batzen/fluent-ribbon/build/artifacts

[batzen]

@maurosampietro Could you try to reproduce your issue with the latest source version from the develop branch? I fixed some things in ControlzEx.

[sfmc]

Hey, just tested out 4.0.0-dev0339 via appveyor, the original issue I took a picture of appears to be fixed! Nice!

Might be a separate issue, but it appears as though there is a border around the perimeter of the test application. I can see it through my start bar, and on my second monitor to the left. It also might appear above and to the right of the application if I had more monitors. The picture below higlights it in red again.

Let me know if this helps

[sfmc]

Oh, sorry, just saw this wasn't directed at me!

[batzen]

No worries. I appreciate more testers!

[batzen]

Will have a look at that issue as soon as I got a Windows 8 machine I can test on...
Getting it right on every OS is hard, especially when the bugs only surface with multiple monitors.

[maurosampietro]

I downlaoded https://ci.appveyor.com/api/buildjobs/tloco36v0bk4d3tj/artifacts/build/Fluent.Ribbon.4.0.0-dev0339.zip

Problem still there.

I can say the left black border issue @sfmc is showing you in his last post is what causes my problem to show up. If @sfmc tries to use Office2010 with dwm he will get my same issue. Now he is not noticing because he is using a glassless theme.

@batzen Do you see that black border too? If you do please try to fix that and i'm sure everything will work. The last stable release 3.6.1.236 did not suffer these two problems.

[batzen]

No black borders on win 7 & 10.

Are you both using win 8?

Stable does not suffer because the windowchrome impl is a different one in develop branch.

[maurosampietro]

I'm on 7

[batzen]

Will test it again then...

[maurosampietro]

@batzen while experimenting which various screen settings (from windows 7 screen settings) i ended up fixing this issue. Now i have troubles getting the bug back!
I'll investigate the right way to reproduce this bug and let you know, i'm close.
Thank you.

[batzen]

As i said, had no issues on my win7 machine. Getting this right in every config and os is a nightmare...

[batzen]

Have to revert what i said. Also got a black bar on Windows 7... Will investigate.

[maurosampietro]

Ok i think i found the repro:
Provided you have more than one monitor go to windows screen resolution settings and set them on different height resolution to make the bug show. If same height bug is latent.

Interesting enough the result is the width of the window overflows showing a black border as also mentioned by @sfmc.

Example settings to show the bug:
monitor 1: 1366x768
monitor 2: 1280x1024

Example settings that do not show the bug:
monitor 1: 1366x768
monitor 2: 1280x768

Let me know.

[batzen]

@sfmc @maurosampietro Could you test again with https://ci.appveyor.com/api/buildjobs/45fnxxmhlaj7ipu0/artifacts/build/Fluent.Ribbon.4.0.0-dev0341.zip

[maurosampietro]

Problem solved 👍

[sfmc]

I can see a brief flicker when maximized, but otherwise, looks great to me!

[sfmc]

(the flicker is transient and only happens 1 time)

[batzen]

Ok, i can live with it flickering one time and with it still rendering round edges while maximized on windows 7.
Will close this issue then.

[mezzalunaj]

Hey guys. I'm having this same issue (black border with missing minimize/maximize/close buttons) sporadically on 4 PCs here. Sometimes, if they close and reopen the application, the problem goes away. We have a second WPF application using version 3.0.3.0 of the Fluent ribbon and the issue is also there but occurs more frequently.

Two of the users have only one monitor. 3 users are on Windows 7; the 4th is on Windows 10. I'm currently referencing ControlzEz version 2.0.0-dev 9 dated 2/26/16 and Fluent v 4.0.0.

Please help :)

Thanks!

J.D.

[batzen]

@mezzalunaj Will release v4.0.3, which depends on ControlzEx 2.0.1.61, in about 2 hours. Please try to reproduce your issue with that version.
If you encounter any issues with that version please open a new issue. Adding comments to a closed issue makes tracking issues more difficult for me. Feel free to reference closed issues in new issues you open.