I have been using the CallMethodAction behavior to call specific methods when an event is raised. The CallMethodAction can call either:
- A public method that takes no arguments and returns no value
- A public method whose signature matches that of the event handler
I had used the first option a couple of times quite successfully but had difficulty getting the second option to work using the DisplayDateChanged event for a DatePicker control. That was until I came across this post which provided me with the necessary pointers to get my DisplayDateChanged event to work. I just needed to ensure:
- The signature of my method matched that for the DisplayDateChanged event handler (of course)
- The method needed to be listed in the ViewModel I was using for the DataContext of the DatePicker control
So my markup code for the DatePicker looks like this:
<telerik:RadDatePicker .... > <i:Interaction.Triggers> <i:EventTrigger EventName="DisplayDateChanged"> <ei:CallMethodAction MethodName="SetRadioButtons" TargetObject="{Binding}" /> </i:EventTrigger> </i:Interaction.Triggers> </telerik:RadDatePicker>
And the ViewModel code for my SetRadioButtons method is declared as:
public void SetRadioButtons(object sender, CalendarDateChangedEventArgs e)
May I firstly commend you on the name of your blog, as a Silverlight Developer I recognised your poetic twist immediately! Brilliant!
Thanks in particular for point (2) above, which I’d missed when I read the API myself ~ anything that helps an MVVM “No Code Behind” policy is good to know, and this point I immediately recognised as being able to move any code-behind event, complete with event arguments, straight to the ViewModel, etc.
Although personally I prefer to avoid utilising UIElements in the ViewModel unless I can help it, sometimes its good to take the short-shift and just get on with it ~ point 2 does it with just three tags!
Thanks!
Thank you very much your post just the thing I was looking for…!