PropertyChanged handler for Dependency Property is called before OnApplyTemplate is called

[leaderanalytics]

I am running into a situation where the proprety changed handler for a dependency property is being called before OnApplyTemplate is called. In WPF I can confirm OnApplyTemplate is called first. In researching this I found this discussion which references this issue. From referenced discussion:

Generic.xaml is not processed when defined in the main app (it's rarely used, which is why we never saw this, let's track in #10327), causing OnApplyTemplate to not be called. To work around this, move the generic.xaml file to something like Styles/Controls.xaml and reference it from the app.xaml resource dictionaries:

I'm not sure what to make of this or if it even applies to my scenario. In my case the control is defined in a control library. The template for the control is defined in Themes/Generic.xaml. Should OnApplyTemplate be called first in the scenario I describe?

[jeromelaban]

Thanks for the report.

WPF and WinUI are different, and you may want to validate that the scenario against a WinAppSDK app first. It may still be that Uno behaves differently though. If you can make a repro of this behavior, we can track that in an issue.

[sam-wheat]

Repro: UnoTest-master.zip

Open CustomControl1.cs - put breakpoints in the property changed lambdas. Put a breakpoint in OnApplyTemplate.
Run the app. Properties are set as follows:

IntProperty
IntProperty2
OnApplyTemplate is called
IntProperty3

Open MainPage.xaml.cs - comment out DataContext = this; in the constructor.

Open MainPage.xaml - paste the commented line into the definiton for CustomControl1

    <localControls:CustomControl1 
        DataContext="{Binding ElementName=mainWindow}"
        IntProperty="5" 
        IntProperty2="{Binding SomeProperty}" 
        IntProperty3="{Binding ElementName=tb1, Path=Width}">
    </localControls:CustomControl1>

Run the app

Properties are set as follows:

IntProperty
OnApplyTemplate is called
IntProperty2
IntProperty3

This is really confusing to me because I inject my my ViewModels and set DataContext to the ViewModel in the constructor.

I also created this straight WinUI repo. It appears to function same as second use case above however IDK how to set the data context in the constructor so it is not an apples-to-apples comparison.

[jeromelaban]

I've tried your repro sample, and Uno behaves differently than WinUI, where I do see the following:

WinAppSDK:
IntProperty
IntProperty2
OnApplyTemplate
IntProperty3

Uno:
IntProperty
IntProperty3
IntProperty2
OnApplyTemplate

I still had to change tb1 with Witdth="100" so that the value conversion does not fail (Width is NaN when not set in WinUI).

The behavior difference between WinUI and Uno you're seeing here is caused by #3519, where the bindings, OnApplyTemplate and Loaded events are not applied in the exact same order as WinUI.

A general workaround to align behaviors for this is to either use the Loaded event or the OnNavigatedTo override.

[sam-wheat]

Thank you @jeromelaban for looking at this.

Using your .zip file, I am unable to reproduce the order of events you specify for Uno. I still get:

IntProperty
IntProperty2
OnApplyTemplate is called
IntProperty3

Is there a chance this may be dependent on some other external?

Hopefully this is on the radar for the near future.

[jeromelaban]

Fixing #3519 is something we have on our roadmap, yet it's a challenging task and won't be in the near future. It would be interesting to understand why you need this specific sequence to provide a proper stable workaround.

In most cases, relying on implicit sequences can lead to subtle bugs, mainly because bindings can be delayed, so if you have a specific scenario which explains why you needs this, it will be helpful.

[sam-wheat]

In most cases, relying on implicit sequences can lead to subtle bugs

I somewhat agree. On the other hand we expect a framework that is rational and predictable. We use implicit sequences everywhere from math int z = 5 + 2 * 10 to object initialization to pipelines and everywhere in between.

At some point the order of operations must be known and predicable. The logic to enforce order of operations can be at the framework level or in my code. If in my code I have to define it, someone else has to learn it, and I will probably have to repeat it for various controls that I write.

In my case this is not an insurmountable obstacle. I call GetTemplateChild in OnApplyTemplate and set a property of my control.

protected override void OnApplyTemplate()
{
    base.OnApplyTemplate();
    grid = (Grid)GetTemplateChild("PART_Grid");
}

One of the property changed callbacks in my control expects grid to not be null. When that callback is executed before OnApplyTemplate is called there is grief.

[jeromelaban]

I agree that frameworks need to be reliable, and we're aiming for having a behavior parity with WinUI, yet certain pieces are still slightly different. We work to find stable workarounds that do work for both Uno and WinUI, so that when we fix the behaviors, user code continues to work properly.

That being said, with the sequence in particular even on WinUI, expecting that a DependencyProperty value is set before OnApplyTemplate can generally cause issues if the user of the control does not set the property before hand. Specifically, OnApplyTemplate should expect that the property is not set, and handle changes of that property at they happen.

[leaderanalytics]

Good advice, thank you.

[ToddGlodek]

I cannot advocate strongly enough for fixing both #3519 & #2895 as quickly as possible.

[ToddGlodek]

@sam-wheat - It feels like this person is having as different manifestation of basically the same issue, WASM Data binding broken #11901. You might also find Page Loading Fails - Potentially because 2 nested XAML controls in a direct parent/child get instantiated/InitializeComponented/loaded in different order between WASM / WinUI #10276 useful as well.