Microsoft.Xaml.Interactivity bug in WinUI 3 Preview 4 making further development a non starter.

[Noemata]

Microsoft.Xaml.Interactivity is not working as expected with WinUI 3 Preview 4.

As mentioned here: https://github.com/microsoft/microsoft-ui-xaml/issues/4350

Given the following XAML:

            <Frame x:Name="ContentFrame" x:FieldModifier="Public" Padding="14 14" >
                <i:Interaction.Behaviors>
                    <ic:EventTriggerBehavior EventName="Loaded">
                        <ic:InvokeCommandAction Command="{x:Bind ViewModel.FrameLoadedCommand}" CommandParameter="{Binding ElementName=ContentFrame}"/>
                    </ic:EventTriggerBehavior>
                </i:Interaction.Behaviors>
                <Frame.ContentTransitions>
                    <TransitionCollection>
                        <NavigationThemeTransition>
                            <NavigationThemeTransition.DefaultNavigationTransitionInfo>
                                <DrillInNavigationTransitionInfo />
                            </NavigationThemeTransition.DefaultNavigationTransitionInfo>
                        </NavigationThemeTransition>
                    </TransitionCollection>
                </Frame.ContentTransitions>
            </Frame>

The CommandParameter is null when it should have the value of the Frame "ContentFrame" object.

You may use the following GitHub repository: https://github.com/Noemata/SimpleMVVM

Steps to reproduce the behavior:

1. Build SimpleMVVM
2. Set a breakpoint on the if () line as shown below within the SetupNavigationService method in ShellViewModel.cs which is part of the SimpleMVVM solution (note: UWP equivalent project is also provided).

        private void SetupNavigationService(Frame frame)
        {
            // MP! fixme: why is frame null??
            if (frame != null)
                NavigationService.Frame = frame;
        }

3. Click the About "( ! ) " menu item when the app launches.

Expected behavior

CommandParameter should not be null.

Screenshot

Version

Microsoft.Xaml.Behaviors.WinUI.Managed v2.0.3-rc5

[Noemata]

@azchohfi, any suggestions/updates?

[Noemata]

ElementName bindings of the form:

<ic:InvokeCommandAction Command="{x:Bind ViewModel.FrameLoadedCommand}" CommandParameter="{Binding ElementName=ContentFrame}"/>

Are broken in WinUI 3 Preview 4. XAML Behaviors is working correctly, provided you work around such framework issues.

The above will work with an x:Bind binding like this:

<ic:InvokeCommandAction Command="{x:Bind ViewModel.FrameLoadedCommand}" CommandParameter="{x:Bind ContentFrame}"/>

To the WinUI team, please fix this ASAP. Lots of code relies on variations of binding strategies that are currently failing.

[pedrolamas]

As you very well have pointed, this is not an issue with the Xaml Behaviors but with the legacy {Binding ElementName=x} expression.

I recommend that you open it on the WinUI bug tracker, and in the meantime will close it here.

[Noemata]

@pedrolamas , agreed. It would be helpful to get a conformance chart for XAML Behaviors on the next release of WinUI, so we can see what is working. This can easily be generated through automated testing. XAML Behaviors tend to be used on most XAML projects these days, so it's an essential lib that can also be used to push compliance of WinUI across the finish line.

[pedrolamas]

@Noemata I can see your point, but at this stage WinUI is still just a (Technology) Preview, so I would be inclined to wait to get a more stable version before doing that kind of work!

[Noemata]

@pedrolamas , I imagine Microsoft having pass/fail XAML conformance test suites. Pushing the output of those into a doc file would be trivial. If such tests don't exist, then making them would be a big job.

From what I've seen so far, WinUI XAML conformance is pretty good at this stage. The missing bits and some of the breaking changes will get in the way of easily porting code over from UWP unless they are addressed. Having a nice XAML level #ifdef mechanism would be one way to work around whatever differences remain at the expense of extra work in maintaining two slightly different code paths.

I am baffled at the need to have different namespaces given the mappings are 1 to 1. Surely that could have been hidden from view when building for non UWP deployments? I don't expect backtracking on that change at this point, but it's an odd platform mistake to make given the 1 to 1 mapping.

The aim should be zero friction between UWP and WinUI. I should be able to use exactly the same code for either. As you can see from the SimpleMVVM sample provided, the adjustments are trivial, but require lots of needless tweaking had frictionless re-deployment of UWP apps been part of Microsoft's objectives for WinUI.

It's as if you folks want a hard breaking change from UWP to force devs in a new direction.