[MVUX] Adding model to Templated Control brakes custom property binding

[kucint]

Let´s create a simple templated control, that exposes one single DependencyProperty of type bool:

public class MyControl : Control
{
    public MyControl() {}

    public bool AutoUpdate
    {
        get { return (bool)GetValue(AutoUpdateProperty); }
        set { SetValue(AutoUpdateProperty, value); }
    }

    public static readonly DependencyProperty AutoUpdateProperty =
        DependencyProperty.Register(
            nameof(AutoUpdate),
            typeof(bool),
            typeof(MyControl),
            new PropertyMetadata(
                false,
                (s, e) => ((MyControl)s)?.OnAutoUpdateChanged(e))
        );

    private void OnAutoUpdateChanged(DependencyPropertyChangedEventArgs e)
    {
        Debug.WriteLine($"MyProperty Changed from [{e.OldValue}] to [{e.NewValue}]");
    }
}

Let´s bind this property to the MainPageModel state MyOption.
MyOption state is as well bound to the CheckBox on MainPage.
Both bindings are TwoWay.

public sealed partial class MainPage : Page
{
    public MainPage() => this
        .DataContext(new BindableMainPageModel(), (ctrl, vm) => this
        .Background(ThemeResource.Get<Brush>("ApplicationPageBackgroundThemeBrush"))
        .Content(new StackPanel()
        .VerticalAlignment(VerticalAlignment.Center)
        .HorizontalAlignment(HorizontalAlignment.Center)
        .Children(
            new CheckBox()
            .Content("MyOption")
            .IsChecked(x => x.Binding(() => vm.MyOption).TwoWay()),

            // binding below triggers correctly, but
            // stops to trigger when state management added to MyControl
            new MyControl()
            .AutoUpdate(x => x.Binding(() => vm.MyOption).TwoWay()) 
        )));
}

internal partial record MainPageModel
{
    public IState<bool> MyOption => State<bool>.Value(this, () => true);
}

I expect that every time when CheckBox is clicked, the AutoUpdate DependencyProperty of MyControl is updated.
And indeed, this is exactly what happens, the method OnAutoUpdateChanged is called everytime as expected.

But now, do modify the template control by adding a state management to it:

public MyControl()
    => this.DataContext(new BindableMyModel(), (page, vm) => { });

where MyModel is:
internal partial record MyModel;

This brakes the binding to custom property and OnAutoUpdateChanged is no longer called when the checkbox is clicked.

Tested on

• WIndows 11
• VS v17.9.6
• "Uno.Sdk": "5.2.95"
• TargetFrameworks: net8.0-desktop

[kucint]

Any news on this one?
Inability to create custom properties on templated control makes the control unusable...
Or am I missing something?

[francoistanguay]

@kucint , friendly reminder that it is a lot easier for our team to look at these issues when you attach a simple project that reproduces your issue. Snippets of code help, but fully working solution is a lot better.

[dansiegel]

I expect that every time when CheckBox is clicked, the AutoUpdate DependencyProperty of MyControl is updated.
And indeed, this is exactly what happens, the method OnAutoUpdateChanged is called everytime as expected.

But now, do modify the template control by adding a state management to it:

I'm not sure what you mean here @kucint. I've created a sample with the code you show in your question which works fine, but I'm not clear on what it is that you're trying to do that is breaking.

[kucint]

@dansiegel I am always eager to deliver a test app. Here you have one: UnoAppTemplateBindingNotWorking.zip
Thanks for your help.

Later on (today evening European time), I will deliver you more info what I want to achieve (meetings, meetings, meetings....)

[kucint]

@dansiegel I promised you more complex demo, here you have one: UnoAbcApp.zip

The attached UnoAbcApp does the following:

• defines MyControl custom templated control that
  • exposes three string properties: FeatureA, FeatureB, FeatureC. Consumer can bind them for reading/writing.
  • uses provided feature strings to perform "complex calculations" (in my case just concatenate all of them with "-" as separator) and present the result as TexBlock
  • each time FeatureA, FeatureB, FeatureC is changed by the consumer, the text of result TextBlock shall change.
  • I want to implement the control using both MVUX and C# Markup internally
• define MainFrame that creates an instance of MyControl and binds exposed FeatureA, FeatureB, FeatureC properties.

Expected behavior: Each time FeatureA, FeatureB, FeatureC TextBox is changed by the user, the text of result TextBlock changes.
Current behavior: Nothing happens

General question is:

• Is the design of my custom templated control appropriate? Note that I want to use both MVUX and C# Markup internally.
• Am I missing something?
• How would you do this?

[kucint]

thanks @dansiegel. I see. In this case two questions arise:

