Get Back to the Xaml Window from AppWindow

[MarkBrainfire]

This code gets you to the AppWindow from a Xaml Window:

public static AppWindow AppWindow(this Window xamlWindow)
{
    IntPtr hWnd = WinRT.Interop.WindowNative.GetWindowHandle(xamlWindow);
    WindowId windowId = Win32Interop.GetWindowIdFromWindow(hWnd);
    return AppWindow.GetFromWindowId(windowId);
}

Given an AppWindow, is there any way to get back to the corresponding Xaml Window?

[DarranRowe]

Whenever I use AppWindow, I normally use it like:

namespace winrt::MyApp::implementation
{
    struct MainWindow : MainWindowT<MainWindow>
    {
        MainWindow();

        void myButton_Click(Windows::Foundation::IInspectable const& sender, Microsoft::UI::Xaml::RoutedEventArgs const& args);

        void AppWindow_Changed(const Microsoft::UI::Windowing::AppWindow &, const Microsoft::UI::Windowing::AppWindowChangedEventArgs &);
        void AppWindow_Closing(const Microsoft::UI::Windowing::AppWindow &, const Microsoft::UI::Windowing::AppWindowClosingEventArgs &);
        void AppWindow_Destroying(const Microsoft::UI::Windowing::AppWindow &, const Windows::Foundation::IInspectable &);

        HWND m_nativehandle = nullptr;
        winrt::Microsoft::UI::WindowId m_windowid{};
        winrt::Microsoft::UI::Windowing::AppWindow m_appwindow = nullptr;
    };
}

Excuse the C++.
I hook up the AppWindow events to the class' member functions and therefore this is always going to be the link back to Xaml's Window. If I use a lambda, C++ allows you to explicitly capture this.
If this kind of option isn't available in C# or there is a scenario here that I'm misunderstanding, then unfortunately no. This would be something that you would have to add yourself. Remember that you can always grab a reference to your application's App class by using Application.Current. It is possible to use that to make the link between the AppWindow's window id and the Xaml window.

[MarkBrainfire]

If we start from a Microsoft.UI.Windowing.AppWindow, we can get the handle of the corresponding Win32 window from the AppWindow.Id as follows:

IntPtr hWnd = Win32Interop.GetWindowFromWindowId(appWindow.Id);

However, I can find no way to get back the corresponding Microsoft.UI.Xaml.Window from Win32 handle (hWnd).

Can anyone else?

Of course, you can store a copy ... but that's not the question.

[DarranRowe]

Which is why the rest of the answer exists, including the "unfortunately no".

[MarkBrainfire]

This represents an obvious defect in WindowsAppSDK.

I suspect the reason it is only one-way is that they are supporting a wide variety of languages and UI frameworks. Still it would have been trivial to maintain the source object and it's type.

[DarranRowe]

I would have to completely disagree with it being a defect.
But I would ask you to consider providing a feature proposal if you really do feel that it is something so important. Just take into consideration that this link cannot go into the AppWindow runtime class since it is meant to be framework agnostic.

[bogdan-patraucean]

In 1.3 experimental you can now directly access AppWindow from the MainWindow.

[MarkBrainfire]

Yes I know, saving 3 lines of code to go from a Microsoft.UI.Xaml.Window -> Microsoft.UI.Windowing.AppWindow

However, that's not my question. I want to find a way to go back in the opposite direction:
Microsoft.UI.Windowing.AppWindow -> Microsoft.UI.Xaml.Window
It's easy to use the AppWindow.Id to get the corresponding hWnd. But I can't find anyway to get from a hWnd back to the corresponding XAML Window.

And, as far as I can tell, it isn't possible within the WindowsAppSDK.
Gettinng the XAML Window from a hWnd might be possible using lower-level Win32 and WinRT methods might be possible, but I don't know how.

[MarkBrainfire]

We do have this static method of the Xaml Window:

    public static Window FromAbi(IntPtr thisPtr)
    {
        if (thisPtr == IntPtr.Zero)
        {
            return null;
        }

        return MarshalInspectable<Window>.FromAbi(thisPtr);
    }

However, I get errors when attempting to call this method.

[DarranRowe]

This is meant to provide a mapping between the underlying COM interfaces and the projection wrapped classes.
So this would take an ABI::Microsoft::UI::Xaml::IWindow * from C++ and produce the C#'s Microsoft.UI.Xaml.Window from it. C++/WinRT has similar functionality in the form of winrt::put_abi.

[MarkBrainfire]

I see. Thanks. So the "thisPtr" above cannot be a Win32 hWnd, which is what I'm after ... getting back to the Xaml Window from it's associated hWnd. So I'll just conclude that it isn't possible.

[fabianoriccardi]

I would revamp this topic for the following reason:

I want to create a modal Window, just like the Options Window in our loved Visual Studio.

