Binding Enum as CommandParameter does not preserve type

[jeffmccormick]

Describe the bug

Enumeration values passed as command parameters get bound as Int32s rather than their enumeration type. Below is a basic example:

XAML

<Button Command={x:Bind VM.MyCommand}>
    <Button.CommandParameter>
        <local:MyEnum>SomeValue<\local:MyEnum>
    <\Button.CommandParameter>
</Button>

ViewModel

private void DoMyCommand(object parameter)
{
    parameter.GetType() // System.Int32
}

Steps to reproduce the bug

Minimal repro using template:

EnumBinding.zip

Expected behavior

Parameter gets bound as the Enumeration type.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.1.4

Windows app type

• UWP
• Win32

Device form factor

Desktop

Windows version

Windows 10 (21H2): Build 19044

Additional context

No response

[Guillermo-Santos]

tested your code and with just a cast, it should get the correct value

private void DoMyCommand(object parameter)
{
    var option = (TestEnum)parameter; // One for the first button, Two for the second (as this are the values you had set)
}

there is no problem as the basic type is just an int that represent your Enum value (or so i think)

[jeffmccormick]

So yes, I could correct this with a cast, but that is still not the expected behavior. It would be nice to have type safety. For example, using this with the Community Toolkit:

public ICommand MyCommand { get; }

public MyViewModel()
{
    MyCommand = new RelayCommand<TestEnum>(DoMyCommand); // This throws a runtime binding error due to a `Int32` to `TestEnum` type mismatch
}

private void DoMyCommand(TestEnum parameter)
{
}

[sam-wheat]

Wasted three hours on this also. Please fix.

[evelynwu-msft]

Possibly related to #6526

[michael-hawker]

I had also come across this issue back at the same time this was opened when trying to use the Community Toolkit in a Windows Template Studio (UWP) project conversion, I had posted about this confusing behavior here: CommunityToolkit/dotnet#407

The enum that's strongly typed in XAML is being passed back into the framework somewhere as an int32 instead.

[michael-hawker]

So, after having gone around debugging this same issue for an hour again earlier; and not wanting to admit defeat to resort back to int for my enum as I had done the last time...

I had an idea to try a Markup Extension to provide the value vs. the XAML system before and it led to interesting results... success!

So, while still a workaround, it does shed a bit of light on where this issue must be occurring, something with the translation of the XAML vs. to how properties are set within a MarkupExtension instead.

---

For completeness, here's the changes to show the difference. Given an enum:

namespace MyApp.Models;

public enum PaneOrientation
{
    HorizontalPreviewTop = 0,
    VerticalPreviewRight,
    HorizontalPreviewBottom,
    VerticalPreviewLeft
}

And usage of a RelayCommand (MVVM Toolkit) with that enum as a parameter:

    [RelayCommand]
    public void SwitchPaneOrientation(PaneOrientation param)
    {

This is how you traditionally call this using XAML (where there's an xmlns for your models namespace above):

<RadioButton Command="{x:Bind ViewModel.SwitchPaneOrientationCommand, Mode=OneWay}">
  <RadioButton.CommandParameter>
    <model:PaneOrientation>HorizontalPreviewTop</model:PaneOrientation>
  </RadioButton.CommandParameter>
</RadioButton>

This gets processed when the compiled bindings (.g.cs) sets the Command, ala:

            public static void Set_Windows_UI_Xaml_Controls_Primitives_ButtonBase_Command(global::Windows.UI.Xaml.Controls.Primitives.ButtonBase obj, global::System.Windows.Input.ICommand value, string targetNullValue)
            {
                if (value == null && targetNullValue != null)
                {
                    value = (global::System.Windows.Input.ICommand) global::Windows.UI.Xaml.Markup.XamlBindingHelper.ConvertValue(typeof(global::System.Windows.Input.ICommand), targetNullValue);
                }
                obj.Command = value; // Exception occurs within here
            }

An ICommandToWinRTAdapter gets constructed and initializes the command here and calls CanExecute:

It is here that the parameter is already an integer instead of the expected Enum value. (I'm not sure where/how the connection between the above managed line and this interface occurs within the XAML system, not sure if I could grab that with native debugging, but feel like hopefully this is enough info for someone in the platform team to pick up from here).

---

The Markup Extension workaround, so what happens if we construct the Enum value as part of a MarkupExtension and pass it directly to the CommandParameter property?

namespace MyApp.Helpers;

[MarkupExtensionReturnType(ReturnType = typeof(object))]
public class EnumValueExtension : MarkupExtension
{
    public Type Type { get; set; }

    public string Member { get; set; }

    protected override object ProvideValue()
    {
        return Enum.Parse(Type, Member);
    }
}

Reminder before XAML was this:

<RadioButton Command="{x:Bind ViewModel.SwitchPaneOrientationCommand, Mode=OneWay}">
  <RadioButton.CommandParameter>
    <model:PaneOrientation>HorizontalPreviewTop</model:PaneOrientation>
  </RadioButton.CommandParameter>
</RadioButton>

So instead, we change our XAML to use this instead (where helper is xmlns defined with namespace for extension):

<RadioButton Command="{x:Bind ViewModel.SwitchPaneOrientationCommand, Mode=OneWay}"
             CommandParameter="{helper:EnumValue Type=model:PaneOrientation,
                                                 Member=HorizontalPreviewTop}"/>

And we get the desired behavior instead. We can see when our CanExecute method is called now within the MVVM Toolkit RelayCommand it now is the enum value and not 0:

So, I imagine this means it's happening within the translation of the XAML markup of the Enum parsing itself, as this direct method of setting the property seems to maintain the proper type of the value.

[ZodmanPerth]

I've used @michael-hawker's markup exension and it resolved the problem for me.
Clearly there's a bug in the XAML compiler here that has a simple fix.