What exaclty is the difference between an AppWindow and a Window?

[eduardobragaxz]

I've asked this in the community call today, but it was too late 😅

I'm a little confused about the existence of seemingly two identical classes. This article says the AppWindow class is framework agnostic and will be the focus when it comes to new features.

I guess I have 2 main questions:

1. Why not turn the AppWindow class into the new Window and have MainWindow (and all windows you add to a project) inherent from that?
2. If whatever functionality I need for a certain window is already contained in the Window class, should I bother setting an AppWindow and using it's properties instead?

@pratikone you were talking about it today, so maybe you can help me?

[eduardobragaxz]

(I posted this here by mistake. I think this would fit the WinAppSDK repo better, but I can't transfer and can't delete this.)

[DarranRowe]

To be honest, it works in either. But my thoughts on the matter are as follows.

1. This is because Microsoft.UI.Xaml.Window is the Xaml host. While AppWindow could be used for the general window control, since it is framework agnostic, it doesn't have any of the actual Xaml related stuff in there. For example, there is no Window.Content property. 1.3 experimental 1 has a new IWindow2 interface, this extends Window so you can obtain the AppWindow directly, so that will likely appear in the release versions sometime soon.
   But if you wanted to make AppWindow the base runtime class for the Xaml window, then you would either have to extend it to add the Xaml hosting capability and remove the framework agnostic property, change Window so that it derives from AppWindow, or make a completely separate runtime class and have this become the new base. To be honest, none of these are that great option wise and I think the best option is to have Window obtain the AppWindow associated with the backing window and call through to that when needed.

2. At the moment, I would say prefer AppWindow*. But I don't think that it will matter too much long term. It has been stated that they plan to consolidate Window and AppWindow functionality.

*Except for when there are bugs.

[pratikone]

Yeah, there aren't any immediate plans to merge both. We added Window.AppWindow property to open up AppWindow apis are first class citizen within WinUI's scope. We will continue to integrate it more so that the need to call Win32 apis related to HWNDs is reduced (and dealing with complexities which come with it) and user can get all that information within WinUI's context (like support for event handlers).

[eduardobragaxz]

Got it. Thanks guys.