EventTo Command: difference (advantages/ disadvantages). Can't see.

[Wobeam]

Hello everyone,
Could anyone tell me about advantages od EventToCommand in contrast with classic InvokeCommandAction. Simple from the point of my experience I can't see an advantage.
Both are working. What was a reason of creation EventToCommand?

Usage EventToCommand in button

 <i:Interaction.Triggers>
                    <i:EventTrigger EventName="PreviewMouseLeftButtonDown">
                        <command:EventToCommand Command="{Binding FillwithCustomColour_command1}" />
                    </i:EventTrigger>
                    <i:EventTrigger EventName="PreviewMouseLeftButtonUp">
                        <command:EventToCommand Command="{Binding FillwithDefaultColour_command1}" />
                    </i:EventTrigger>
                </i:Interaction.Triggers>

Usage classic InvokeCommandAction in button

 <i:Interaction.Triggers>
                    <i:EventTrigger EventName="PreviewMouseLeftButtonDown">
                        <i:InvokeCommandAction Command="{Binding FillwithCustomColour_command2}" />
                    </i:EventTrigger>
                    <i:EventTrigger EventName="PreviewMouseLeftButtonUp">
                        <i:InvokeCommandAction Command="{Binding FillwithDefaultColour_command2}" />
                    </i:EventTrigger>
                </i:Interaction.Triggers>

[tonyhallett]

Comparing Microsoft.Xaml.Behaviors to MVVMLight there are noticeable differences.

Note that I am comparing the open sourced Xaml Behaviours and not System.Windows.Interactivity which is used by MVVMLight so there may be some additional differences.

Common behaviour:
Both actions derive from TriggerAction.
The desired event is handled and may result in a command's CanExecute method being called followed by Execute ( if it CanExecute) with both method receiving an argument that may be derived from the event args.

Differences:

The derived TriggerAction class:
InvokeCommandAction is a sealed class whereas EventToCommand is not.

The command itself.
With InvokeCommandAction the command can come from a property of the AssociatedObject, you specify the name of that property with the CommandName. For EventToCommand you must supply the command.

The command parameter.
For both InvokeCommandAction and EventToCommand the command parameter will be taken from CommandParameter if set. If it has not been set then there are differences. Firstly the InvokeCommandAction has an additional EventArgsParameterPath which can be used to transform the event args by dotting through the object structure.
Secondly, although both have an EventArgsConverter they are of different types, IValueConverter for InvokeCommandAction and IEventArgsConverter for EventToCommand. The behaviour is the same for each, to convert the event args perhaps using the EventArgsConverterParameter in its decision. The major difference is that for EventToCommand the converter will only be used ( if present ) when PassEventArgsToCommand whereas for InvokeCommandAction it is unrelated to PassEventArgsToCommand. For both, to have the event args, as is, you must set PassEventArgsToCommand to true.

The major difference - the additional functionality of EventToCommand
As I said before, CanExecute may be called. InvokeCommandAction will always be called ( assuming there is a command to be called ) but EventToCommand has conditional behaviour.
If the associated element is disabled and AlwaysInvokeCommand is false ( the default ) then CanExecute/Execute will not be called.
**EventToCommand provides binding from CanExecute to the associated element's IsEnabled if MustToggleIsEnabled is true **( default false ). Whenever the command CanExecuteChanged event is raised the command will be requiried ( with the command parameter ) and IsEnabled is set to the result.

Less important differences:

EventToCommand has a public Invoke method -> Invoke(null)
EventArgsConverter is a dependency property in InvokeCommandAction and not so in EventToCommand.