EventToCommandBehavior should have an option PassEventArgsToCommand

[MaximG1234]

Simple really, huge oversight in my opinion that EventToCommandBehavior does not have an option PassEventArgsToCommand="True|False" like every other implementation of EventToCommandBehaviour I have previously used.

I was able to get around this issue by simply creating a BaseConverterOneWay which looked like this:

public class GenericArgsValueConverter : BaseConverterOneWay<object?, object?>
{
    public override object? DefaultConvertReturnValue { get; set; }

    public override object? ConvertFrom(object? value, CultureInfo? culture)
    {
        return value;
    }
}

and adding it as such (for anyone else with the same issue)

 <mct:EventToCommandBehavior
                                Command="{Binding SelectionChanged}"
                                EventArgsConverter="{StaticResource GenericArgsValueConverter}"
                                EventName="SelectionChanged" />

Which achieved what I needed but this is pretty silly given that the overwhelming amount of users are simply going to want the EventArgs passed as they stand without any mutations.

Just my two cents...

[bijington]

It does appear that we are missing documentation on how to achieve this but it is already possible through the use of the generic EventToCommandBehavior implementation. I will aim to document this part soon but for now you can take a look at:

#569 (comment)

[MaximG1234]

Hi @bijington,
Thanks for the response and appreciate the toolkit. Fair enough, but I still would argue to you that its a bad approach. Why do I need to provide the argument type when it is unnecessary to get the binding I need working. It just seems like extraneous work. I have always used something like this for my Command Delegate

public class DelegateCommand<T> : System.Windows.Input.ICommand where T : class
{
    public event EventHandler? CanExecuteChanged;

    private readonly Predicate<T?>? _canExecute;
    private readonly Action<T?> _execute;

    public DelegateCommand(Action<T?> execute) : this(execute, null)
    {
    }

    public DelegateCommand(Action<T?> execute, Predicate<T?>? canExecute)
    {
        this._execute = execute;
        this._canExecute = canExecute;
    }

    public bool CanExecute(object? parameter)
    {
        if (this._canExecute == null)
            return true;

        return this._canExecute((T?)parameter);
    }

    public void Execute(object? parameter)
    {
        this._execute((T?)parameter);
    }


    public void RaiseCanExecuteChanged()
    {
        this.CanExecuteChanged?.Invoke(this, EventArgs.Empty);
    }
}

Which already casts the parameters to the type I need without me having to provide further information to the EventToCommandBehavior converter. Unless there has been a change to how you should implement ICommand for Maui that I don't understand I would still argue it should just be a boolean flag which passes the EventArgs as object and allows the handler to deal with it as needed.

[bijington]

I cannot vouch for why it is the way it is, this came well before my time on the toolkit. I guess the aim was to force thoughts around types being used but as you point out it isn't required inside the XAML, my only thought there is that perhaps it covers scenarios where developers are building their UIs in C# and gain benefits of type safety (a guess more than a statement).

I personally don't like the idea of the boolean flag due to the fact that the CommandParameter, Converter and then this PassEventArgsToCommand would all be mutually exclusive. We currently have an order of precedence based on whether the CommandParameter is set and then the Converter parameter and then the event args will be passed if neither are. If we had a flag to determine this it would conflict with this rule. I do suspect some of this detail is likely missing from the docs pages so I will make a note to check this.

[CliffAgius]

Closed and answered