Closed QuantumDeveloper closed 9 years ago
Can't reproduce here. Does this also happen when you try this in the showcase application? Which version are you using? Which theme are you using? Which windows version are you using? Which .NET version are you using?
You can easily reproduce this with the same test app from the last time: https://onedrive.live.com/?cid=650F345C1F75A314&id=650F345C1F75A314%21105
In showcase app this is not reproducible I am using the latest version - 3.3.0 Theme - office 2013 Windows - 8.1 .Net 4.5 But I also use fluent with MA.Metro 1.1.2. and use their MetroWindow as main window.
Still can't reproduce with your application while following your steps. Anything missing?
You must start app, open backstage, maximize window, close backstage and the press maximize button one more time to restore the previous size of the window.
Ah, it's larger than before but it does not freeze.
Yeah, I think it because of Win 7 or something like that. On Win 8.1 cant reproduce freezing hopefully. So, does this ribbon issue or someone elses?
It's larger because:
Regarding windows 7, I can try your sample at work as soon as I got time for that.
Does the freezing only occur when you use the ribbon with the mah metro window?
I didnt try it in other scenarios, but seems that exactly this use case leads to freezing, but here could be also PC configuration, so I would not say, that this is exactly ribbon fault.
But is this a bug or a normal behavior? As for me its unexpected behavior.
Freezing is, of course, considered a bug.
Enlarging the window when the backstage is opened and restoring the window size when closed is the intended behavior but open for discussion if you feel it should be changed.
Maybe you need to temporary persist previous state of the window before backstage and restore to that values when restoring the window size.
That's exactly what is done but restoring the values while the window is maximized doesn't seem work in WPF...
hm, how about:
private void MainWindow_StateChanged(object sender, EventArgs e)
{
if (WindowState == WindowState.Normal)
{
if (Backstage was open && lastWindowstate == maximized && lastWindowSize != currentWindowSIze)
{
Width = persistedWidth;
Height = persistedHeight;
}
}
}
This is just pseudo code, but seems it works. At least my window change its size to size that I tell him.
Hmmm, I checked the behavior of Word 2013 and it behaves the same. Still considered a bug then?
I also just tested on Word 2013 and I dont have such behaviuor. Window always correctly restore its size in described use case.
While using Office 2013 on Windows 8.1 it behaves exactly as this library does. Can anyone else try this out and tell us how it behaves?
FYI, it behaves the same on office 2013/win10. If you just open/close the backstage with a small window, it will adapt the size dynamically. But if you switch to maximized with the backstage open, it will not retain the previous size and switch back to windowed mode with the backstage size.
So I suggest this could be considered as not a bug.
As I said, we do exactly what Office 2013 does.
Does anyone disagree with closing this issue then?
Hello,
I am not sure if this is really Fluent bug, but do the following:
As a result window will not back to the previous size and will become bigger, than it was at startup. Also it hangs and app becomes unstable. In my case the whole WPF UI is locked and become black when I try to move the window with the header.