I am trying to translate WPF CodeBehid events like Event, Handler, EventSetter to MVVM pattern. I am not allowed to use System.Windows.Controls since I am using MVVM. And I am also avoiding 3rd party library to solve this issue.
Can somebody explain how to convert the following CodeBehind Event Handler to MVVM Event-Handler? Please explain as much as you can while writing answer.
XAML Code
<DataGridCheckBoxColumn Header="Select" Binding="{Binding Path=IsSelected}">
<DataGridCheckBoxColumn.CellStyle>
<Style TargetType="DataGridCell">
<EventSetter Event="MouseLeftButtonUp" Handler="ApprovedMouseUp"></EventSetter>
</Style>
</DataGridCheckBoxColumn.CellStyle>
</DataGridCheckBoxColumn>
Code Behind
private void ApprovedMouseUp(object sender, MouseButtonEventArgs e)
{
if(sender is DataGridCell)
{
var temp = (sender as DataGridCell).Content;
if(temp is CheckBox) (temp as CheckBox).IsChecked = !(temp as CheckBox).IsChecked;
}
}
There are few thumb rules regarding MVVM....
Your Models and ViewModles should not refer System.Windows.Controls namespace.
Your Models and ViewModles should not handle events. Use ICommand interface for that.
RoutedCommand is not valid in Models / ViewModels (due to point 2). Hence use DelegateCommand / RelayCommand
Having said that, all the above points are perfectly allowed if you have written an Attached Behavior in MVVM.
You have a couple of choices:
Attach the event handler in XAML but the only thing the event handler does is call into the view model passing in the appropriate arguments (it's important not to pass any GUI level items to the view model -- just the data necessary to perform the action)
Use the EventToCommand behavior (showcased here) to attach an instance of an ICommand (from your view model) to an event in your view
As long as you're not trying to set these event handlers up in styles or templates I would recommend pursuing option #1 -- there is no iron law prohibiting you from using event handlers when convenient, as long as the view model is what actually performs all the work
Edit: Option #1
private void ApprovedMouseUp(object sender, MouseButtonEventArgs e)
{
if(sender is DataGridCell)
{
var checkBox= (sender as DataGridCell).Content as CheckBox;
if(checkBox != null)
{
var viewModel = (MyViewModel)checkBox.DataContext;
viewModel.ToggleApprovedStatus();
}
}
}
You can also use Caliburn Micro libraries to be able to attach a handler in ViewModel to an event in View.
Sample code:
... xmlns:cal="clr-namespace:Caliburn.Micro;assembly=Caliburn.Micro"....
<Button Content="Edit" DataContext="{Binding Path=VmInstance}"
cal:Message.Attach="[Event Click] = [Action EditFilter]" />
Related
i'm developing a WPF application with MVVM.
At the XAML code i have a Grid with its DataContext pointing to a ViewModel, and i need to know if it is possible to change the DataContext at runtime to access an event at its code-behind.
Code-behind for the view:
public partial class MainWindow : Window
{
public MainWindow()
{
this.DataContext = new MainViewModel();
InitializeComponent();
}
private void ValidationEvent(object sender, ValidationErrorEventArgs e)
{
//Something useful
}
}
Here is the code that i tried in XAML:
<Grid Validation.Error={Binding Path=ValidationEvent RelativeSource={RelativeSource Self}}/>
The XAML code throws an XamlParseException telling that it is not possible to do the Binding on an "AddErrorHandler", that it is only possible for a DependencyProperty on a DependencyObject.
I don't want to change the DataContext of the Grid because inside it there are elements that access the MainViewModel properties, so i just want to change the DataContext for the Validation.Error event binding... If it is possible...
Thanks.
Validation.Error is an event, not a property. You can't set Bindings to events.
You can use things like MVVM Light's EventToCommand, or Microsoft's own Interactivity EventTrigger to associate Commands to Events.
But there really isn't anything wrong with just adding a regular event handler in code-behind and calling some viewmodel code from there... Contrary to what many people seem to think, MVVM doesn't forbid the use of code-behind and what you'd be doing is not very different from what an EventToCommand or an EventTrigger are doing under the hood.
First of all, just set the event handler name for the Validation.Error event.
<Grid Validation.Error="ValidationEvent" />
And then in your code-behind do whatever you want.
private void ValidationEvent(object sender, ValidationErrorEventArgs e)
{
// Something useful
// Some call to VM code
(this.DataContext as MainViewModel).SomeMethod();
}
This works independently of your DataContext (as long as you cast this.DataContext to the correct type, of course).
Event handlers don't depend on your DataContext, only Bindings do.
In the view (AudioView.xaml) i have written the following code
<Slider
Name="AudioSlider"
Width="200"
Height="23"
Grid.Column="0"
IsSelectionRangeEnabled="True"
IsSnapToTickEnabled="True"
Maximum="{Binding Path=TotalAudioPlayingSeconds, Mode=OneTime}"
Minimum="0"
Style="{StaticResource CustomStyleForSlider}"
Thumb.DragCompleted="{Binding AudioSliderChangedCommand}"
TickFrequency="1"
Value="{Binding Path=AudioPosition}"/>
Note: Also there is file AudioView.xaml.cs.
In the view model class(AudioViewModel.cs) i defined the following property
public event DragCompletedEventHandler AudioSliderChangedCommand;
and in the constructor of view model class (AudioViewModel.cs)
this.AudioSliderChangedCommand = new DragCompletedEventHandler(OnAudioSliderChanged);
During the compilation i am getting the following error
Error 8 DragCompleted="{Binding AudioSliderChangedCommand}" is not
valid. {Binding AudioSliderChangedCommand} is not a valid event
handler method name. Only instance methods on the generated or
code-behind class are valid.
The problem is not in your code-behind, but in your XAML. Somewhere you do this:
DragCompleted="{Binding AudioSliderChangedCommand}"
This instructs the XAML deserializer to attach the AudioSliderChangedCommand handler to the DragCompleted event. However, AudioSliderChangedCommand is not a method with the appropriate signature (which can be attached as a handler) and it is not in your View class. And finally, you can't use Binding for event handlers.
To solve this, the simplest solution is to do this in your View:
private void DragCompletedEventHandler(object sender, DragCompletedEventArgs e)
{
var viewModel = (YourViewModelType)this.DataContext;
viewModel.OnAudioSliderChanged(this, e);
}
and also change
DragCompleted="{Binding AudioSliderChangedCommand}"
to
DragCompleted="DragCompletedEventHandler"
in your XAML.
This is how the above will work:
In your View, when DragCompleted is raised, the method View.DragCompletedEventHandler will be called
This method will get hold of the AudioSliderChangedCommand event (see note below) from the ViewModel and raise it, passing the original event args
Important note
You seem to be confused about events, event handlers and commands. Your code as it stands is misleading. AudioSliderChangedCommand is an event, but the name suggests it's an ICommand. The appropriate name would be AudioSliderChanged.
Also, the appropriate MVVM way of doing this is by using some flavor of DelegateCommand (all decent MVVM frameworks have one; I used the class name for the implementation in Prism). Then, assuming that AudioSliderChangedCommand is indeed a command, the code-behind in your View would be:
private void DragCompletedEventHandler(object sender, DragCompletedEventArgs e)
{
var viewModel = (YourViewModelType)this.DataContext;
viewModel.AudioSliderChangedCommand.Execute();
}
It would also be possible to do without any code-behind at all by using some flavor of "event to command" attached behavior.
I am using commanding in my viewmodel to handle events. like for example I am handling a button click event like this:
XAML
<i:Interaction.Triggers>
<i:EventTrigger EventName="Click">
<i:InvokeCommandAction Command="{Binding mvvmButtonclick}" />
</i:EventTrigger>
</i:Interaction.Triggers>
Viewmodel Code
public ICommand mvvmButtonclick
{
get;
private set;
}
Viewmodel Constructor code to wireup the command
this.mvvmButtonclick = new ActionCommand(this.ButtonClickedEvent);
Actual method in the viewmodel that gets called on button click
private void ButtonClickedEvent()
{
MessageBox.Show("worked!!!");
}
This works. So my questions are:
Is this the correct way?
Is there a way I can propogate the (object sender, RoutedEventArgs e) parameters into my viewmodel and should I care if its not there?
Suppose if this were a listbox selection changed event and not a button click. How do I get the value of the selected item without the object sender, SelectionChangedEventArgs e parameters?
I think you may be missing the point of the separation between view and view-model that the interaction triggers are designed to provide.
The purpose of the interaction triggers is to allow the designer (typically using Blend) to invoke a command on the view model. Which UI element and which event on the UI element might invoke such a command is the designers choice.
If the ViewModel though did require that a specific derivative of the EventArgs be provided during such a call to a command then that would tie the designers hands a little. It would create the sort of coupling between the view and view-model that interaction triggers aspires to eliminate.
As to your final question, the way to determine the currently selected item in a list box and be notified when it changes would be to create a property on the view model that is the bound to the SelectedItem of the ListBox. There is no need to employee interaction triggers or commands for this sort of thing.
There are some frameworks (such as Catel), that allow the forwarding of the EventArgs. For example, see this implementation:
http://catel.codeplex.com/SourceControl/changeset/view/508b404f2c57#src%2fCatel.Windows35%2fMVVM%2fCommands%2fCommand.cs
The class is compatible with both Silverlight and WPF.
If you don't want to use the EventArgs, you will need to create a SelectedObject property on the ViewModel and bind it to the SelectedItem of the listbox.
Catel includes 2 example applications (both in WPF and Silverlight) that use MVVM and the EventToCommand class to edit a selected item in a listbox. I think that is what you are looking for!
i'm just starting with the mvvm model in Silverlight.
In step 1 i got a listbox bound to my viewmodel, but now i want to propagate a click in a button and a selecteditemchanged of the listbox back to the viewmodel.
I guess i have to bind the click event of the button and the selecteditemchanged of the listbox to 2 methods in my viewmodel somehow?
For the selecteditemchanged of the listbox i think there must also be a 'return call' possible when the viewmodel tries to set the selecteditem to another value?
i come from a asp.net (mvc) background, but can't figure out how to do it in silverlight.
Roboblob provides excellent step-by-step solution for Silverlight 4. It strictly follows MVVM paradigm.
I would not bind or tie the VM in any way directly to the events of controls within the View. Instead, have a separate event that is raised by the View in response to the button click.
[disclaimer: this code is all done straight from my head, not copy & pasted from VS - treat it as an example!!]
So in pseudo code, the View will look like this:
private void MyView_Loaded(...)
{
MyButton.Click += new EventHandler(MyButton_Click);
}
private void MyButton_Click(...)
{
//Raise my event:
OnUserPressedGo();
}
private void OnUserPressedGo()
{
if (UserPressedTheGoButton != null)
this.UserPressedTheGoButton(this, EventArgs.Empty);
}
public EventHandler UserPressedTheGoButton;
and the VM would have a line like this:
MyView.UserPressedTheGoButton += new EventHandler(myHandler);
this may seem a little long-winded, why not do it a bit more directly? The main reason for this is you do not want to tie your VM too tightly (if at all) to the contents of the View, otherwise it becomes difficult to change the View. Having one UI agnostic event like this means the button can change at any time without affecting the VM - you could change it from a button to a hyperlink or that kool kat designer you hire may change it to something totally weird and funky, it doesn't matter.
Now, let's talk about the SelectedItemChanged event of the listbox. Chances are you want to intercept an event for this so that you can modify the data bound to another control in the View. If this is a correct assumption, then read on - if i'm wrong then stop reading and reuse the example from above :)
The odds are that you may be able to get away with not needing a handler for that event. If you bind the SelectedItem of the listbox to a property in the VM:
<ListBox ItemSource={Binding SomeList} SelectedItem={Binding MyListSelectedItem} />
and then in the MyListSelectedItem property of the VM:
public object MyListSelectedItem
{
get { return _myListSelectedItem; }
set
{
bool changed = _myListSelectedItem != value;
if (changed)
{
_myListSelectedItem = value;
OnPropertyChanged("MyListSelectedItem");
}
}
}
private void OnPropertyChanged(string propertyName)
{
if (this.NotifyPropertyChanged != null)
this.NotifyPropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
To get that NotifyPropertyChanged event, just implement the INotifyPropertyChanged interface on your VM (which you should have done already). That is the basic stuff out of the way... what you then follow this up with is a NotifyPropertyChanged event handler on the VM itself:
private void ViewModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
switch (e.PropertyName)
{
case "MyListSelectedItem":
//at this point i know the value of MyListSelectedItem has changed, so
//i can now retrieve its value and use it to modify a secondary
//piece of data:
MySecondaryList = AllAvailableItemsForSecondaryList.Select(p => p.Id == MyListSelectedItem.Id);
break;
}
}
All you need now is for MySecondaryList to also notify that its value has changed:
public List<someObject> MySecondaryList
{
get { return _mySecondaryList; }
set
{
bool changed = .......;
if (changed)
{
... etc ...
OnNotifyPropertyChanged("MySecondaryList");
}
}
}
and anything bound to it will automatically be updated. Once again, it may seem that this is the long way to do things, but it means you have avoided having any handlers for UI events from the View, you have kept the abstraction between the View and the ViewModel.
I hope this has made some sense to you. With my code, i try to have the ViewModel knowing absolutely zero about the View, and the View only knowing the bare minimum about the ViewModel (the View recieves the ViewModel as an interface, so it can only know what the interface has specified).
Regarding binding the button click event I can recommend Laurent Bugnion's MVVM Light Toolkit (http://www.galasoft.ch/mvvm/getstarted/) as a way of dealing with this, I'll provide a little example, but Laurent's documentation is most likely a better way of understanding his framework.
Reference a couple of assemblies in your xaml page
xmlns:command="clr-namespace:GalaSoft.MvvmLight.Command;assembly=GalaSoft.MvvmLight.Extras"
xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
add a blend behaviour to the button
<Button Content="Press Me">
<i:Interaction.Triggers>
<i:EventTrigger EventName="Click">
<command:EventToCommand Command="{Binding ViewModelEventName}"/>
</i:EventTrigger>
</i:Interaction.Triggers>
</Button>
and create the event within your viewmodel which will be called when the button is clicked
public RelayCommand ViewModelEventName { get; protected set; }
...
public PageViewModel()
{
ViewModelEventName = new RelayCommand(
() => DoWork()
);
}
This supports passing parameters, checking whether execution is allowed etc also.
Although I haven't used it myself, I think the Prism framework also allows you to do something similar.
I am just getting started with MVVM and im having problems figuring out how I can bind a key press inside a textbox to an ICommand inside the view model. I know I can do it in the code-behind but im trying to avoid that as much as possible.
Update: The solutions so far are all well and good if you have the blend sdk or your not having problems with the interaction dll which is what i'm having. Is there any other more generic solutions than having to use the blend sdk?
First of all, if you want to bind a RoutedUICommand it is easy - just add to the UIElement.InputBindings collection:
<TextBox ...>
<TextBox.InputBindings>
<KeyBinding
Key="Q"
Modifiers="Control"
Command="my:ModelAirplaneViewModel.AddGlueCommand" />
Your trouble starts when you try to set Command="{Binding AddGlueCommand}" to get the ICommand from the ViewModel. Since Command is not a DependencyProperty you can't set a Binding on it.
Your next attempt would probably be to create an attached property BindableCommand that has a PropertyChangedCallback that updates Command. This does allow you to access the binding but there is no way to use FindAncestor to find your ViewModel since the InputBindings collection doesn't set an InheritanceContext.
Obviously you could create an attached property that you could apply to the TextBox that would run through all the InputBindings calling BindingOperations.GetBinding on each to find Command bindings and updating those Bindings with an explicit source, allowing you to do this:
<TextBox my:BindingHelper.SetDataContextOnInputBindings="true">
<TextBox.InputBindings>
<KeyBinding
Key="Q"
Modifiers="Control"
my:BindingHelper.BindableCommand="{Binding ModelGlueCommand}" />
This attached property would be easy to implement: On PropertyChangedCallback it would schedule a "refresh" at DispatcherPriority.Input and set up an event so the "refresh" is rescheduled on every DataContext change. Then in the "refresh" code just, just set DataContext on each InputBinding:
...
public static readonly SetDataContextOnInputBindingsProperty = DependencyProperty.Register(... , new UIPropetyMetadata
{
PropertyChangedCallback = (obj, e) =>
{
var element = obj as FrameworkElement;
ScheduleUpdate(element);
element.DataContextChanged += (obj2, e2) =>
{
ScheduleUpdate(element);
};
}
});
private void ScheduleUpdate(FrameworkElement element)
{
Dispatcher.BeginInvoke(DispatcherPriority.Input, new Action(() =>
{
UpdateDataContexts(element);
})
}
private void UpdateDataContexts(FrameworkElement target)
{
var context = target.DataContext;
foreach(var inputBinding in target.InputBindings)
inputBinding.SetValue(FrameworkElement.DataContextProperty, context);
}
An alternative to the two attached properties would be to create a CommandBinding subclass that receives a routed command and activates a bound command:
<Window.CommandBindings>
<my:CommandMapper Command="my:RoutedCommands.AddGlue" MapToCommand="{Binding AddGlue}" />
...
in this case, the InputBindings in each object would reference the routed command, not the binding. This command would then be routed up the the view and mapped.
The code for CommandMapper is relatively trivial:
public class CommandMapper : CommandBinding
{
... // declaration of DependencyProperty 'MapToCommand'
public CommandMapper() : base(Executed, CanExecute)
{
}
private void Executed(object sender, ExecutedRoutedEventArgs e)
{
if(MapToCommand!=null)
MapToCommand.Execute(e.Parameter);
}
private void CanExecute(object sender, CanExecuteRoutedEventArgs e)
{
e.CanExecute =
MapToCommand==null ? null :
MapToCommand.CanExecute(e.Parameter);
}
}
For my taste, I would prefer to go with the attached properties solution, since it is not much code and keeps me from having to declare each command twice (as a RoutedCommand and as a property of my ViewModel). The supporting code only occurs once and can be used in all of your projects.
On the other hand if you're only doing a one-off project and don't expect to reuse anything, maybe even the CommandMapper is overkill. As you mentioned, it is possible to simply handle the events manually.
The excellent WPF framework Caliburn solves this problem beautifully.
<TextBox cm:Message.Attach="[Gesture Key: Enter] = [Action Search]" />
The syntax [Action Search] binds to a method in the view model. No need for ICommands at all.
Perhaps the easiest transition from code-behind event handling to MVVM commands would be Triggers and Actions from Expression Blend Samples.
Here's a snippet of code that demonstrates how you can handle key down event inside of the text box with the command:
<TextBox>
<i:Interaction.Triggers>
<i:EventTrigger EventName="KeyDown">
<si:InvokeDataCommand Command="{Binding MyCommand}"/>
</i:EventTrigger>
</i:Interaction.Triggers>
</TextBox>
The best option would probably be to use an Attached Property to do this. If you have the Blend SDK, the Behavior<T> class makes this much simpler.
For example, it would be very easy to modify this TextBox Behavior to fire an ICommand on every key press instead of clicking a button on Enter.