Add trim-safe replacements for ChangePropertyAction and EventTriggerBehavior

[sylveon]

#255 added trim annotation for various commonly used behaviors and actions. However, UWP .NET 9 requires NAOT (and by extension trimming-safe code), which meant that users migrating from UWP .NET Native to UWP .NET 9 where simply given "this behavior is not trim-safe" with no useful actionable info in the warnings. This is not helpful.

This PR adds a few behaviors and actions:

• ChangeDependencyPropertyAction, a trim-safe alternative to ChangePropertyAction which specifically targets dependency properties. This should cover many use cases that ChangePropertyAction previously covered (in our app, we where able to replace all uses with this). Use like the following:

  <ChangeDependencyPropertyAction DependencyProperty="{x:Bind wux:FrameworkElement.MarginProperty}"
                                  TargetDependencyObject="{x:Bind MyControl}">
      <Thickness>0,0,36,0</Thickness>
  </ChangeDependencyPropertyAction>

• EventTriggerBehaviorBase<T>, a trim-safe version of EventTriggerBehavior. Not useful by itself, it needs to be derived to add event registration and unregistration code. I've added a few subclasses covering the most common cases in our app, that hopefully are frequently used elsewhere as well. Additionally, I refactored the reflection-based EventTriggerBehavior to derive from EventTriggerBehaviorBase<T>, as an example of more complex subclasses (and to reduce code duplication). Use like the following:

  public class PointerWheelChangedTriggerBehavior : EventTriggerBehaviorBase<UIElement>
  {
      protected override bool RegisterEventCore(UIElement source)
      {
          source.PointerWheelChanged += OnEvent;
          return true;
      }
  
      protected override void UnregisterEventCore(UIElement source)
      {
          source.PointerWheelChanged -= OnEvent;
      }
  }

  <PointerWheelChangedTriggerBehavior>
      <InvokeCommandAction Command="{x:Bind ViewModel.OnRenderControlPointerWheelChangedCommand}" />
  </PointerWheelChangedTriggerBehavior>

These additions are backwards compatible with .NET Native, to allow progressive migration towards trim-safe patterns in an existing .NET Native UWP app, allowing easier upgrade to UWP .NET 9 or WinUI 3 down the line.

A few drive-by changes where made to improve code quality as well.

[sylveon]

All dependency properties for this class break when one of the DPs has DependencyProperty itself as its type. Meta-DPs are reserved to the framework itself apparently...

[michael-hawker]

🤔 Interesting, I know sometimes not having it as a DP could cause VS to bubble up other warnings when binding to things, but since it'd only ever be a OneTime binding sort of scenario, I can't imagine it being an issue.

[sylveon]

Advanced binding scenarios which would trigger that warning probably requires you to make your own DP-of-DP, which you aren't able to, so I think this should be fine. As you've mentioned, this is rarely ever changed at runtime.

[sylveon]

@michael-hawker any update on this? would love to get it merged

[michael-hawker]

@sylveon sorry for the delay, it may be a bit, but I too would like to get it merged. Would be good to get @Sergio0694 sign-off in the meantime. But I'll raise it up.

[sylveon]

@Sergio0694 have you been able to look at this?

[sylveon]

@michael-hawker @Sergio0694 any update?

[riverar]

@Sergio0694 Can you sign off on this while you're online and screwing around on Discord chat? Thanks buddy. ❤️

[sylveon]

@Sergio0694 @michael-hawker any update on this?

[Sergio0694]

"I refactored the reflection-based EventTriggerBehavior to derive from EventTriggerBehaviorBase"

This is a breaking change. Two options:

• Leave that as is was
• We do a new major release where we properly fix everything, and we can break stuff

But for the latter, I'd want to take that opportunity to actually fix things for real. Right now e.g. in the Store we have a lot of custom behaviors because they're "working around issues" with the ones in this package. I'd rather figure these out for good and just fix things here, so we can also delete our local versions (and also so that everyone gets the fixes).

Let me chat with some folks in the Store team first to try to understand exactly what's not working 🙂

[sylveon]

I don't believe this is breaking @Sergio0694.

.NET's own breaking change guidelines say that adding a base class is allowed: https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/breaking-change-rules.md#types

Introducing a new base class

So long as it does not introduce any new abstract members or change the semantics or behavior of existing members, a type can be introduced into a hierarchy between two existing types. For example, between .NET Framework 1.1 and .NET Framework 2.0, we introduced DbConnection as a new base class for SqlConnection which previously derived from Component.

Current class hierarchy is
EventTriggerBehavior -> Trigger -> ...

New one is
EventTriggerBehavior -> EventTriggerBehaviorBase<DependencyObject> -> Trigger<DependencyObject> -> Trigger -> ...

It does not removing any existing base classes. While it does add an abstract, EventTriggerBehavior is sealed so this is not a concern, as no one can derive from EventTriggerBehavior. Semantics aren't changed, as this is just pure code reorganization to facilitate reuse.