WindowPersistence does not restore FullScreen presenter

[riyasy]

WinUIEx: 2.9.0
OS: Windows 11 x64
Platform: WinUI 3 (C#)

If the app is closed while the window state is in AppWindowPresenterKind.FullScreen, on next launch the window opens monitor-sized but in Overlapped (restored) state (rounded corners + maximize button).

It appears that WindowManager.PersistenceId restores size/position but not the presenter kind.

Is this by design? Would it make sense to optionally persist and restore AppWindowPresenterKind as well?

I can handle it manually, just checking whether this is expected behavior.

Thanks!

Note - In test code, while in FullScren, there is no close button, I closed by pressing Alt + F4

using Microsoft.UI.Windowing;
using Microsoft.UI.Xaml;
using WinUIEx;

namespace FullScreenTest;

public sealed partial class MainWindow : Window
{
    public MainWindow()
    {
        InitializeComponent();
        FullScreenButton.Click += MaximizeFullScreenToggle;
        var manager = WindowManager.Get(this);
        manager.PersistenceId = "FullScreenTest";
    }

    private void MaximizeFullScreenToggle(object sender, RoutedEventArgs e)
    {
        // Use .Kind (a plain enum) instead of `is OverlappedPresenter` / `is FullScreenPresenter`
        // type-pattern checks. The `is T` form goes through WinRT COM QueryInterface, which the
        // Release-build trimmer strips — causing the check to silently return false in Release.
        if (AppWindow.Presenter.Kind == AppWindowPresenterKind.Overlapped)
            AppWindow.SetPresenter(AppWindowPresenterKind.FullScreen);
        else if (AppWindow.Presenter.Kind == AppWindowPresenterKind.FullScreen)
            AppWindow.SetPresenter(AppWindowPresenterKind.Overlapped);
    }
}

[dotMorten]

Nice find. I didn’t think this would be a requirement so didn’t test that. Would have to think it over a little. I could imagine there’s many cases where you don’t want to restore back to full screen (like a video player)

[riyasy]

In my case it is a photo viewer.

[dotMorten]

I have another thought on this: I think the better solution here is to not persist the full-screen setting, but only manage the overlapped presenter size and position. That would match what I think most Windows apps do.

[riyasy]

In my app, I can go to fullscreen from restored window state or maximized state (Both are overlapped).
So if the app exits while in full screen, are you proposing we can get back the previous overlapped state (maximized or restored) on relaunch?

[dotMorten]

Yes that's what I'm proposing, and you can choose to restore the fullscreen presenter yourself, but once you go out of fullscreen, it should return to the original saved state.
I'm having slight trouble with this though, due to the order events are firing (resize to full screen happens way before we know we're getting a new presenter), so so far the solution I have to accomplish this is really ugly. Will need a little bit more work.

[riyasy]

Currently I made a workaround like -
I built WinUIEx after exposing SavePersistence() as public from WindowManager.
When pressing F11, my app saves the state using this function, then sets "" to persistence ID and then goes full screen.
When exiting from fullscreen, it sets the persistence ID back.

[riyasy]

(resize to full screen happens way before we know we're getting a new presenter), so so far the solution I have to accomplish this is really ugly. Will need a little bit more work.

I tried to write my own window manager and faced same issue. When setting FullScreen, first the resize event comes and then presenter changed event comes. The resize event saves the fullscreen cordinates to the persisted state. I tried a dirty fix like adding a PauseTracking property to my manager to control this. Then later scrapped everything.

[dotMorten]

Btw have you happened to try the new persistance APIs in WinUI 3 v2.x ?

[riyasy]

Btw have you happened to try the new persistance APIs in WinUI 3 v2.x ?

Thanks.. I shall check..