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

Mahapps UI is locked in Dialog Window after re-login #2734

Closed
kopacz0 opened this Issue Nov 3, 2016 · 9 comments

Comments

Projects
None yet
6 participants
@kopacz0

kopacz0 commented Nov 3, 2016

Mahapps UI in Dialog Window is locked when user re-signs in.

Steps to Reproduce

In order to reproduce please use the below sample app:

  • Open Dialog Window from the Main window by clicking "Display Window" button
  • The dialog window is displayed
  • Lock out using Windows+L button
  • Login again
  • Try to enter any text to textbox

Per the attached example. User is not able to enter any text to the textbox. Generally UI is locked. User is able to switch to the second tab, but is not able to return to first tab.

Expected outcome

The textbox and whole UI should not be locked to allow user to use it.

Environment:

  • MahApps.Metro 1.3.0 stable
  • Visual Studio 2015 Community
  • .NET Framework 4.6.1

Demo App

SampleMahapps.zip

@cavando

This comment has been minimized.

Show comment
Hide comment
@cavando

cavando Nov 4, 2016

I am having the same issues, has this been looked at yet?

Environment:

  • MahApps.Metro 1.3.0 stable
  • Visual Studio 2013 Professional
  • .NET Framework 4.0

cavando commented Nov 4, 2016

I am having the same issues, has this been looked at yet?

Environment:

  • MahApps.Metro 1.3.0 stable
  • Visual Studio 2013 Professional
  • .NET Framework 4.0

@punker76 punker76 added the Bug label Nov 4, 2016

@fussmonkey

This comment has been minimized.

Show comment
Hide comment
@fussmonkey

fussmonkey Nov 7, 2016

We see the same issue, if the window is visible when locking the workstation and logging back in, the UI is unresponsive. If I close the window and re-open it, the entire UI is actually transparent, except for the border.

I can fix the issue by minimizing all windows on my workstation (Win+D). At that point, if I open the window again the UI seems back to normal (until the next time I lock the machine).

  • MahApps.Metro 1.3.0 stable
  • Visual Studio 2015 Enterprise
  • .NET Framework 4.5.2

fussmonkey commented Nov 7, 2016

We see the same issue, if the window is visible when locking the workstation and logging back in, the UI is unresponsive. If I close the window and re-open it, the entire UI is actually transparent, except for the border.

I can fix the issue by minimizing all windows on my workstation (Win+D). At that point, if I open the window again the UI seems back to normal (until the next time I lock the machine).

  • MahApps.Metro 1.3.0 stable
  • Visual Studio 2015 Enterprise
  • .NET Framework 4.5.2
@gkinsman

This comment has been minimized.

Show comment
Hide comment
@gkinsman

gkinsman Nov 15, 2016

#2742 is a duplicate of this and an issue I'm seeing too 😃.

To add some more information:

  • Large memory spikes can occur after some time when the window remains active. The memory doesn't seem to be used by the process itself, but on some system thread, perhaps GC.
  • Attaching more monitors/removing monitors appears to fix the issue until next sleep/login.

Cheers

gkinsman commented Nov 15, 2016

#2742 is a duplicate of this and an issue I'm seeing too 😃.

To add some more information:

  • Large memory spikes can occur after some time when the window remains active. The memory doesn't seem to be used by the process itself, but on some system thread, perhaps GC.
  • Attaching more monitors/removing monitors appears to fix the issue until next sleep/login.

Cheers

@gkinsman

This comment has been minimized.

Show comment
Hide comment
@gkinsman

gkinsman Nov 16, 2016

I've found a workaround for this:

window.Loaded += (s, e) =>
{
    var w = (Window) s;
    var src = PresentationSource.FromVisual(w) as HwndSource;
    var target = src.CompositionTarget;
    target.RenderMode = RenderMode.SoftwareOnly;
};

It appears to be some kind of driver issue in windows that's causing hardware rendering to fail when the shell environment is restored. Forcing software rendering for that window solves the issue for me.

