Possible to subclass subclass of UserControl?

[StevoSM]

In our application, we will have a whole suite of customized controls that will all share some common functionality. We would like to have something like the following hierarchy:
BaseControl : Microsoft.UI.Xaml.Controls.Control
SpecializedControl1 : BaseControl
SpecializedControl2 : BaseControl
....

We have been trying to set this up, but have only encountered various compiler errors. Copilot initially suggests this is easy to do, then changes its tune when asked about the compiler errors, saying the only proper way to accomplish this is either to use "composition", where there is no subclassing at all and the XAML for SpecializedControl1 includes a reference to BaseControl, or to use Templated Controls. "Composition" does not get us where we want, but is Copilot correct? Would Templated Controls be the only way to accomplish this?

It can be quite time consuming to set these scenarios up and try to slog through the compiler errors, so it would be really great to hear from someone with definite knowledge of what is possible and the correct approaches before spending lots more time seemingly in the weeds in Visual Studio.

[DarranRowe]

This is one of the big reasons why I hate things like Copilot. It is unable to provide actual knowledge on things.

But to dispel one illusion right away, in WinUI 3, there is no such thing as inheritance. Composition is the only option.

Remember that WinUI 3 is a COM API under the surface. COM itself only supports interface inheritance, but the restricted form that WinUI uses, this is WinRT, then it doesn't even support interface inheritance.

So, let's look under the covers a bit and actually see the definition of Microsoft.UI.Xaml.Controls.UserControl.

                [composable(Microsoft.UI.Xaml.Controls.IUserControlFactory, public, Microsoft.UI.Xaml.WinUIContract, 1.0)]
                [contract(Microsoft.UI.Xaml.WinUIContract, 1.0)]
                [marshaling_behavior(agile)]
                [static(Microsoft.UI.Xaml.Controls.IUserControlStatics, Microsoft.UI.Xaml.WinUIContract, 1.0)]
                [threading(both)]
                runtimeclass UserControl : Microsoft.UI.Xaml.Controls.Control
                {
                    [default] interface Microsoft.UI.Xaml.Controls.IUserControl;
                }

This is the MIDL2 definition of it, so it doesn't hide the ABI related stuff. Now, notice that the runtime class definition has a composable attribute? This tells any projection that another runtime class can compose. The thing here is that in projections, this looks like inheritance. What's more, UserControl also composes over Control. Yes, that syntax that looks like inheritance is a composable/composing relationship.

Anyway, what you are doing should be pretty straight forward to do, but without knowing the errors then it is difficult to help.

[StevoSM]

@DarranRowe Thanks so much for the response and for explaining the under-the-hood things. I have put together a basic project to try and get this working, which is attached. The current error is A runtime class can derive only from a composable runtime class. UserControl_Sandbox.MyBaseControl when compiling MyDerivedControl.idl:

import "MyBaseControl.idl";
namespace UserControl_Sandbox
{
    [default_interface]
    runtimeclass MyDerivedControl : MyBaseControl
    {
        MyDerivedControl();
    }
}

UserControl Sandbox.zip

[DarranRowe]

MIDL3.0 uses the unsealed keyword to indicate that a runtime class can take place in composition. This can be seen in the documentation.

The only thing to be aware of is that CppWinRT may not correctly generate the source for a runtime class that is both composable and composing.

To give an example of this:

namespace TestComponent
{
    [default_interface]
    unsealed runtimeclass TestBase : Microsoft.UI.Xaml.Controls.UserControl
    {
        TestBase();
        
        protected Int32 ProtectedProperty;
    }
}

This is stating that it is composing UserControl.

#pragma once
#include "TestBase.g.h"

//Warning comment removed.
static_assert(false, "This file is generated by a tool and will be overwritten. Open this error and view the comment for assistance.");

namespace winrt::TestComponent::implementation
{
    struct TestBase : TestBaseT<TestBase>
    {
        TestBase() = default;

        int32_t ProtectedProperty();
        void ProtectedProperty(int32_t value);
    };
}
namespace winrt::TestComponent::factory_implementation
{
    struct TestBase : TestBaseT<TestBase, implementation::TestBase>
    {
    };
}

This is what would be generated by CppWinRT.

#pragma once
#include "TestBase.g.h"

namespace winrt::TestComponent::implementation
{
    struct TestBase : TestBaseT<TestBase, Microsoft::UI::Xaml::Controls::UserControl>
    {
        TestBase() = default;

        int32_t ProtectedProperty();
        void ProtectedProperty(int32_t value);

        int32_t m_value{};
    };
}
namespace winrt::TestComponent::factory_implementation
{
    struct TestBase : TestBaseT<TestBase, implementation::TestBase>
    {
    };
}

In the above, notice the second template parameter for TestBaseT. It is this second parameter that states that TestBase is composing UserControl, but it is missing.

[StevoSM]

@DarranRowe Gah. Yes, I knew about the unsealed adornment. I am using it elsewhere but forgot it needed to be added here.

The .h files you included above are in our domain so we can just add the missing Microsoft::UI::Xaml::Controls::UserControl, which I did, but doesn't resolve the latest message static_assert failed: 'Class must derive from implements<> or ClassT<> where the first template parameter is the derived class name, e.g. struct D : implements<D, ...>'.

It sounds like perhaps you are saying that conceptually this should be possible, but it's a ?current? bug/limitation of the tools that they are not generating the correct file content to allow the downstream compiler to proceed without issue?

Latest Project attached for anyone interested:
UserControl Sandbox.zip

[DarranRowe]

Speaking of Gah, I think you managed to hit the other bug there. Of course, I knew about it and when I created a quick little project myself to make sure that what I was writing was valid, I naturally took the appropriate steps to avoid it. But it completely slipped my mind.

This screenshot shows the solution layout, and I currently have a runtime component project where my TestBase and TestDerived classes are defined.

When building with the solution layed out in this manner, it doesn't hit this problem. I'm not sure which it is, but there is a long running problem either in CppWinRT or the XamlCompiler that generates bad code in this case. So try moving the runtime classes to a component DLL to see if that helps.

Also, if this is intended to be an upackaged application, then you really should also use Registration Free WinRT to register the component for the executable. This is done in the application manifest, under the file element. The activatableClass element makes the link between the runtime classes in the component and the component file. CppWinRT has done direct attempts to load a component based on namespaces before, but I think that has either changed or will change. So it is possible that the applicaiton may apparently work correctly if this registration isn't done, but this may just fail one day, and CppWinRT cannot handle the case where the component library doesn't match the root namespace name.

Registration Free WinRT isn't needed when the application is packaged, this is registered in the package manifest file.