Pass EventArgs for SingleEventCommand as CommandParameter


Passing the EventArgs for the SingleEventCommand would be more helpful than passing null. Example: Passing KeyEventArgs for KeyDown would let you only execute some logic if a certain key was pressed.
To make this change, simply pass the EventArgs through as a parameter in the OnEventRaised method of the EventHooker class.
/// Runs the ICommand when the requested RoutedEvent fires
/// </summary>
private void OnEventRaised(object sender, EventArgs e)
    ICommand command = (ICommand)(sender as DependencyObject).
    if (command != null)
        command.Execute(e); // <--- change this from null to e to pass EventArgs
Closed Nov 27, 2011 at 5:15 PM by sachabarber


sachabarber wrote Dec 5, 2009 at 8:12 PM

Sending the eventArgs like this would not mean a thing, as you are hooking up an event from all sorts of Events, and just using polymorphism to allow EventArgs to be used to fire the OnEventRaised. But that could have come from any one of a hundred events, and the only command base class is EventArgs, so unless the ViewModel knows exactly what event the ICommand in the VM was fired for it will not be able to know what to cast the ICommand parameters back to to match the EventArgs for the original UI elements event.

Besides this, I do not feel the VM should know anything about EventsArgs of any sort, what if I switched to using SL with my ViewModels or maybe even ASP .NET, that would not be cool as I would have my ViewModel referencing non SL or ASP .NET Dlls, Uncool

If you look at the SingleEventCommand now, you can see there is a CommandParameter property you can use in your XAML which you could use to pass a parameter to the ViewModel ICommand.

sevententh wrote Dec 17, 2009 at 11:49 AM

Could you give an example at the ViewModel end? Is the set up similar to SimpleCommand? I'm not sure how you get the commandArgs in the VM
public class MyViewModel
private SimpleCommand dropCommand

public MyViewModel() 
   dropCommand = new SimpleCommand
        CanExecuteDelegate = x => true,
        ExecuteDelegate = x => ExecuteDropCommand()                    

private void ExecuteDropCommand()
    DropCommand.CommandSucceeded = false;
//work action here
    DropCommand.CommandSucceeded = true;

public SimpleCommand DropCommand
    get { return dropCommand; }


sevententh wrote Dec 17, 2009 at 1:38 PM

Never mind, figured it out in the end! I needed to change the dropCommand new statement

public MyViewModel()
dropCommand = new SimpleCommand();
dropCommand.CanExecuteDelegate += new Predicate<object>(dropCommand_CanExecute);
dropCommand.ExecuteDelegate += new Action<object>(ExecuteDropCommand);
private void ExecuteDropCommand(object sender)
SCommandArgs param = (SCommandArgs)sender;

Is this the correct way??

DanielRose wrote Jan 29, 2010 at 2:30 PM

Currently the parameter is passed. At least how the execution of the linked RoutedCommand is done, this is necessary IMHO.

In my case, I have a window consisting of multiple Views and associated ViewModels, all looking at different parts of my Model. For example I have a TreeView of the data structure (done as in http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx , using the Cinch classes), and different views for editing the data of individual nodes, or for commands associated with certain node types, etc.

What this means is that I have views embedded in other views. Using the attached command behaviour, I respond to certain events (ex. LeftMouseButtonUp). With routed events, this bubbles up, firing the event until it is marked as handled. Thus, I need a way to mark the event as handled in the ViewModel, otherwise the "outer" ViewModels will overwrite the changes done by the innermost ViewModel, which handled the event (in my case selecting an item in the TreeView).

An alternative to casting to RoutedEventArgs in my ViewModel and setting Handled to true, you would have to have some sort of technology-independent way of saying that the event was actually handled in Cinch.

wrote Mar 5, 2010 at 10:49 AM

sachabarber wrote May 2, 2010 at 6:34 AM

This is fixed now

wrote Nov 27, 2011 at 5:15 PM

wrote Feb 21, 2013 at 11:07 PM

wrote May 16, 2013 at 10:46 AM