Window content remains highlighted after mouse leaves window

[ravigneaux-1]

Describe the bug When opened as a modal window/dialog, the "elements" and contents of a MetroWindow keep their highlighted mouseover appearance when the mouse cursor leaves the window. This happens only if the mouse cursor "lands" on an other application window in the background, but not if the new destination is unoccupied (see attached animations for more clarity)!

I first noticed this with the regular window minimize/maximize/close buttons - but I can observe the same behavior with a regular button within the window content area (the margin to the window border needs to be reasonably small and you have to move the mouse cursor a little bit speedy), so I dare to guess that it happens with any kind of controls.

The problem only appears if the window is opened as a dialog (Window.ShowDialog()), but not if opened as a regular window (Window.Show())

To Reproduce Steps to reproduce the behavior:

1. Implement two regular MetroWindows (let's name them "MainWindow" and "Window1")
2. Add a Button to the main window and open Window1 as a modal window/dialog on the Click event of the button:

   private void Button_Click(object sender, RoutedEventArgs e)
   {
   Window1 window1 = new Window1();
   window1.Owner = this;
   window1.ShowDialog();
   }

3. Run the code and click the button on the main window.
4. Move and resize Window1 so that it overlaps the main window.
5. Hover the mouse over the close button of Window1 and observe its highlighted appearance.
6. Quickly move the mouse cursor off the close button and onto the main window in the background.
7. The close button of Window1 remains highlighted until the mouse cursor enters Window1 again (not necessarily via its close button, just anywhere)

Expected behavior All window elements and contents return to their regular, non-highlighted appearance after the mouse cursor has left the window.

Screenshots

• Moving mouse to unoccupied area: No issue

• Moving mouse to area occupied by other application window: Unexpected behavior

Environment(please complete the following information):

• MahApps.Metro version v1.6.5
• OS: Win10
• Visual Studio 2017 15.9.11
• .NET Framework 4.6.1

[punker76]

@MisterNobody123 This works on my machine™ Latest v1.6.5 and current source

Can you check your RenderCapability.Tier?

private static string CollectRenderCapabilityTier()
{
    var tier = RenderCapability.Tier / 0x10000;

    switch (tier)
    {
        case 0:
            return "0/2 - No graphics hardware acceleration. The DirectX version level is less than version 7.0.";
        case 1:
            return "1/2 - Partial graphics hardware acceleration. The DirectX version level is greater than or equal to version 7.0, and lesser than version 9.0.";
        case 2:
            return "2/2 - Most graphics features use graphics hardware acceleration. The DirectX version level is greater than or equal to version 9.0.";
    }

    return "Unknown Rendering Tier";
}

[ravigneaux-1]

Hello @punker76 ! Thanks for the quick reply! Assuming that you move the mouse cursor fast enough (it's hard to tell from the GIFs), it's confusing that it works for you... 🤔 I have run your code snippet and end up in case 2 (hardware acceleration, DirectX version >= v9.0)

[ravigneaux-1]

Can anyone else reproduce this behavior?

[timunie]

Hi @MisterNobody123

can you provide the sample shown in your gif and provide more Information about your system (OS, .NET-Version, Graphic-Card) ? I will try to reproduce it with the same program as you have.

Happy coding Tim

[ravigneaux-1]

Hi @timunie

I have added the Visual Studio project I used for demonstration to a repository and sent you an invitation. Please let me know if access works and the project builds properly.

I observe the mentioned behavior on a Windows 10 machine with Intel(R) HD Graphics 630. The application targets .NET framework v4.6.1. I can also observe the same behavior on a Windows 7 machine (for which I unfortunately don't have the graphics card specification handy in this very moment)

[timunie]

@MisterNobody123 thank you. I'll have a look soon. Please invite @punker76 as well.

Happy coding Tim

[ravigneaux-1]

Invitation sent to @punker76 Thanks in advance to both of you! 👍

[timunie]

Hi @MisterNobody123 ,

with your example I can reproduce your issue. If I comment out the line below in your MainWindow.xaml.cs the issue is gone for me.

window1.Owner = this;

This is not the solution for your problem but I want to leave the link below because I really like it for Dialogs: SimpleChildWindow

Happy coding Tim

[punker76]

@MisterNobody123 I can reproduce this with MahApps BUT also without MahApps. So IMO it's not a MahApps bug...

[ravigneaux-1]

@timunie Thanks! I'll have a look at it later... @punker76 Oh, I didn't realize this at all...! I'm gonna try to reproduce this later and maybe report to Microsoft...

[ravigneaux-1]

I was able to reproduce the behavior on plain windows (without MahApps.Metro). The big button in the window content shows the issue. However, the window buttons (min/max/close) seem to behave correctly.

Commenting out window1.Owner = this; didn't really fix the problem for me... 🤔 This is confusing... I'm having a look at the SimpleChildWindow now 😉

[ravigneaux-1]

@punker76 Thanks for pointing out that the issue also happens without MahApps.Metro! A two-minute Google search (facepalm) revealed this is a known issue with borderless windows (which, I believe, MahApps.Metro.MetroWindow is...)

Have a look here!

Maybe this solution can be incorporated into a future release of MahApps.Metro? 🤔

[HengWh]

I have a similar problem. And I found that if I didn't set the "GlowBrush" of the main window, everything would be ok. The GlowBrush is from ControlzEx.

I haven't found a solution yet. I hope I can provide you with ideas. Problem will occur in MahApp version is 2.0+