Microsoft-ui-xaml: Question: Will the new WinUI 3.0 app template include CoreWindow as the main app Window?

[duke7553]

Hello, community!

I am attempting to figure out how to create a fully-modern application window from my WPF app. Below is what I have so far in my code file. Are the modern app windows created by the Application.Start() function, or is there another way to do this? I would ideally want a modern window where I can expand the content into the titlebar, and display a splash-screen just from WPF.

If this is currently impossible, will it be addressed with WinUI 3.0? I think a modern window w/ splash screen should be part of the WinUI Desktop template when it is added. Is this on the roadmap?

Sorry in advance for such a question, but I really liked the flexibility to expand content into the titlebar (without having to redraw all window decoration myself) and want to see this in WinUI 3.0.

Thanks guys,
Luke Blevins

[contextfree]

AFAIK there's currently no way to directly create UWP windows (CoreWindow/AppWindow) from a Win32 process, nor is there a way to directly create Win32 windows (HWND) from a UWP process. You would have to make a hybrid app (using Desktop Bridge/Centennial) which sort of lets you staple together a Win32 and UWP app and have them appear to the user as one unified app; then you can use IPC methods like app services to communicate between them. There's some documentation on how to do things like this here: https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extend

[michael-hawker]

@marb2000 FYI

[duke7553]

Updated question to reflect new information.

[marb2000]

Our approach is that WinUI 3 will use CoreWindow when running in UWP and Win32 Window(HWind) when running in Desktop (Win32).

WinUI 3 in UWP apps will be able to use AppWindow APIs. For Desktop, there will be needed to come out with something similar. We are still designing this, so I don't have more details so far.

[Gavin-Williams]

If you replace Win32 Window with CoreWindow for non-contained / non-Xaml scenarios, and also provide CoreWindow to .Net 5 Non-UWP then we can have a unified app/window model across Windows for non-Xaml work. That makes more sense than holding onto Win32 FOR EVER or making up new App models.

Why should we have to rewrite the application layer just because we want to switch between contained and non-contained execution (for example between UWP and Win32) - that's a typical problem which faces game dev's today, they can't commit to UWP because they need Win32 distribution freedom. So they are forced to use HWnd or .Net Framework app models. If the UWP app/window model was made available for non-uwp-contained apps, no problem, we could write the same code for the application layer and compile for both MS Store and other stores from the same code base.

Edit: Otherwize, any new AppWindow API's that are being developed, should be similar to CoreWindow at least, using WinRT and should be made available for each build scenario - WinRT and Win32. Please don't make another AppWindow model specific to .net 5 Win32 and not provide it to WinRT (UWP). Give us a universal Xaml-less app-window api (all containers, all languages).