• Suggestion 1: The documentation is a bit misleading/not complete:
  • You always use the .DataContext(new BindableMyModel(), (ctrl, vm) => this syntax in all of your examples and code snippets, see counter-sample or get-started-data-binding. Even though in these cases the app will behave correctly, the developers are not aware that this syntax does not work always. I learned (wrongly) the VMU from your examples...
  • In your documentation doc/Learn/Markup#data-binding you provide info about both approaches .DataContext(new BindableMyModel(), (ctrl, vm) => this vs .DataContext<BindableMyModel>(ctrl, vm) => this, but IMO the explanation could be more specific.
• Q2: you suggest to derive MyControl from UserControl rather from Control. This is something I do not understand.
  • why the Templated Control does not support the syntax you propose?
  • if I cannot attach Model to Templated Control, how I am suppose to use Templated Control with MVU?
  • I know that these questions are 'philosophical', but I would like to deep understanding of what I am doing and what is the idea behind such a design...

[kucint]

And unfortunately your proposal does not work. See: UnoAppTemplateBindingNotWorking.v2.zip

Now I think, maybe we do not understand each other.
I try to build "control library" that will be used by many Apps. I don't want to force to consumer of the library to use any model, neither MVU or MVVM.
I as a developer of the control library, I want to create a custom control that internally uses MVU model. Internally means, the model is not public and its logic is hidden to the consumer. So the model cannot be attached to DataContext by the consumer. The consumer shall communicate with the control with help of publicly defined DependencyProperties as in attached example.
Is it feasible?

[kucint]

Even if I make a model public and set the data context from outside. it does not work.
The method is never called:

    private void OnAutoUpdateChanged(DependencyPropertyChangedEventArgs e)
    {
        Debug.WriteLine($"MyProperty Changed from [{e.OldValue}] to [{e.NewValue}]");
    }

[dr1rrb]

Hey @kucint, I've made a sample with both a UserControl and a Control that should give you some insight on how to fix your issue:
UnoAppTemplateBindingWorking.zip

The main point is really to note that a "binding" is relative to a "source". When not specified, the default/implicit source of that binding is the inherited DataContext, and all bindings on an element are relative to the DataContextof that given element.

This means that is you have:

<local:MyControl
    DataContext="{Binding PropertyA}"
    MyProperty="{Binding PropertyB}" />

the binding on MyProperty is relative to the DataContext of MYControl, so it's equivalent to:

<local:MyControl
    MyProperty="{Binding PropertyA.PropertyB}" />

In your sample as you doing this in the constructor:

public MyControl()
    => this.DataContext(new BindableMyModel(), (page, vm) => { });

You are setting a custom DataContext on this (i.e. MyControl), so at the same time you are changing the "implicit source" on all bindings on your control. So when your users (app-dev) is trying to use your control, binding are no longer relative to their data-context, but on your own data-context. For instance in your sample app:

 new MyControl()
            .AutoUpdate(x => x.Binding(() => vm.MyOption).TwoWay()) 

Here the MyOption is resolved on the BindableMyModel instanciated on the constructor of your MyControl ... and there no such property on this model.

Note: Binding written with C# markup are same bindings written in XAML. The () => vm.MyOption is only used to resolve the Path ("MyOption"), but it does not change the Source ("vm" in this case). So previous example is equivalent to <MyControl AutoUpdate="{Binding MyOption}" />.

But actually the DataContext/implicit source should be considered as user (app-dev) variable and should not be altered by a library-develloper (and arguably should never be alter at all, except by navigation engine). It's an inherited property and app-dev usually don't expect it to have been silently modified by a control (especially "containers"). For instance:

<StackPanel>
    <TextBlock x:Name="TB1" Text="{PropertyA}" />
    <Border>
        <TextBlock x:Name="TB2" Text="{PropertyA}" />
    </Border>
</StackPanel>

It seems pretty logic for TB1.Text and TB2.Text to be equals, but it would not have been possible if the Border had modified the DataContext.

The recommendation then for a library-dev is just to not use the implicit source, but instead specify it. That's what I tried to show in the sample, in multiple way, for both a Control and a UserControl (including example that alters the DataContext which are just for examples).

Note: the question to choose between Control and a UserControl is again another topic that we could also discuss tomorrow :)

[kucint]

Hi @dr1rrb, thanks for this great explanation, especially for the example app, with very detailed info.
You made my day, now I need time to consume all what I have learned.
I wish I would have such an example months ago, it would save me a lot of headache, I could never figure out the solution by my own.
I strongly recommend to make a documentation out of it, I think the community will be grateful for it :)

[francoistanguay]

Thanks for the feedback Tomasz, I already talked to David yesterday to figure out how we could make a sample+docs out of it.

It's as if nobody actually thought of "User Control" encapsulation/reuse this way. So I agree providing guidance, even though there's nothing Uno-specific about it makes sense.

[dr1rrb]

Hey @kucint, about the crash at startup when adding AutoUpdate(true) in the _defaultStyle, I opened an issue here : https://github.com/unoplatform/uno.csharpmarkup/issues/722

[kucint]

Hi @dansiegel, great, thanks!
BTW: the provided link is corrupted.

[francoistanguay]

It`s because it is a private repo. @dansiegel Make sure to update Tomasz here once issue is fixed. Thanks!