Edit: Confirmed that this fix works for the reproduction in the original post.

gkinsman commented Nov 16, 2016

I've found a workaround for this:

window.Loaded += (s, e) =>
{
    var w = (Window) s;
    var src = PresentationSource.FromVisual(w) as HwndSource;
    var target = src.CompositionTarget;
    target.RenderMode = RenderMode.SoftwareOnly;
};

It appears to be some kind of driver issue in windows that's causing hardware rendering to fail when the shell environment is restored. Forcing software rendering for that window solves the issue for me.

Edit: Confirmed that this fix works for the reproduction in the original post.

punker76 added a commit that referenced this issue Nov 19, 2016

@punker76 punker76 added this to the 1.4.0 milestone Nov 19, 2016

@punker76 punker76 self-assigned this Nov 19, 2016

@punker76 punker76 closed this Nov 19, 2016

@punker76

This comment has been minimized.

Show comment
Hide comment
@punker76

punker76 Nov 19, 2016

Member

@kopacz0
@cavando
@fussmonkey
@gkinsman

I think I fixed this with cafa38c
Please test and try latest pre-release 1.4.0-ALPHA029
Thx!

Member

punker76 commented Nov 19, 2016

@kopacz0
@cavando
@fussmonkey
@gkinsman

I think I fixed this with cafa38c
Please test and try latest pre-release 1.4.0-ALPHA029
Thx!

@LuisHCK

This comment has been minimized.

Show comment
Hide comment
@LuisHCK

LuisHCK Dec 4, 2016

I'm upgrade the nuget package to 1.4.0-ALPHA035 and I still have the same bug when re-login.

Environment:

  • MahApps.Metro 1.4.0-ALPHA035
  • VS Comunity
  • .NET Framework 4.5.2
    version
    Note: I tried to resize the window. This is the result

Edit: Confirm @gkinsman's solution works, with some modifications to work with my project

        private void Window_Loaded(object sender, RoutedEventArgs e)
        {
            var w = (Window)sender;
            var src = PresentationSource.FromVisual(w) as System.Windows.Interop.HwndSource;
            var target = src.CompositionTarget;
            target.RenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
        }

LuisHCK commented Dec 4, 2016

I'm upgrade the nuget package to 1.4.0-ALPHA035 and I still have the same bug when re-login.

Environment:

  • MahApps.Metro 1.4.0-ALPHA035
  • VS Comunity
  • .NET Framework 4.5.2
    version
    Note: I tried to resize the window. This is the result

Edit: Confirm @gkinsman's solution works, with some modifications to work with my project

        private void Window_Loaded(object sender, RoutedEventArgs e)
        {
            var w = (Window)sender;
            var src = PresentationSource.FromVisual(w) as System.Windows.Interop.HwndSource;
            var target = src.CompositionTarget;
            target.RenderMode = System.Windows.Interop.RenderMode.SoftwareOnly;
        }
@punker76

This comment has been minimized.

Show comment
Hide comment
@punker76

punker76 Dec 4, 2016

Member

@LuisHCK it looks like you don't use the MetroWindow...

Member

punker76 commented Dec 4, 2016

@LuisHCK it looks like you don't use the MetroWindow...

@gkinsman

This comment has been minimized.

Show comment
Hide comment
@gkinsman

gkinsman Dec 4, 2016

Ah, @LuisHCK I'm using it with Caliburn, so I have a window manager. If you use plain mahapps you'll obviously need to override the loaded event in your MetroWindow as you have :)

gkinsman commented Dec 4, 2016

Ah, @LuisHCK I'm using it with Caliburn, so I have a window manager. If you use plain mahapps you'll obviously need to override the loaded event in your MetroWindow as you have :)

bojanrajkovic added a commit to bojanrajkovic/workbooks that referenced this issue Dec 1, 2017

Windows: Bump MahApps packages to get fix for #115
Bump from our old 1.3.0 to the latest stable, 1.5.0 to pick up the fix
in MahApps/MahApps.Metro#2734.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment