I just tried running our v2019.1 build 685 Sample Browser on a remote desktop connection and maximized both the main Window (which uses WindowChrome) and a RibbonWindow and neither seemed to show any problems. Can you give us more detailed steps on how to reproduce this, and verify that you are on build 685?
We have the latest 685 version. I have attached a screenshot of the problem reproduced with the SampleBrowser.exe
Notice the maximized window is shifted to the right and to the bottom.
Also notice that this is specific to RemoteApp and does not occur when using Remote Desktop to remote into the full desktop.
[Modified 3 years ago]
I haven't heard of that tool before. If you'd like to email our support address and mention this thread, we can send you links to the various v2019.1 68x builds so you can run through them. That way we can narrow down which build's changes caused this issue.
Are you able to recreate the issue?
No, that URL doesn't provide much info and I'm not sure we have the infrastructure for RemoteApp anyhow.
As mentioned, please write our support address and we can send you other builds so that you can try and narrow down which build's changes triggered the issue.
I have tried the different versions and then figured out that it is not as what our QA team has reported.
None of the versions works. I even went as far as going back to our first version which uses Actipro 18.1.672.0 and that does not work either.
So the conclusion is that this is always a problem when running as a RemoteApp.
There are three things I have found out though.
1. The Office themes and the Aero theme do not have the problem.
2. Once the Office themes or the Aero theme is used, if we dynamically switch to different theme, for example, metrowhite, the metro theme will no longer have the problem either.
3. MetroLight is a problematic theme that we have to force the theme to MetroWhite if it is the selected theme.
So currently my workaround, if running as RemoteApp is detected (and if the selected theme is not one of the Office theme nor Aero), we move the Window off the screen by setting the Left to -10000, load the OfficeSilver theme and then at ContentRendered, load the original selected theme and restore the Left position. This is kind of ugly but it works.
Of course, I would like to have a real solution from Actipro.
Do you specifically set the MetroLight theme at app startup, or do you let the system auto-select it since it's the default theme?
I noticed from your screenshot that the distance it's offset is 8 pixels, which is the default Windows system's window border resize thickness. Then I remembered that we have a trigger in our Window style to set our outer Grid's (in the template) Margin to the WindowChrome.SystemResizeBorderThickness value (which is 8 pixels) when the window is maximized and the taskbar is not auto-hidden. When building a custom Window chrome in WPF, there are all kinds of side effects that happen based on various Windows versions, taskbar settings, and so on. We need that trigger normally because due to some Win32 API we have to do for the custom chrome, a maximized Window would appear past the monitor bounds by the SystemResizeBorderThickness amount. I wonder if that's what we're running into here with RemoteApp.
I would suggest that if you detect you are in a RemoteApp, try getting the root Grid in the Window's template. Our Window template has an AdornerDecorator as its visual root and then the root Grid is the child of that. See if you can force the root Grid's Margin to 0 when maximized.
That being said, I'm not sure why switching themes to something else and back would affect that at all since the trigger fires in all the themes. The main difference between Metro and other themes is that Metro has the outer glow shadow, which is a separate Window that follows the main Window. But that shouldn't really affect the main Window's maximized state at all. The default Window border thickness is different in that theme from Aero. The other thing is that Metro themes will not set a Win32 clip region on the Window to start with, however Aero themes must because they have rounded corners. That is the other thing that I wonder could oddly contribute to this. Once an Aero theme (and old Office themes are effectively Aero themes) is activated, clip regions are adjusted when the Window's position or state change from that point forward.
Thanks for the information. I will try what you have suggested.
It doesn't matter. I had tried setting in specifically as "MetroLight" or leave the theme as null.
Just to verify, you tried adjusting the root Grid's Margin to 0, right?
Let's do something to trigger the clip region logic instead. Set this attached property (themes:ThemeProperties.CornerRadius="1") on your Window. See if that makes any difference in stopping the problem without requiring the theme change. That should trigger the clip region code to execute that normally executes in Aero themes only.
Wow that works!
I can live with that 1 pixel round corner for the RemoteApp.
Thank you so much!
After the window is initialized and displayed you might be able to set it back to zero again too. I think the key is having it be a non-zero value (in at least one corner) to start with.
Ok, thank you for the information again.
We just observed another odd behavior. If you minimize a window and restore it, something becomes off.
This happens to all themes.
It looks like there is a transparent border and the window is shifted to the right.
And once that happens, the only way to get it correct again is to relaunch.
Is there any way to force something to be reinitailized to fix this?
[Modified 3 years ago]
Is this happening on normal PCs or only in RemoteApp?
If in Remoteapp, I'm curious to see what happens if you did the trick mentioned above where you ensure the root Grid's Margin is zero.
All these I am reporting are specific to RemoteApp only.
Ok, I tried setting the grid margin to zero and that seems to be working visaully but if I do a screen capture, I can still see the transparent border but I guess I can live with that. Also, I will have to reset the margin to it's original value when the screen is maximize.
I have a final issue. If I minimize a maximized screen and restore it, then the shift right and down 8 pixels reappears. Restore the window to normal and maximize it again, the problem will go away. Any idea how to address this one?
It almost seems like you might need to clone our default template used for Window and would need to remove the Trigger that alters the Margin on Maximized state. That seems to be leading to numerous issues in RemoteApp for whatever reason. I believe your company has WPF Studio so you should be able to download the default styles/templates from your account. The default template is in "Shared\Themes\Includes\Styles\Native\Window.xaml".
Ok, thank you very much for your help.
Please log in to a validated account to post comments.