x:Bind outside data templates is extremely inconsistent

[Sergio0694]

Describe the bug

Apparently it is possible to use x:Bind to bind to a field in code behind outside a data template. Basically, escaping from the data template in use. Not entirely sure whether this is by design or just a lucky quirk of the XAML compiler and codegen (especially since this is not mentioned anywhere in the docs), but it works.

As a code example:

<UserControl
    x:Class="MyNamespace.Views.MyUserControl"
    xmlns:viewModels="using:MyNamespace.ViewModels"
    models="using:MyNamespace.Models">
    <UserControl.DataContext>
        <viewModels:MyViewModel x:Name="ViewModel"/>
    </UserControl.DataContext>
    <UserControl.Resources>

        <DataTemplate
            x:Name="SomeDataTemplate"
            x:DataTye="models:SomeModelTyppe">

            <!--This works-->
            <TextBlock Text="{x:Bind ViewModel.SomeText}"/>
        </DataTemplate>
    </UserControl.Resources>

    <ListView
        ItemsSource="{x:Bind ViewModel.MyItems}"
        ItemTemplate="{StaticResource SomeDataTemplate}"/>
</UserControl>

You can see how the binding is escaping the data template and just targeting a field in code behind.
The problem with this is that it's extremely fragile and inconsistent:

• x:Bind to a property outside the data template works fine ✅
• x:Bind to that same property but with function binding fails to build ❌
• x:Bind to that same property from a visual state setter crashes at runtime ❌
• x:Bind to that same property with a converter crashes at runtime ❌

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Download this repro
2. Open the solution, run the app

Expected behavior

🤷‍♂️ 🤷‍♂️ 🤷‍♂️

Actual behavior

The binding to the outside field (the view model) works just fine

Screenshots

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

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

cc. @MikeHillberg

[StephenLPeters]

@fabiant3 For FYI

[jamesmcroft]

This almost looks like it shouldn't work at all. The DataTemplate has a defined DataType which it uses for its bindings.

I know with old-style Binding, this was possible with ElementName but I think there's an argument for having this functionality work correctly with x:Bind.

[MikeHillberg]

{Binding} and ElementName will walk up the element tree at runtime. IIRC x:Bind will statically search up the naming scopes -- the DataTemplate then the x:Class.

[Sergio0694]

@jamesc I actually believe this was in fact supported, in particular because VS even has dedicated warnings for this. Like, if your x:DataType model has a property with the same name as the one from code behind, and you x:Bind to it, VS will say something like:

Warning, binding to property will cause the binding to reference the one from the outer scope.

As in, it looks like the system is perfectly aware of the possibility of binding outside of a data template, as @MikeHillberg said. I'd also argue this feature is extremely useful in many cases.

@MikeHillberg is it safe to say then that the issue is just that using anything other than standard x:Bind in this case (eg. function binding, binding from markup extension, etc.) breaks down? But like, that in theory this is a supported scenario that should work? 🤔

[MikeHillberg]

Yes, it should work. I expect some of the code for the (1903) feature went into a not-common code path, so missed the function binding case.

[RealTommyKlein]

Thanks Mike for digging into this - yes, x:Bind'ing to named elements outside of the scope is an intentional feature. This is meant to be similar to the ElementName feature in {Binding}, allowing for binding to named elements outside of the current namescope. But unlike {Binding} which walks the visual tree at runtime to perform the name lookup, x:Bind walks the "markup tree" at compile time so it can perform compile time validation. You could see behavior differences when those don't align, like when using a Binding/x:Bind in a template from a ResourceDictionary. The Binding walks the visual tree from where the template is used, whereas x:Bind walks the markup tree from where the template is defined.

is it safe to say then that the issue is just that using anything other than standard x:Bind in this case (eg. function binding, binding from markup extension, etc.) breaks down? But like, that in theory this is a supported scenario that should work? 🤔

Correct, these should work

[hansmbakker]

I believe this is still an issue; is there any indication on when we can use x:Bind for this rather than Binding?

