Develop Reference

how do UserControls get access to a textbox's value in MainWindow?

The UserControls are put into MainWindow but they don't instantiate each other - they don't have owner-member relationship.
I need the back-end code of UserControls to be able to get the value from a TextBox of MainWindow. I have been told to use data binding but I don't really know what to be bound in UserControls.
Create an interface:
interface Interface_ProSimIP
{
string ProSimIP_Text { get; set; }
}
In MainWindow ViewModel:
string Interface_ProSimIP.ProSimIP_Text
{
get
{
return ProSimIP.Text;
}
set
{
}
}
In MainWindow View:
<TextBox x:Name="ProSimIP" Text="{Binding Path=ProSimIP_Text, Mode=OneWay}..."
I don't know am I right to do it this way and I don't know how to implement the interface in UserControls code behind.

You could use the same DataContext (view model) for the parent window and the user controls. Set the DataContext property of the window to an instance of a view model class where you implement your logic and then bind to properties of the view model from the XAML views of the window and the user controls. Then the window and the controls effectively share the same "back-end" code.
This pattern is known as MVVM and it's the recommended pattern to use when developing XAML based UI applications. You should learn it. The following MSDN page might be provide a good starting point for you: https://msdn.microsoft.com/en-us/library/hh848246.aspx.
Another (worse but maybe faster to adopt if you don't know anything about nor follow the MVVM pattern) approach would be to get a reference to the window from the UserControl using the Window.GetWindow method, and then access any control that's defined in the window directly:
var window = Window.GetWindow(this) as MainWindow:
if (window != null)
string text = window.ProSimIP.Text;
You should note that this kind of code doesn't follow follow best practices when it comes to developing loosely coupled, maintainable and testable applications though.

MVVM when to create a viewmodel for a control?

Or should I only create viewmodels for the domain data being represented? While reading on MVVM, I came across this:
"The ViewModel is responsible for these tasks. The term means "Model of a View", and can be thought of as abstraction of the view, but it also provides a specialization of the Model that the View can use for data-binding. In this latter role the ViewModel contains data-transformers that convert Model types into View types, and it contains Commands the View can use to interact with the Model. "
http://blogs.msdn.com/b/johngossman/archive/2005/10/08/478683.aspx
If the viewmodel is a model of the view, then doesn't it make sense to put properties of the view in the viewmodel rather than on the code behind of the view itself?
I guess in making a custom control I just have a hard time deciding when I should just add a property to the control's code behind and when it is worthwhile to make a viewmodel for the control to represent it. Honestly I kind of feel that moving all of the control's view related properties to the viewmodel would clean up the code behind of the control leaving only the control logic.
However, if I were to change things like this, then at times when an item needs properties from the control itself I can no longer use {Binding ElementName = control, Path=property} and have to instead get the data context of the parent (because the current datacontext would be on the individual subitem of the observable collection.
Basically I was considering whether I should move properties from Class GraphViewer into a GraphViewerViewModel and then just bind to it.
Code is worth a million words so:
public class GraphViewerViewModel :DependencyObject
{
private const int DEFAULT_PEN_WIDTH = 2;
private const int DEFAULT_GRAPH_HEIGHT = 25;
public SignalDataViewModel _SignalDataViewModel
{
get;
set;
}
public PreferencesViewModel _PreferencesViewModel
{
get;
set;
}
}
Meanwhile
public class SignalDataViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
ObservableCollection<SignalViewModel> _signals;
public ObservableCollection<SignalViewModel> Signals
{
get
{
return _signals;
}
private set
{
_signals = value;
}
}
ObservableCollection<SignalViewModel> _AddedSignals;
public ObservableCollection<SignalViewModel> AddedSignals
{
get
{
return _AddedSignals;
}
private set
{
_AddedSignals = value;
}
}
it is a pain to type:
PenWidth="{Binding RelativeSource = {RelativeSource AncestorType={x:Type DaedalusGraphViewer:GraphViewer}},
Path = _GraphViewerViewModel._SignalDataViewModel._AxisDivisionUnit.GraphPenWidth, Mode=OneWay}"
and I'm wondering if it is worthwhile to make the change or whether I'm misunderstanding what a view model should be used for in mvvm.

I guess in making a custom control I just have a hard time deciding when I should just add a property to the control's code behind and when it is worthwhile to make a viewmodel for the control to represent it. Honestly I kind of feel that moving all of the control's view related properties to the viewmodel would clean up the code behind of the control leaving only the control logic.
In general, a custom control is 100% View layer code. As such, it really falls outside of MVVM entirely.
The main goal when making a custom control to be used within an application being designed with MVVM is to make sure that you design and build the custom control in a way that it is fully compatible with data binding. This will allow it to be used within your View layer of your application exactly like other controls.
As such, this pretty much guarantees that you'll have code behind, since implementing Dependency Properties really requires code behind. You also don't want to set the DataContext of a custom control within the control (since you want to inherit the data context of the user control or window using the control).
Basically I was considering whether I should move properties from Class GraphViewer into a GraphViewerViewModel and then just bind to it.
If the types are specific to your domain, then this is really typically more of a UserControl being used by your application. In that case, creating a ViewModel and just binding is likely good.
If this is, on the other hand, a true custom control that's made to be completely general purpose (ie: usable by anybody in any application), then keeping it as a "pure view" custom control typically means that you 1) won't take a dependency on any ViewModels or domain specific objects, and 2) not set the data context (which means no view model).

