I have a usercontrol with a command, what I would like to do is execute this command from the containing view's ViewModel.
This would be easy to accomplish in the code behind, as I could just go "UserControl.MyCommand.Execute", but of course I want to be able to do this in the ViewModel.
In theory, what I would like to do is bind the UserControl's Command to a Command on the ViewModel which I can execute and will then be handled by the UserControl. Something like this:
...
<local:MyControl
MyCommand="{Binding ViewModelsCommand}" />
...
Of course this will have the opposite affect to what I want to do, as now the ViewModelsCommand is bound to MyCommand. So how to invert this?
Basically I want to be able to bind something like this:
ViewModelsCommand="{Binding MyControl.MyCommand}"
Any ideas or inspiration would be welcomed, I can't see a binding Mode that would let me do this. And I'm not sure how to access the DataContext's properties for binding (usually you would do just bind and have twoway handle this, but of course that doesn't work in this scenario).
Thanks in advance.
You are instantiating the view-model in the constructor of the view.
Why not set the value explicitly upon construction?
public SomeView()
{
var viewModel = new SomeViewModel();
viewModel.ViewModelCommand = MyCommand; // or = myControl.MyCommand
DataContext = viewModel;
}
It is possible to use a binding with OneWayToSource, TwoWay, or Explicit, but you still have to explicitly update source at least once in code (always if you use Explicit).
myControl.GetBindingExpression(MyControl.MyCommandProperty).UpdateSource();
I use PRISM's EventAggregator, or MVVMLight's Messenger to allow two ViewModels to talk, but your case looks slightly different where you have a view(UserControl) talking to a ViewModel.
Please note, the following answer is not correct. It seems that OneWayToSource only updates after the target-property has changed. However I don't delete this answer to inform other people which are not aware of this behaviour (like me).
Old answer (see text above)
IMO your example should work (if MyControl.MyCommand is a public property that returns an ICommand). Have you tried the BindingMode OneWayToSource?
<local:MyControl
MyCommand="{Binding ViewModelsCommand,Mode=OneWayToSource}" />
Related
I have a main window coupled with a view model.This main window uses a usercontrol which also has its own viewmodel.
What I would like to achieve is setting a binding in the main window's xaml between one of its viewmodel's custom property and one of the usercontrol's viewmodel's custom property.
How would one go about doing that?
Could you instead use the ViewModels as projections of a Model?
That is, could you have a class that holds the state (or actions) that both the VMs need to expose and have both the VMs reference this class?
If for some reason you have to couple views to something outside their own DataContext I believe you can only go up the visual tree by using RelativeSource FindAncestor in the binding. I don't think you can traverse down (e.g. Window -> Control).
If you really want to Bind them together you could make your ViewModel's properties Dependency Properties and your ViewModel derive from DependencyObject - then you could do..
var binding = new Binding("Something");
binding.Source = myViewModel1;
binding.Mode = BindingMode.TwoWay;
BindingOperations.SetBinding(viewModel2,ViewModelType.SomethingProperty,binding);
If this is a good design having your viewmodels derive from DependencyObject is another question..
You could also try looking at this library that allows binding to and from POCOs.
I ended up not using a modelview for my usercontrol, not as neat but at least it works and is less complicated datacontext wise.
Thanks to all.
I have a ViewModel that uses a DelegateCommand property to bind to a Button's Command property.
The problem is my sample data does not like the DelegateCommand object. It complains that: The type "DelegateCommand" does not include any accessible constructors. Also, the only exposed property is the IsActive property.
<local:MyViewModel xmlns:local="clr-namespace:MyNamespace"
xmlns:prism="http://www.codeplex.com/prism">
<local:MyViewModel.Age>47</local:MyViewModel.Age>
<local:MyViewModel.PurchaseAlcohalCommand>
<prism:DelegateCommand IsActive="True" />
</local:MyViewModel.PurchaseAlcohalCommand>
</local:MyViewModel>
Change your view model to expose an ICommand instead of a DelegateCommand. DelegateCommand is just an implementation of ICommand; if you later want to switch to RelayCommand from MvvmLight your view and your sample data should not have to care.
I'm not sure that this will solve your problem, but I suspect it might. Plus it's just a good programming practice.
The way your DelegateCommand is setup, it won't do anything when it is activated. If that is the desired behavior, my suggestion would be to simply not declare it. WPF will gracefully handle being bound to a null ICommand object.
Alternatively, if you need it to bind to an instantiated DelegateCommand, you could subclass DelegateCommand to include a parameterless constructor.
If you wanted it to bind to a DelegateCommand and you wanted that DelegateCommand to actually DO something when the command is triggered, that would get a bit more complicated. You would have to use the subclassed DelegateCommand I mentioned before, but you would also have to be able to define a delegate in XAML. I think there are samples out there, but I would guess they involve things like markup extensions and things of those nature. Your return on investment in this approach may be a little low, but your mileage may vary.
One last alternative that is the way this is typically handled: define your DelegateCommands in the constructor of your ViewModel.
I have been reading about MVVM pattern from various sources like MSDN:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
In that article it says: Unlike the Presenter in MVP, a ViewModel does not need a reference to a view.
If the View (XAML) assumes it's DataContext is the ViewModel then where in the code is the following line:
view.DataContext = viewModel;
The ViewModel doesn't know anything about the view so it cannot set the datacontext. If I give the ViewModel the reference do I break the MVVM pattern? My other choice is to have some kind of Builder or extra Presenter whose only job is to wire the whole thing (wait for the loaded event of the View, set the DataContext).
I know different view's can share the same DataContext (e.g. set the DataContext only for the mainwindow and others will see it) but in many cases that is not possible at all nor even feasible.
This is a great question that has many answers. It all depends on how you want to architect your application. For instance, I use dependency injection to create my IViewModel, which in turn creates my IView and my IViewModel runs an IView.SetViewModel(this) on the constructor.
Other people may wish to use a more Blendable method by setting the DataContext in the Xaml:
<UserControl.DataContext>
<ns:CrazyViewModel />
</UserControl.DataContext>
Sometimes the DataContext can be implied so it is set by the framework, like in the instance of a DataTemplate used by an ItemsControl. This is also pretty common in desktop WPF because it supports typed DataTemplates.
So there really isn't a wrong way to set the DataContext, just as long as what you have separates concerns, is maintainable and is also easily testable.
Shawn Wildermuth has a great post about whether the View or ViewModel comes first:
http://wildermuth.com/2009/05/22/Which_came_first_the_View_or_the_Model
I like, and use, his marriage concept where a 3rd party class creates both the view and viewmodel, and then associates the two. It's worked well for me.
I use MVVM a lot in with Prism. In Prism I use Unity for dependecy injection. Therefore I have an interface for every class registered with Unity including the View.
The IView interface has a method like this:
void SetViewModel(object viewModel);
The ViewModel calls this method at the end of its constructor, passing itself as a parameter:
public ViewModel(IView view, ...)
{
...
this._view=view;
this._view.SetViewModel(this);
}
In the View.xaml.cs the IView interface is implemented. This will be the only code I add to the codebehind of the view:
public partial class View:UserControl, IView
{
public View()
{
...
}
public SetViewModel(object viewModel)
{
this.DataContext = viewModel;
}
}
As for my own usage, the ViewModel doesn't know the View, or any interface on the View. And most of time, the View doesn't know its ViewModel, even if it is less important. The VM is just transprted by the DataContext.
This ensures that the VM and V will remain highly independant. Links are established thoughout bindings, commanding, Behaviors, Triggers & so on. Even if VM is often highly related to a given view, I try to make it as generic as possible, so that I can switch the corresponding View, and / or adapt the View behavior without needing to update the VM, except if the architectural link between V and M is impacted !
I'm just getting started with the MVVM pattern in WPF and I decided that the most elegant way to structure my code was injecting the view-model in to the view's constructor.
This is all well and good, but ReSharper gives a warning in the XAML that my view doesn't have a default constructor. I'm assuming that this is so that I can construct my view in XAML if required, but that's only a guess.
What am I giving up by requiring my view to take a view-model in the constructor?
Edit: My view constructor looks like this:
public ExampleView(ExampleViewModel viewModel)
{
if (viewModel == null) throw new ArgumentNullException("viewModel");
DataContext = viewModel;
}
Answer: I settled on the following set up, where the DesignTime namespace contains mocked up versions of the ViewModel for testing and design time support.
ExampleView.xaml.cs
public ExampleView()
{
InitializeComponent();
}
public ExampleView(IExampleViewModel viewModel)
: this()
{
DataContext = viewModel;
}
ExampleView.xaml
<UserControl
x:Class="Wpf.Examples.ExampleView"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:DesignTime="clr-namespace:Wpf.Examples.DesignTime">
<UserControl.DataContext>
<DesignTime:ExampleViewModel/>
</UserControl.DataContext>
</UserControl>
As you correctly recognized, requiring a non-default constructor will deny you using that control from XAML. That also means no more design-support and your designers will probably hate you. Finally you break all sorts of nice data binding scenarios. Like using the control as an ItemTemplate.
As a remedy for the missing design support, I would suggest implementing a default constructor which creates a mocked view-model which doesn't need any infrastructure. That way you can support design mode very elegantly and putting the view in a XAML file (e.g. for testing) will do something sensible.
As a remedy for the missing data binding support, you should ponder whether it might be better to consume the view model via the DataContext of your WPF control. This is common in WPF and---as far as I can tell---the intended way to pass the model to the view in WPF.
Assuming that you don't need designer support then I see no reasons.
To keep designer support you need a default constructor. When you define your own constructor you basically loose the autogenerated default constructor. Just create an explicit default constructor and you should be fine.
I am following the M-V-VM pattern for my WPF UI. I would like to hook up a command to the TextChanged event of a TextBox to a command that is in my ViewModel class. The only way I can conceive of completing this task is to inherit from the TextBox control, and implement ICommandSource. I can then instruct the command to be fired from the TextChanged event. This seems to be too much work for something which appears to be so simple.
Is there an easier way (than subclassing the TextBox and implementing ICommandSource) to hook up the TextChanged event to my ViewModel class?
First off, you've surely considered two-way data binding to your viewmodel, with an UpdateSourceTrigger of PropertyChanged? That way the property setter of the property you bind to will be called every time the text is changed?
If that's not enough, then I would tackle this problem using Attached Behaviours. On Julian Dominguez’s Blog you'll find an article about how to do something very similar in Silverlight, which should be easily adaptable to WPF.
Basically, in a static class (called, say TextBoxBehaviours) you define an Attached Property called (perhaps) TextChangedCommand of type ICommand. Hook up an OnPropertyChanged handler for that property, and within the handler, check that the property is being set on a TextBox; if it is, add a handler to the TextChanged event on the textbox that will call the command specified in the property.
Then, assuming your viewmodel has been assigned to the DataContext of your View, you would use it like:
<TextBox
x:Name="MyTextBox"
TextBoxBehaviours.TextChangedCommand="{Binding ViewModelTextChangedCommand}" />
Using the event binding and command method might not be the right thing to use.
What exactly will this command do?
You might want to consider using a Databinding to a string field in your VM. This way you can make a call to a command or function from there rather than having the UI care at all.
<TextBox Text="{Binding WorldName}"/>
....
public string WorldName
{
get
{
return WorldData.Name;
}
set
{
WorldData.Name = value;
OnPropertyChanged("WorldName");
// CallYourCustomFunctionHere();
}
}
Can you not just handle the TextChanged event and execute the command from there?
private void _textBox_TextChanged(object sender, EventArgs e)
{
MyCommand.Execute(null);
}
The alternative, as you say, is to create a TextBox that acts as a command source, but that does seem like overkill unless it's something you're planning on sharing and leveraging in many places.