Calling all Windows developers

[r2d2Proton]

Is the WindowsAppSDK targeting C/C++ Windows Developers?

I've been using Microsoft products for a while; MFC wasn't even flushed out. At the moment I am using the resource compiler and .rc files. I am loading my resources as needed, and most of the time dynamically create them using C++ code to make sure the program will run in case a resource DLL isn't found. Most of the time (99%) I handcraft my .rc files too. Would this qualify as a Windows Developer under your definition?

The generated UI elements from WinUI 2 and WinUI 3 look good but the XAML implementation is terrible. Any chance the resource compiler can generate the same UI elements?

Looking at some of the windowing discussions I am a little confused. Are you discussing SDI or MDI type windows?
Is the design and implementation limiting that? That strikes me as alarming, but I don't know enough to be honest.

The Visual Studio 2022 templates are sparse and samples such as Mica cpp-win32 are lacking. C/C++ templates should have a WinMain, and samples that show how to create the UI elements via code.

Please get rid of any WinMain hidden in another file covered by an ifndef

Please remove anything that is not CRT based. In other words, please list what we need to call to get the UI engine up and running.

Please provide samples that show how to create the various UI elements in code.

From a Windows Developer perspective this makes sense. Please don't automagically perform startup stuff - let us call what is needed.

I get the vibe of XAML and C# developers with the examples I see and the startup code. I don't care for XAML - it is poorly done - and this is C/C++ WinMain developers. If not, my apologies.

[sylveon]

Is the WindowsAppSDK targeting C/C++ Windows Developers?

Yes, all Windows App SDK APIs are accessible in C++ (mostly via C++/WinRT).

I've been using Microsoft products for a while; MFC wasn't even flushed out. At the moment I am using the resource compiler and .rc files. I am loading my resources as needed, and most of the time dynamically create them using C++ code to make sure the program will run in case a resource DLL isn't found. Most of the time (99%) I handcraft my .rc files too. Would this qualify as a Windows Developer under your definition?

Yes

The generated UI elements from WinUI 2 and WinUI 3 look good but the XAML implementation is terrible. Any chance the resource compiler can generate the same UI elements?

No. The best you could get is maybe something that converts your resource scripts to equivalent XAML, either at compile-time or at runtime. There was some discussion in this repo or WinUI 3's but I can't find it at the moment because GitHub search is terrible

Looking at some of the windowing discussions I am a little confused. Are you discussing SDI or MDI type windows?
Is the design and implementation limiting that? That strikes me as alarming, but I don't know enough to be honest.

WinUI 3 is SDI only AFAIK (the general trend in UI design has been moving away from MDI). However, you can get a TDI (tabbed document interface) using the TabView control. You can also have multiple top level windows.

The Visual Studio 2022 templates are sparse and samples such as Mica cpp-win32 are lacking. C/C++ templates should have a WinMain, and samples that show how to create the UI elements via code.
Please get rid of any WinMain hidden in another file covered by an ifndef
Please remove anything that is not CRT based. In other words, please list what we need to call to get the UI engine up and running.

WinUI 3 is mostly meant as a completely integrated app development framework at the moment. Support for hosting in other code (via XAML islands) is not available yet. But to get the gist of how'd you do it manually, you can simply look at the auto-generated WinMain:

int __stdcall wWinMain(HINSTANCE, HINSTANCE, PWSTR, int)
{
    {
        void (WINAPI *pfnXamlCheckProcessRequirements)();
        auto module = ::LoadLibrary(L"Microsoft.ui.xaml.dll");
        if (module)
        {
            pfnXamlCheckProcessRequirements = reinterpret_cast<decltype(pfnXamlCheckProcessRequirements)>(GetProcAddress(module, "XamlCheckProcessRequirements"));
            if (pfnXamlCheckProcessRequirements)
            {
                (*pfnXamlCheckProcessRequirements)();
            }

            ::FreeLibrary(module);
        }
    }

    winrt::init_apartment(winrt::apartment_type::single_threaded);
    ::winrt::Microsoft::UI::Xaml::Application::Start(
        [](auto&&)
        {
            ::winrt::make<::winrt::App1::implementation::App>();
        });

    return 0;
}

Please provide samples that show how to create the various UI elements in code.

You create objects and assign them properties like you'd do with every other C++/WinRT objects. There's a small sample in the cppwinrt repo: https://github.com/kennykerr/cppwinrt/tree/master/Store/XamlCode. While this targets UWP XAML, the same applies to WinUI 3.

From a Windows Developer perspective this makes sense. Please don't automagically perform startup stuff - let us call what is needed.

Unfortunately the truth is that if a lot of this stuff is not done by the framework, developers will simply not do it. That's how we end up with, for example, apps without high DPI support in 2022.

I get the vibe of XAML and C# developers with the examples I see and the startup code. I don't care for XAML - it is poorly done - and this is C/C++ WinMain developers. If not, my apologies.

One does not need to use WinMain to be considered a C++ Windows developer. In fact, many app development frameworks now generally don't have you touching main. Qt and C# WPF are like that.

[r2d2Proton]

Thank you for the reply.

Qt aligns with MFC. I do not consider C# a Windows developer. It was developed to soften the blow.

The link https://github.com/kennykerr/cppwinrt/blob/master/Store/XamlCode/App.cpp succinctly demonstrates the disconnect. There is no window procedure. Maybe I missed it.

From your statement WinUI may be an all or nothing sort of thing. It is built on the SDK here.

Do you have an example with the message pump and a windows procedure?

An example that creates the window (without relying on ApplicationT, OnLaunched, etc.), sets the window type, title, menu, and responds to different menu options, has a window procedure and message pump?

As I mentioned this does: WindowsAppSDK-Samples\Samples\Mica\cpp-win32 but it is limited.

It is possible I have not gotten it to execute because it keeps erroring out:

D:\a_work\1\s\dev\WindowsAppRuntime_BootstrapDLL\MddBootstrap.cpp(645)\Microsoft.WindowsAppRuntime.Bootstrap.dll!00007FF9FD4A4BBD: (caller: 00007FF9FD4A244F) Exception(1) tid(550c) 80070491 There was no match for the specified key in the index.
Msg:[Enumeration: Major=1, Minor=0, Tag=, MinVersion=0.319.455.0]

[sylveon]

The link https://github.com/kennykerr/cppwinrt/blob/master/Store/XamlCode/App.cpp succinctly demonstrates the disconnect. There is no window procedure. Maybe I missed it.

WinUI handles the window procedure and message pump for you. You can override the window procedure for a specific Window object using SetWindowLongPtr (after having obtained the HWND using IWindowNative). But there is no way to use a custom message loop.

From your statement WinUI may be an all or nothing sort of thing.

Right now, yes. XAML islands (which allows custom hosting of WinUI content) are still not available.

As I mentioned this does: WindowsAppSDK-Samples\Samples\Mica\cpp-win32 but it is limited.

The sample pointed to is to integrate Mica into an existing Win32 app, it does not use WinUI (the method to use Mica in WinUI is different). The non-WinUI parts of the Windows App SDK (dynamic dependencies, Mica, environment manager) can be used in existing Win32 apps.

[r2d2Proton]

Thank you again for the reply. Obviously, I don't know enough about Mica and WinUI3 :) I will take note of it.