InitializeComponent is not called for base classes.

[sylveon]

With #1130, InitializeComponent is now called internally as part of winrt::make instead of within the constructor. This means that the following scenario, by default, does not work anymore:

• Class A is a base class using XAML.
• Class B derives from class A in metadata, and uses XAML too.
• Both are within the same project, so implementation::B directly derives from implementation::A, instead of using WinRT composition.

C++/WinRT will call class B's InitializeComponent function, but the XAML compiler did not generate code in class B's InitializeComponent function to call class A's InitializeComponent function. As a result, nothing from class A is loaded: none of the XAML is visible, no event handlers are attached, x:Bind bindings are not set up, trying to access a x:Name'd control gives nullptr, ets.

To fix this, a user has to explicitly go and add the following in implementation::B:

void B::InitializeComponent()
{
    A::InitializeComponent();
    BT::InitializeComponent();
}

These kinds of things should be transparent to the user.

[sylveon]

Also to note that this workaround doesn't work if the XAML runtime calls back to the type (most notably, used for x:Bind, event handlers, and x:Name), as instead of calling class A's Connect when in A::InitializeComponent, it will call B::Connect, which is wrong and will result in E_NO_INTERFACE crashes because B's Connect expects certain connection IDs to match certain control declared in the XAML, but here we're passing the controls declared in A's XAML, not B's. This worked previously before because by the point A::InitializeComponent was called, B's vtable didn't exist yet, so it called A::Connect.

[roxk]

While I think manually adding InitializeComponent makes sense given that's how inheritance/shadowing work in C++, its compatibility with the xaml runtime is ultimately broken for now.

On top of the above issue, in my testing, LoadComponent isn't even called for the derived class. Inside DerviedT::InitializeComponent, _contentLoaded is already true since Base::InitializeComponent had set it, thus skipping the call.

While I personally don't recommend using inheritance for composing UI, and there are other workarounds (namely, don't inherit classes from the same project), inheriting pages within the same project is explicitly documented and this breakage would confuse lots of users.

Modifying xaml compiler to explicitly qualify every such variables like _DerivedT_contentLoaded might work, but this fix is going to take a long time to ship. And it doesn't even solve the issue of xaml runtime calling DerivedT::GetBindingConnector even in Base::InitializeComponent.

Update: Through more debugging, it's revealed that Base::InitializeComponent set DerivedT::_contentLoaded via DerivedT::Connect, so variable shadowing etc isn't the problem and using different variable names wouldn't help here.

Regardless of how we get to resolve this, I suggest we add some basic tests for xaml as these kind of breakage is quite severe and would have been caught trivially with a test.

[Scottj1s]

@sylveon, thanks for opening the issue - can you put together a simple repro?

[sylveon]

Here's a repro:
InitializeComponentRepro.zip

You'll notice, when clicking on "Navigate to DerivedPage", that the app turns blank. This is because DerivedPageT's InitializeComponent will be called by cppwinrt, but not BasePageT's InitializeComponent. So Page's Content is never set (because it is set by BasePage), resulting in an empty page.

Now if we go and uncomment the InitializeComponent in DerivedPage.h and DerivedPage.cpp, and rerun the app, we will see that navigating to DerivedPage will instead crash the app, with an hresult_no_interface exception. This happens within DerivedPageT::Connect. It is trying to cast the ContentPresenter from BasePage to a TextBlock. The XAML framework was expecting to call BasePageT::Connect to connect the x:Bind, since it's currently loading up BasePage, but ends up calling DerivedPageT::Connect since DerivedPage's vtable is fully formed (because we are outside the constructor).

[sylveon]

@roxk's comment about _contentLoaded being set is not a naming conflict, but rather that when the XAML framework wrongfully calls DerivedPageT::Connect, it can succeed (that can happen when there is no x:Name'd element, no event handler, and no x:Bind in DerivedPage, so there is nothing for Connect to actually do), and then sets _contentLoaded to true.

[Scottj1s]

Thanks - investigating

[sylveon]

As a temporary workaround, we can keep the InitializeComponent() call within the constructor for all unsealed runtime classes.

[Scottj1s]

@sylveon, thanks for your patience. I should have time to look at this next week. Glad you have a workaround.