This seems not possible with Winui3, unless using low-level APIs. (please correct me if I'm wrong).

So I would try to create a modal Windows in the following way:

{
	var presenter = OverlappedPresenter.CreateForDialog();
	presenter.IsModal = true;

	// "this" is some other Window.
	var appWindow = AppWindow.Create(presenter, this.AppWindow.Id);
	appWindow.Show();
}

And an empty modal windows is shown. But how can I populate the window? I need the Window object to set the Content.

So, I can get the "Window" pointer:

var windowHandle = Win32Interop.GetWindowFromWindowId(appWindow.Id);

But I still cannot get the Window object. Any suggestion to create a modal window?

[castorix]

I want to create a modal Window, just like the Options Windows in our loved Visual Studio.

You can see this thread #4435
But I had to use SetWindowLong with GWL_HWNDPARENT (I did not test if it is still necessary with last versions)

[DarranRowe]

I think there is something that should be cleared up first, just in case there is a misunderstanding.

There is no guaranteed 1:1 relationship between an AppWindow and a Window. Microsoft.UI.Xaml.Window is built upon a desktop window, so it has a HWND, and therefore by extension has an AppWindow. But if you use AppWindow.Create to create an AppWindow, this does not have a Microsoft.UI.Xaml.Window instance attached to it. It is no different from calling CreateWindowEx.

This is, in a roundabout way called out in the documentation.

For the Windows App SDK version of Microsoft.UI.Windowing.AppWindow we're supporting only top-level HWNDs. There's a 1:1 mapping between an AppWindow and a top-level HWND.

The lifetime of an AppWindow object and an HWND is the same—the AppWindow is available immediately after the window has been created; and it's destroyed when the window is closed.

In other words, an AppWindow is only tied to a HWND, and you can get an AppWindow for any HWND you create using CreateWindowEx. What's more, creating an AppWindow through AppWindow.Create actually puts you in a worse starting place than using CreateWindowEx. The window doesn't have the normal set up for a window. There is certainly no sane default for the window procedure, and you would immediately have to subclass it.

For being able to obtain a Window from a HWND, there are issues with this. Since there is no way to query this from the runtime itself, the only real way available would be to send a message to the HWND. This is problematic, since what would you get from the window? The natural thing would be the ABI instance of IWindow, but this can potentially lead to leaks or crashes. I would also imagine that C# developers wouldn't be too happy to go through P/Invoking SendMessage and having to attach the ABI instance up to an empty projection object. There are also other things that could happen, like causing a crash by sending an unexpected message to a window that wasn't ready for it.
The best option would be for a static member on Window to try to get the Window instance from a WindowId. If there is no feature request for this, then I would suggest you make one.

For using DesktopWindowXamlSource, all I can say is look into using the WinUI 3 Xaml Islands. There is a C++ example available, but you should be in a better position due to having the full Xaml environment available. This would mean that you would only have to create the window, initialise DesktopWindowXamlSource and then load your content. Unless there is something that I have missed, this is really the only supported way to have Xaml content in an owned window.

But I had to use SetWindowLong with GWL_HWNDPARENT (I did not test if it is still necessary with last versions)

As a side note. This is problematic for x64 and AA64 builds due to pointer truncation. HWNDs are 64 bit types, so you really should be using SetWindowLongPtr. There is also the whole undocumented behaviour thing.

[fabianoriccardi]

As usual, @castorix as peculiar ways to solve the issue, and even if it is working, I prefer to avoid tricky and undocumented behavior/APIs. If this should be the only way to solve an issue, I prefer to leave.

@DarranRowe thanks for the extensive explanation, but I would have a clarification... Is the window generated by AppWindow.Create(presenter, this.AppWindow.Id); a TOP-level window? I think no, because it has a parent. So, it doesn't have any HWND, correct?

[DarranRowe]

@fabianoriccardi
Even if it wasn't a top level window, it would still have a HWND. Child windows are still created using CreateWindowEx, the only difference is that the style for the window has to include WS_CHILD. This fact is documented in Window Features, and this means that child windows must have HWNDs because CreateWindowEx also returns a HWND. What's more, a child window can also be a parent. Since you must provide a HWND to the parent to establish the parent/child relationship (See CreateWindowEx's hWndParent parameter or SetParent), then again, a child window MUST have a HWND.

Now, for the exact situation with AppWindow.Create, while it jumps between two terms, the remarks section states:

To make this window an owned window, pass the Id of the window you want to be its owner to the ownerWindowId parameter.

This explicitly states that it is an owner/owned layout. Now, again, from Windows Features, this states:

An overlapped or pop-up window can be owned by another overlapped or pop-up window.

If you then look closer at the top of Windows Features, an overlapped window is explicitly defined as a top-level window and a pop-up window is explicitly defined as an overlapped window. So putting this all together, owned windows are top-level windows. AppWindow.Create with a window id creates an owned window, therefore AppWindow.Create only creates top-level windows.
Also, AppWindow.Create with a window id doesn't create a window with a parent, it creates a window with an owner.

[fabianoriccardi]

Now I'm a bit less confused. I never deep down in Window windowing system, so I was thinking Parent and Owner were synonymous. I will read Windows Features, but now should be clear that, for me, the best option is asking for a feature request for (as you said) a static member on Window to try to get the Window instance from a WindowId.