Simple usercontrol and MVVM pattern: How to use?

Please help me
I have
public partial class OrderControl : UserControl
{
private OrderHeader orderHeader;
public Customer selectedCustomer { get; set; }
private Customer[] allCustomers;
public User selectedManager { get; set; }
private User[] allManagers;
public OrderControl()
{
InitializeComponent();
DataContext = this;
}
...
}
And I need one way binding to source:
<ComboBox Name="CustomerComboBox" SelectedItem="{Binding selectedCustomer}"/>
Is this best way to keep selectedCustomer Property in OrderControl.xaml.cs or I need to create some OrderViewModel class with ..,selectedCustomer,... Properties and keep an instance of OrderViewModel in OrderControl.xaml.cs?
thanks

That will work if you implement INotifyPropertyChanged. Right now there is no way for the combobox to get updates when the property is set. See http://msdn.microsoft.com/en-us/library/ms229614.aspx
However, if you wish to follow MVVM, then you will want to create a view model object.

It is best to create a ViewModel class, move your properties to that class and make it a DataContext of your UserControl.
Also, your selectedCustomer property is just a regular .NET property and it needs to support INotifyPropertyChanged interface in order to facilitate binding and change notification... typically a base ViewModel class from which all your other ViewModel classes inherit would implement this interface...

if you wanna create real usercontrols you should not:
DataContext = this;
here a quote from H.B.
It's bad practice, setting the DataContext like that is invisible
"from the outside" and impractical as inheritance of the DataContext
is usually what you want and expect
here is are similar question and answer.
but if you wanna do MVVM with viewmodel first.
quote from Rachel:
Remember, with MVVM your ViewModels are your
application. The View is just a pretty interface that allows users to
interact with your ViewModels.
that mean you should create appropriate viewmodels with all properties and commands you need. remove all code from your usercontrol because its now just a view. viewmodel first connects the viewmodel and the view through datatemplates.

Using viewmodel commands to open new tabs