Imagine I have a UserControl containing a dependency property IsEditing (bool), I want to be able to set the visibility of a TextBlock vs a TextBox inside my DataTemplates.

With x:Bind that seems not possible because it only allows selecting items from the configured x:DataType, and not from the codebehind of the UserControl

Pseudocode, only to explain the use case of wanting to access data outside the DataType scope using x:Bind:

<UserControl Class="local:CarsList">
   <UserControl.Resources>
      <converters:BoolToVisibilityConverter x:Key="BoolToVisibilityConverter" />
      <DataTemplate x:Key="listItemTemplate" x:DataType:"models.Car">
        <Grid>
            <TextBlock Text="{x:Bind Brand}"
                               Visibility="{x:Bind IsEditing, Converter={StaticResource BoolToVisibilityConverter}, ConverterParameter=True, Mode=OneWay}" />
            <TextBox Text="{x:Bind Brand}"
                            Visibility="{x:Bind IsEditing, Converter={StaticResource BoolToVisibilityConverter}, Mode=OneWay}" />
        </Grid>
      </DataTemplate x:Key="listItemTemplate">
   </UserControl.Resources>
</UserControl>

Doing the above will result in The property 'IsEditing' was not found in type 'Car'.

Workaround is giving the usercontrol an x:Name and fall back to Binding. Quite annoying 😕.

<UserControl Class="local:CarsList" x:Name="workaroundNameForControl">
   <UserControl.Resources>
      <converters:BoolToVisibilityConverter x:Key="BoolToVisibilityConverter" />
      <DataTemplate x:Key="listItemTemplate" x:DataType:"models.Car">
        <Grid>
            <TextBlock Text="{x:Bind Brand}"
                               Visibility="{Binding Path=IsEditing, ElementName=workaroundNameForControl, Converter={StaticResource BoolToVisibilityConverter}, ConverterParameter=True, Mode=OneWay}" />
            <TextBox Text="{x:Bind Brand}"
                            Visibility="{Binding Path=IsEditing, ElementName=workaroundNameForControl, Converter={StaticResource BoolToVisibilityConverter}, Mode=OneWay}" />
        </Grid>
      </DataTemplate x:Key="listItemTemplate">
   </UserControl.Resources>
</UserControl>

Other workarounds for this case would be using a DataTemplateSelector but that won't work for all cases.

[RealTommyKlein]

Unfortunately, I don't believe we can investigate this before the official WinUI 3 release in 2021. For your scenario in particular, you could try adding an x:Name to your root UserControl, then x:Bind using the named element (e.g. x:Bind RootUserControl.IsEditing). When looking outside of the namescope it was used in, x:Bind only looks for named elements, and not properties on the root data context.

[hansmbakker]

Thanks for thinking along!
Actually I tried that (x:Bind workaroundNameForControl.IsEditing), but then I get the error The property 'IsEditing' was not found in type 'Car'..
I'm using VS 16.8 Preview 3.2 with an UWP project.

[stevenbrix]

@hansmbakker does using {x:Bind ElementName=workaroundNameForControl, Path=IsEditing} work?

[deakjahn]

@stevenbrix Considering that x:Bind has no ElementName, no, it does not... :-) And even if it did, it would only work for plain property binding, not functions where the property would need to be passed as an argument, for instance.

I'm also struggling with this, and this is very important. Now that we have functions in x:Bind and prefer to avoid converters, reaching out to two places: data from the context of the data template and functions from the underlying control (data conversions, checks for visibility, disabled state, etc), this became very important. And Binding isn't even an alternative any more, not because it's quirkier and slower but because it doesn't do functions.

Conversion and other functions can be specified static and called as such (not nice but definitely a workaround) but properties of the control can't. Naming the control doesn't work, either, just as Hans pointed out above. And while the OP's solution might be OK for MVVMWHATEVERTHECURRENTBUZZWORDIS, it doesn't work for a plain user control: if we refer to the control itself this way, there will be complaints about IType_BindingsScopeConnector. Basically, with this trick, you can reach out to two data elements (template data context and control data context) but not the control itself as the second.