Cannot {x:Bind} to property of named XAML control in C++/WinRT

[sylveon]

Describe the bug
The autogenerated binding code tries to find the named XAML control through the projected type rather than the implementation type, resulting in a compile-time error.

Steps to reproduce the bug

1. Create a new C++/WinRT XAML project
2. Add <winrt/Windows.UI.Xaml.Media.h> to the precompiled headers (to allow SolidColorBrush to be usable)
3. Add the following XAML code somewhere in the MainPage

<StackPanel>
    <ColorPicker x:Name="Picker" IsAlphaEnabled="True" IsMoreButtonVisible="True" IsColorPreviewVisible="False" />

    <Rectangle Width="100" Height="100">
        <Rectangle.Fill>
            <SolidColorBrush Color="{x:Bind Picker.Color, Mode = OneWay}" />
        </Rectangle.Fill>
    </Rectangle>
</StackPanel>

4. Build the code

Expected behavior
The code builds fine.

Version Info

NuGet package version: [Microsoft.Windows.CppWinRT 2.0.200615.7]

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
May 2020 Update (19041)	Yes
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context
The fix should be quite simple. Here's the wrong autogenerated code:

void Update_(::winrt::BlankApp1::MainPage obj, int32_t phase)
{
    if (obj)
    {
        if ((phase & (NOT_PHASED | (1 << 0))) != 0)
        {
            Update_Picker(obj.Picker(), phase);
        }
    }
}

A correct version would be:

void Update_(::winrt::BlankApp1::MainPage obj, int32_t phase)
{
    if (obj)
    {
        if ((phase & (NOT_PHASED | (1 << 0))) != 0)
        {
            Update_Picker(obj.as<::winrt::BlankApp1::implementation::MainPage>().Picker(), phase);
        }
    }
}

Alternatively, I believe it would be possible to instead have Update_ directly take the implementation type:

void Update_(::winrt::BlankApp1::implementation::MainPage obj, int32_t phase)
{
    if (obj)
    {
        if ((phase & (NOT_PHASED | (1 << 0))) != 0)
        {
            Update_Picker(obj.Picker(), phase);
        }
    }
}

by adjusting the generated struct declaration to refer to the implementation type, like this:

    template <typename D, typename ... I>
    struct MainPageT<D, I...>::MainPage_obj1_Bindings
        : public ::winrt::BlankApp1::implementation::ReferenceTypeXamlBindings<::winrt::BlankApp1::implementation::MainPage, ::winrt::BlankApp1::implementation::XamlBindingTrackingBase>
{

[sylveon]

Additionally, looks like neither Binding works, the rectangle is just permanently black 😞

[JeanRoca]

Hey @sylveon would adding ColorPicker Picker;​​ to your IDL file fix this issue?

[sylveon]

Yes, it does, but I don't want to expose it to my consumers like that.

[JeanRoca]

Oh I see that makes sense thank you for clarifying. In that case, there are ways to filter metadata, so that you don't expose this to customers. Adding @kennykerr and @BenJKuhn who may be able to help workaround this while we wait on a real fix.

[evelynwu-msft]

Fix will be available in WinAppSDK 1.4.

[sylveon]

That's great news! Any chance at backporting to UWP?

[evelynwu-msft]

It's very unlikely given that a workaround (as ugly as it is) exists.

[duncanmacmichael]

Fixed in 1.4.0. @bpulliam please close this issue as I cannot. :)

[sylveon]

Not fixed in system XAML :(

[bpulliam]

Not fixed in system XAML :(

We are focusing our resources and efforts on WinUI 3. The bar for backporting changes to system Xaml is very high.