XAML Compiler support for RoutedEvent Strategies

[maxkatz6]

Right now all event handlers are registered with Direct | Bubble strategy.
But it's pretty common to have a case when Tunnel strategy is needed.

In WPF/UWP they had Preview*** prefix for events, which basically requires to duplicate all events in this way. We already went in a different path, and I personally don't like this whole idea of duplicating events.

So to avoid code-behind for each Tunnel event handler, we need some XAML support.
Here I have some ideas, but please add yours.

Note:

• it needs to be a valid XML.
• Technically, ":" can be a valid part of the method in IL code
• Ideally it should be compatible with something like PointerPressed.Tunnel="{x:Static StaticClass.EventHandler}"

My current ideas:

1. PointerPressed="OnPointerPressed:Tunnel" also supporting PointerPressed="OnPointerPressed: Tunnel | Bubble"
2. PointerPressed="Tunnel: OnPointerPressed"
3. PointerPressed="OnPointerPressed, Tunnel" also supporting PointerPressed="OnPointerPress
4. PointerPressed.Tunnel="OnPointerPressed"
5. PointerPressed="{Binding #ThisWindow.OnPointerPressed, Strategy=Tunnel}" (we will end up with binding to events anyway at some point, IMO)
6. PreviewPointerPressed="OnPointerPressed" (special XAML compiler magic, this event doesn't exist)

<Button>
   <Button.PointerPressed>
        <RoutedEventHandler Method="OnPointerPressed" Strategy="Tunnel" />
   </Button.PointerPressed>
</Button>

[maxkatz6]

Off-topic: github pools could be way better, if I was able to include rich text content right in the options.

[robloo]

Interesting, going to think about this some more for sure

[stevemonaco]

Option 8. A new MarkupExtension could be made instead to perhaps avoid XAML compiler work unless you plan to reuse this work to simplify other areas, too. Also avoids adding complexity to the Binding MarkupExtension. It's more verbose, but enables some niche scenarios. Simple code-behind handler:

PointerPressed="{Handler DrawPixel, Strategy=Tunnel}" basically the same as Option 5. Subscribes to event in code-behind.

The following would handle the event on the VM and use a converter to convert PointerPressedEventArgs (an Avalonia type) to something more VM-friendly. The RoutedEventArgs would be passed implicitly as a CommandParameter.

PointerPressed="{Handler ((vm:ArtboardViewModel)DataContext).DrawPixelCommand, Strategy=Tunnel, Converter={x:Static PressedArgsToPointConverter}}"

I still really like the simplicity of the first option though and it covers my needs. I don't have an issue handling the event in code-behind and forwarding it into the VM, if necessary. Some thought should go into discoverability while typing these into the IDE.

[maxkatz6]

The thing is, UWP x:Bind already allows binding to events. And I was considering to extend our bindings syntax a little. Just never had enough time.

And allow something like this:

Event=“{Binding Submit(#txtBox.Text, $args.EventArgsProp.ToString())}”

But it would require some missing features in Bindings infra itself (aside from compiler)

• it’s essentially a multi binding, as it has multiple different sources in the single binding
• different sources can be processed and used as arguments in the function

[maxkatz6]

But, for the beginning, normal UWP-like syntax would work fine:
Click={Binding ViewModelOnClick, Strategy=Tunnel}

Where ViewModelOnClick needs to be either empty, or with single args parameters, or full even handler. Same as in UWP.
(except uwp doesn’t allow strategy parameter)

[stevemonaco]

Where ViewModelOnClick needs to be either empty, or with single args parameters, or full even handler. Same as in UWP. (except uwp doesn’t allow strategy parameter)

I guess it's not sensible to make restrictions on your side regarding handler signatures. The end developer will have to be disciplined enough to maintain MVVM purity or decide it's worth breaking. For reference, here are the scenarios when binding to an event handler method in a VM with respect to MVVM purity.

public void ViewModelOnPointerPressed() <-- No args, so might not be useful if you need mouse coordinates
public void ViewModelOnPointerPressed(PointerPressedEventArgs e) <-- Now the VM knows about the View system (Avalonia)
public void ViewModelOnPointerPressed(object? sender, PointerPressedEventArgs e) <-- Worse, now the VM has a View reference
public void ViewModelOnPointerPressed(ViewModelPoint point) <-- Good, has View-neutral type ViewModelPoint, needs conversion though.

[workgroupengineering]

In WPF/UWP they had Preview*** prefix for events, which basically requires to duplicate all events in this way. We already went in a different path, and I personally don't like this whole idea of duplicating events.

It is not necessary to duplicate the events, just adopt the strategy I used here

With the same strategy you could handle all other types of events without complicating the syntax too much.

For binding the event to the VM I like this syntax:

Event=“{Binding Submit(#txtBox.Text, $args.EventArgsProp.ToString())}”

[maxkatz6]

Yeah, it's option 6 "PreviewPointerPressed="OnPointerPressed" (special XAML compiler magic, this event doesn't exist)". Didn't really got any votes

[maxkatz6]

Still, mentioning attached events here is important.
Because, suddenly, this syntax is unlikely to be valid:

Button.Click.Tunnel="OnPointerPressed"

[workgroupengineering]

Yeah, it's option 6 "PreviewPointerPressed="OnPointerPressed" (special XAML compiler magic, this event doesn't exist)". Didn't really got any votes

I've seen, but the pool has little value compared to the number of users. I like the Preview syntax because for those who come from WPF or UWP like me, they would immediately find themselves at home.

[Mrxx99]

What would happen if the original event name already starts with Preview but is a bubble event? Would there be a PreviewPreview or would this be skipped?

For me to that one can use Preview* even no declaration exists with that name is a bit too much magic. I would prefer something like Event.Tunnel="" or Event="..., Strategy=Tunnel"