I have an application where I have a main viewmodel whose view contains a tabcontrol, where each tab has its own view and viewmodel (and possibly more of them). I believe this is a pretty common design. Now, I want to open new tabs (by instantiating new viewmodels and adding them to the collection of workspaces) by firing commands from controls inside those tabs. The problem is that the command is received by the inner viewmodel, that controls the tab, not the outer one that controls the tabcontrol. What would be the best practice to do this? All the solutions I can think of are kind of "hacky" (giving the viewmodel a reference to its parent viewmodel, subscribing to a child's event from the parent...). I am assuming there is a nice solution for this.
For example, from a "list of entities" view, clicking the "new" button or selecting a row should open another tab with an "entity details" type of view. However, the command will be received by the "list of entities" view's viewmodel, to whom the tab is bound, and not the "list of workspaces" viewmodel to whom the tabcontrol is bound.

One possibility is to have your outer viewmodel expose a command to create a new tab. We use a centralized CommandService, which is simply a dictionary of name-to-ICommand, which allows for decoupled global commands. Something like this:
public interface ICommandService
{
void RegisterCommand(string name, ICommand command);
ICommand this[string name] {get;}
}
public class OuterViewModel
{
public OuterViewModel (ICommandService commandService)
{
commandService.RegisterCommand("OpenNewTab", OpenNewTab);
}
private void OpenNewTab (object newTabViewModel)
{
// The new tab's viewmodel is sent as the ICommand's CommandParameter
}
}
public class InnerViewModel
{
public InnerViewModel (ICommandService commandService)
{
_commandService = commandService; // Save injected service locally.
}
public HandleClickOnInnerTabpage()
{
AnotherViewModel newVM = new AnotherViewModel(...);
_commandService["OpenNewTab"].Execute(newVM);
}
}

You can use either standard .NET events (subscribing to the child events in the parent), or for more decoupling, use an event aggregator pattern.
Frameworks such as Prism and Caliburn.Micro implement the event aggregator pattern, and the MVVM Light Toolkit provides a Messenger class for the same purpose.

Having trouble deciding how to wire up a UserControl with MVVM

I've been doing the best I can to try to stay true to the separation recommended by the MVVM pattern. One thing I haven't figure out how to do correctly has to do with initializing my UserControls.
My most recent example of this has to do with a library that I wrote to talk to some low-level hardware. That assembly happens to have a UserControl that I can simply drop into any GUI that uses this hardware. All that is necessary for it to work is to set a reference to the object that has access to the low level methods.
However, that's where my problem lies -- currently, the UserControl is added to the GUI via XAML, where I define the namespace and then add the UserControl to my window. Of course, I have no control over its creation at this point, so the default constructor gets called. The only way to set the necessary reference for hardware control involves calling a method in the UC to do so. The ViewModel could feasibly call a method in the Model, e.g. GetController(), and then call the method in the UserControl to set the reference accordingly. The GUI can pass a reference to the UserControl to the ViewModel when said GUI creates the ViewModel, but this violates MVVM because the ViewModel shouldn't know anything about this control.
Another way I could deal with this is to not create the UserControl in XAML, but instead do it all from code-behind. After the ViewModel gets initialized and retrieves an initialized UserControl (i.e. one that has the low-level object reference set), it can set the Content of my Window to the UserControl. However, this also violates MVVM -- is there a way to databind the Content of a Window, TabControl, or any other element to a UserControl?
I'd like to hear if anyone has had to deal with this before, and if they approached it the first or second way I have outlined here, or if they took a completely different approach. If what I have asked here is unclear, please let me know and I'll do my best to update it with more information, diagrams, etc.
UPDATE
Thanks for the responses, guys, but I must not have explained the problem very well. I already use RelayCommands within the UserControl's ViewModel to handle all of the calls to the hardware layer (Model) when the user clicks in the control in the UserControl itself. My problem is related to initially passing a reference to the UserControl so it can talk to the hardware layer.
If I create the UserControl directly in XAML, then I can't pass it this reference via a constructor because I can only use the default constructor. The solution I have in place right now does not look MVVM-compliant -- I had to name the UserControl in XAML, and then in the code-behind (i.e. for the View), I have to call a method that I had added to be able to set this reference. For example, I have a GUI UserControl that contains the diagnostics UserControl for my hardware:
partial class GUI : UserControl
{
private MainViewModel ViewModel { get; set; }
public GUI( Model.MainModel model)
{
InitializeComponent();
ViewModel = new MainViewModel( model, this.Dispatcher);
ViewModel.Initialize();
this.DataContext = ViewModel;
diagnostics_toolbar.SetViewModel( ViewModel);
user_control_in_xaml.SetHardwareConnection( model.Connection);
}
}
where the outer class is the main GUI UserControl, and user_control_in_xaml is the UserControl I had to name in the GUI's XAML.
Looking at this again, I realize that it's probably okay to go with the naming approach because it's all used within the View itself. I'm not sure about passing the model information to user_control_in_xaml, because this means that a designer would have to know to call this method if he is to redo the GUI -- I thought the idea was to hide model details from the View layer, but I'm not sure how else to do this.
You will also notice that the main GUI is passed the Model in the constructor, which I assume is equally bad. Perhaps I need to revisit the design to see if it's possible to have the ViewModel create the Model, which is what I usually do, but in this case I can't remember why I had to create it outside of the GUI.

Am new to MVVM myself but here's a possible solution:
Create a property in your VM that is of the object type (that controls the hardware) and bind it to an attached property on your UserControl. Then you could set the property in your VM using dependency injection, so it would be set when the VM is created. The way I see it, the class that talks to the hardware (hardware controller) is a service. The service can be injected to your view model and bound to your UserControl. Am not sure if this is the best way to do it and if it is strict enough to all the MVVM principles but it seems like a possible solution.

if your question is: How do i show my viewmodel in the view? then my solution is always using viewmodelfirst approach and datatemplates.
so all you have to do is wire up your viewmodel via binding to a contentcontrol.content in xaml. wpf + datatemplates will do the work and instantiate your usercontrol for your viewmodel.

You are right, the ViewModel shouldn't know about anything in the View - or even that there is such a thing as a View, hence why MVVM rocks for unit testing too as the VM couldn't care less if it is exposing itself to a View or a test framework.
As far as I can see you might have to refactor things a little if you can. To stick to the MVVM pattern you could expose an ICommand, the ICommand calls an internal VM method that goes and gets the data (or whatever) from the Model, this method then updates an ObservableCollection property of the data objects for the View to bind to. So for example, in your VM you could have
private ICommand _getDataCommand;
public ICommand GetDataCommand
{
get
{
if (this._getDataCommand == null)
{
this._getDataCommand = new RelayCommand(param => this.GetMyData(), param => true);
}
return this._getDataCommand;
}
}
private void GetMyData{
//go and get data from Model and add to the MyControls collection
}
private ObservableCollection<MyUserControls> _uc;
public ObservableCollection<MyUserControls> MyControls
{
get
{
if (this._uc == null)
{
this._uc = new ObservableCollection<MyUserControls>();
}
return this._uc;
}
}
For the RelayCommand check out Josh Smiths MSDN article.
In the View you could either call the ICommand in the static constructor of your UC - I am guessing youwould need to add an event in your class for this - or call the ICommand from some sort of click event on your UC - maybe just have a 'load' button on the WPF window. And set the databinding of your UC to be the exposed observable collection of the VM.
If you can't change your UC at all then you could derive a new class from it and override certain behaviour.
Hope that helps a bit at least, like I say, have a look at Josh Smiths MVVM article as he covers the binding and ICommand stuff in there brilliantly.

If you set the DataContext of the Window or UserControl containing thisUserControl to the main view model, the user control can call SetHardwareConnection() on itself in its Loaded event (or DataContextChanged event handler).
If that's not possible because you're saying the UserControl is 'fixed', you should derive from it or wrap it up in another UserControl, which would serve as a MVVM 'adapter'.
(In order to bind the window: you could make the MainViewModel a singleton with a static Instance property and use DataContext="{x:Static MyClass.Instance}". A nice way to get things going quickly)
Note; this is based on my understanding that MVVM works because of Bindings.. I always bind the control to a ViewModel, not pass a ViewModel as a parameter.
Hope that helps!