This project has moved and is read-only. For the latest updates, please go here.


Nov 11, 2009 at 9:46 PM

Hello Laurent,

this is maybe both a question regarding usage of the Toolkit as well as regarding general application architecture with MVVM.

I am refactoring an existing  WPF application to your toolkit and struggled with the decision if the handling of events should stay in the code-behind. Your recent blogpost about Commands bound to Events came as a blessing at just the right moment.
So far (in the old app) I am capturing user input in a richtextbox (special commands like Tab or Escape keypresses) with the KeyUp event. Using your new triggers lets me assign a Command to this event but I am at a loss how to access the information I so far got from the event arguments (in this case the actual key pressed).  Is this approach (handling such logic in the ViewModel) even a valid approach or should such stay in the code-behind. And if it is a valid use-case for your new EventCommand feature: is it possible to get the EventArgs as parameters to the command?

Thank you a lot,


Nov 11, 2009 at 11:17 PM


You make a very valid point. At the current time, there is no way to get the EventArgs and pass that as a parameter to the command. I am honestly not even sure this is possible, you gave me something to think about for the next release :) Thanks for that.

For the records, I don't think there is anything wrong with code in the code-behind, as long as it makes sense. View-related code (such as starting/stopping animations) and code such as the one you have now are OK in the code behind in my opinion. The only issue with code in the code behind is that it is harder (or even impossible) to unit test, which is why we try to find ways to minimize the amount of code there.

In your specific case, and given the fact that, as I said, I cannot grab the EventArgs, I would handle the event in the code behind, and from there execute the command. I will try to find a way to enhance EventToCommand, stay posted on my blog for additional info in case I find a way.



Nov 11, 2009 at 11:37 PM

Hi Laurent,

thank you for your quick response.

Yes - I am not afraid of using code-behind (tbh I dont foresee the need to really have this level of abstraction to the view in my case, its just MVVM simply feels more "natural" regarding the design features WPF offers).
Just it would be preferable if there was some intuitive seperation of code-behind and viewmodel code as in where to look if i am searching for a particular function in the applications code.
The way you suggest - animations etc and minimal event handlers just passing args through to a command in the code-behind is intuitive enough for me.

Again thanks for this very nice toolkit,
I am looking forward to anything you come up with and release,



Nov 11, 2009 at 11:45 PM

I didn't mean to discourage you to use VMs and Commands though ;) I am sure you got that.

For the records, I just checked and there is indeed a simple way to get the EventArgs so I can pass it to the Command. I just need to come up with a clean syntax to do that (because there is only one parameter to a Command, so I need to see how to let the user choose between the CommandParameter or the EventArgs to be passed to the RelayCommand).

Thanks a lot for this!



Nov 12, 2009 at 2:49 PM

Sounds great - I'll treat the proxy event-handlers in the code-behind as a temporary solution than :-)


Nov 13, 2009 at 4:28 PM
Edited Nov 13, 2009 at 4:29 PM

I added this feature in changeset 34855, available in the Source section of this site.

You need to set the "PassEventArgsToCommand" property to true in the EventToCommand tag to enable this feature. Then, use a RelayCommand<EventArgs> to receive the EventArgs as the parameter. I will post a sample a little later.




Nov 13, 2009 at 8:29 PM

Great! Works like a charm.

Thank you a bunch Laurent for the quick and helpful response and action.
Glad I decided on using this framework :-)


Nov 14, 2009 at 1:32 PM
Edited Nov 14, 2009 at 1:57 PM

Hi again Laurent,

just read your Blog-post regarding this issue and I certainly agree that using a WPF-specific type like KeyEventArgs or MouseButtonEventArgs in the ViewModel violates the original idea of seperation of concerns.
Guess in the end one would have to stick to the skeleton-event-handler-proxies in the code-behind which take the event-args, extract whatever parameter is of interest (in my example above the character of the keypress) and call the worker method with a char signature in the VM. Personally (being new to MVVM) I am unsure how "clean" it is to access the VM by going through the Views datacontext in the code-behind. Is that considered a best-practice? After all it strengthens the coupling of View->VM

In any way I am thankful for your shortcut which allows me to avoid having yet another level of abstraction in command-handling (reducing boilerplate code when binding a new command by 50%) while still making full use of WPF databinding. Also the app could be very easily refactored to a "full" MVVM seperation if I'd need to implement a second type f View.


Nov 15, 2009 at 9:44 AM

Hi Hinnerk,

My point in the blog post was that instead of exposing, for instance, MouseEventArgs (which is quite a "low level" UI class), maybe encapsulating the UI elements in a UserControl and exposing a higher level event on that UserControl would be better, from an abstraction point of view.

That said, I totally agree that this could be a total overkill in some smaller size projects, which is why it makes sense to have the possibility to get the EventArgs in the VM directly.



Apr 18, 2010 at 7:54 PM


As you are a previous user of the discussion tab on the MVVM Light Codeplex site, I would like to inform you that I decided to encourage the usage of StackOverflow for questions regarding the MVVM Light toolkit. Please tag your questions with the mvvm-light tag.

StackOverflow is an awesome site where tons of developers help others with their technical question.

I will monitor this tag on the StackOverflow website and do my best to answer questions. The advantage of StackOverflow over the Codeplex discussion is the sheer number of qualified developers able to help you with your questions, the visibility of the question itself, and the whole StackOverflow infrastructure (reputation, up- or down-vote, comments, etc)