Custom message loop and WinMain in WinUI 3?

[sylveon]

I am interested in porting some Win32 XAML Islands code to WinUI 3 for a future release - but I have one major question that I can't seem to find an answer to anywhere: is there a way to host WinUI 3 in a custom wWinMain function and with a custom message loop?

I am asking this because currently:

• I am using some Win32 features and third party components that require PreTranslateMessage to be inserted in the message loop
• I need some custom initialization in that happens before anything from WinUI in wWinMain
• I use APIs like WriteFileEx, which require to use MsgWaitForMultipleObjectsEx instead of the GetMessage loop.

Sure, I could just wait for WinUI 3's XAML islands and port all my existing code to that, but that seems like far away still, and I want to make use of WinUI's Window class to be able to remove most of my custom XAML island hosting code, since Window covers most of my use cases.

From what I understand, I can just disable the XAML generated main and use my own wWinMain for the first part, but the XAML generated main calls into Application.Start, which blocks until the app exits: this is undesired, and I can't find a non-blocking alternative.

Another side question: can we mix normal WinUI 3 and WinUI 3 XAML Islands in the same app?

[StephenLPeters]

This feels very similar to #3408 @sylveon do you argree?

[sylveon]

For the custom main part yes, but not the message loop

[StephenLPeters]

@ocalvo and @MikeHillberg FYI

[MikeHillberg]

Xaml islands is the design for hosting WinUI3 and running your own message pump. Just avoiding the call to Start won't help because in addition to running the pump it does some necessary initialization.

And I'm not sure that the Window class will work when running the thread as an island. Maybe we should make that a feature request, and at least call out in the spec/docs.

[sylveon]

Why not make it possible to do the initialization as a separate API call so that a consumer can simply call that, new up Windows, and run their own message loop?

The XAML Island API is a lot more trouble than using Window (because you have to implement all the windowing/custom titlebar stuff that Window takes care of yourself).

Making Window supported in XAML islands would be a valid alternative yes.

[marb2000]

@sylveon I added the label feature proposal to the issue. Does this sound good for you? Feel free to close the issue.

[sylveon]

Yep, sounds good to me

[sylveon]

Bump? I'm thinking of introducing new features to my app which require custom message loop handling (specifically, using MsgWaitForMultipleObjectsEx and using an event to wake up the code to process some events), but they would block an eventual migration to WinUI 3 currently.

[sylveon]

Application.Run being blocking is a huge problem for me :(

[Ajith-GS]

Application.Run being blocking is a huge problem for me :(

Is there any update on this issue? I am facing the same issue

[myth384]

Application.Run being blocking is a huge problem for me :(

For me as well! I recently made a wide scoped feature request. I think your suggestion falls into this request as well. Can you relate to that?

[sylveon]

Allowing custom message loops would probably be required to implement your feature proposal, but your proposal in specific isn't related to my use case (everything is contained within a single assembly/app, I just want to be able to use custom code for my message loop)

[sylveon]

Also, I don't use C#

[myth384]

Your very technical specific suggestion is indeed one of the requirements to be able to implement mine. My suggestion may have a larger audience, which could give traction to yours. That's the reason I'm replying here.
Lastly, I don't think Microsoft would limit any solution for your problem to just C++.