DialogHost | Dialog no longer visible if disconnected-then-reconnect to VM running application

[tblong]

Bug explanation

Steps to reproduce

Used a hyper-v VM running Win 10 21H2 build 19044.1466 + the MainDemo.Wpf app latest commit 607ee6a:

1. Transfer the MainDemo.Wpf app to the VM
2. Open the MainDemo.Wpf app and navigate to Dialogs
3. Click "Run Code" under Sample 3
4. While the dialog is visible, close the window which disconnects from the VM but leave the VM running
5. Reconect to the VM and login.
6. Notice that the dialog is no longer visible, the obscured background of the app is still greyed out and present, and nothing in the app being overlaid by the DialogHost responds to user input.

Screenshot for step 3 above:

Screenshot for step 6 above:

The short story of them problem seems to be: If the user gets disconnected from a remote session AND a dialog is visible when the disconnect occurs, then the user on reconnect will see a greyed out screen and no visible dialog on reconnect. Anyone ran into this and is there a known workaround?

Version

v4.7.1

[tblong]

@Keboo I'm able to help out here and contribute to fixing this. Not much experience troubleshooting controls like this directly though. Is this a situation where I should install VS on the VM in question and run the app to see whether certain events are not getting fired or state not updating while trying to reproduce the issue? I'll likely need just a bit of guidance on where to look first.

[Keboo]

@tblong that would be really helpful. Some suggestions.

First, take a look at this blog post on how the DialogHost works. Specifically, it appears that the bug above is the Popup control being hidden but the DialogHost not being notified of it.

I have a hunch that if you watch the Loaded/Unloaded events what you will see is when you disconnect your session the controls are unloaded. Likewise reconnecting likely triggers the Loaded event but the Popup control is not moved back into the correct state (this is just a guess). These would be the first two events I would look into.

Also keep an eye on the IsOpen property on the DialogHost as well as the IsOpen on the Popup control. A second theory I have is that because the Popup's IsOpen is set as part of the VisualStateManager it is possible that those are simply not re-triggering. It is possible that we might need to call VisualStateManager.GoToState during some event when the RDP session is reconnected.

You can certainly install VS on the VM if that makes running this easier. It might also make sense to modify the app to write a log file since I am not sure how the debugger will respond when you disconnect your RDP session.

Happy to provide guidance, on what you find.

[peijiehuang]

@tblong that would be really helpful. Some suggestions.

First, take a look at this blog post on how the DialogHost works. Specifically, it appears that the bug above is the Popup control being hidden but the DialogHost not being notified of it.

I have a hunch that if you watch the Loaded/Unloaded events what you will see is when you disconnect your session the controls are unloaded. Likewise reconnecting likely triggers the Loaded event but the Popup control is not moved back into the correct state (this is just a guess). These would be the first two events I would look into.

Also keep an eye on the IsOpen property on the DialogHost as well as the IsOpen on the Popup control. A second theory I have is that because the Popup's IsOpen is set as part of the VisualStateManager it is possible that those are simply not re-triggering. It is possible that we might need to call VisualStateManager.GoToState during some event when the RDP session is reconnected.

You can certainly install VS on the VM if that makes running this easier. It might also make sense to modify the app to write a log file since I am not sure how the debugger will respond when you disconnect your RDP session.

Happy to provide guidance, on what you find.

Thanks for sharing, great programmer