I was wondering if it is possible to make a reference to an instance made in code behind of a class, with XAML.
For example:
I have two clasess, MainWindow and MainWindow_ViewModel.
MainWindow is defined like so:
public partial class MainWindow : Window
{
static public MainWindow wn;
private MainWindow_ViewModel _mwvm;
public MainWindow_ViewModel mwvm
{
get
{
return _mwnm;
}
}
public MainWindow()
{
InitializeComponent();
wn = this;
_mwvm = new MainWindow_ViewModel();
}
}
1) How could I, in MainWindow.xaml, make a reference to the property MainWindow.wn.mwvm without creating a new instance of MainWindow_ViewModel (the purpose to this is to do some binding without using DataContext but I need to use the same instance of MainWindow_ViewModel throughout the whole application)
2) Is it possible to make a reference to that same property (MainWindow.wn.mwvm), from a XAML other than MainWindow.xaml ?
Thanks again for all the support.
First of you should set the DataContext of your window to your ViewModel. Only that way will it's properties be visible in the MainWindow's XAML.
Example:
<Window DataContext="{Binding mwvm}">
<TextBlock Text="{Binding PathToYourPropertyInVM} />
</Window>
Allways make sure your viewmodels either implement INotifyPropertyChanged or use DependencyProperties for Bindable properties. That is required in order for the UI to "listen" to the changes in the properties values.
If you want a Globally accessible ViewModel, you should look into the ServiceLocator pattern. All of the MVVM framework implement it for you (MVVMLight, Caliburn, etc). It basically consist of a class where your register your components and it handles all the instatiation when it's required. You should do a little research about that topic because it's rather extensive and hard to put on a single answer.
Hope this helps ;)
To instantiate your class in the app.xaml :
Add the namespace in the app.xaml
xmlns:myApp="clr-namespace:WpfApplication1"
Create the object of your class
<myApp:MainWindow_ViewModel x:Key="mwvm" />
An example of use :
<TextBlock Text="{Binding Source={StaticResource mvvm}, Path=A_PROPERTY}"/>
Related
For context, I am building a universal Windows Store app.
I'm just starting to learn C# and MVVM patterns and I need help correctly implementing binding.
I have followed this tutorial (Binding) and understand how it works, however in this example the code which does the binding is stored within the View Class.
public partial class MainPage : Page
{
public ObservableCollection<TermTest> MyTerms = new ObservableCollection<TermTest>();
public MainPage()
{
this.InitializeComponent();
MyTerms.Add(new TermTest("BNC", "Wire"));
MyTerms.Add(new TermTest("Lens", "Collects light"));
this.DataContext = new CollectionViewSource { Source = MyTerms };
}
As I understand it however this is poor design. In my implementation I will be using my Model to retrieve data which will get put into an Observable Collection. Then in my ViewModel I will want to bind the ObservableCollection to the XAML controls in which it is being used, not send the Collection to the View and then call a method in the View to populate the XAML controls.
Is that the correct way of doing this and, if so, how should it be done because I do not know how to expose the XAML controls to my ViewModel (and don't think I should be, right?).
I know I can expose the control creating a new instance of Mainpage but that is useless as I would need to bind to the current instance.
Mainpage Test = new MainPage();
Can someone please help me explain this - I have been through a lot reading and either not found the answer or not understood it!
Thanks, James
To begin, you definitely have the right idea.
What you want to do is create a ViewModel object (have it implement INotifyPropertyChanged) something like:
public class MainViewModel : INotifyPropertyChanged
{
//INPC implementation
public ObservableCollection<TermTest> MyTerms
{
//Standard INPC property stuff
}
}
Note that I used a property. You can only bind to properties, and you'll need the set method to raise the PropertyChanged event.
Then, you set the data context for the view. You can do this a number of ways, but the simplest is to do this:
public MainView() //Default Constructor
{
InitializeComponent();
DataContext = new MainViewModel();
}
Finally, bind!
<ListView ItemsSource="{Binding MyTerms}"/>
Also, if you don't want to touch the code behind of your window, you can do something like this:
<Window.Resources>
<YourNamespace:MainViewModel x:Key="MainViewModel"/>
</Window.Resources>
<Grid DataContext="{StaticResource MainViewModel}">
<ListView x:Name="TermsListView" ItemsSource="{Binding MyTerms}">
</ListView>
</Grid>
If you want understand in details this pattern I recommend you read this article:WPF MVVM step by step (Basics to Advance Level)
In an MVVM pattern, I have a single common ViewModel used by 3 usercontrols. I was instantiating the ViewModel and passing it as a parameter to the constructors of the user controls but this breaks XAML which requires that objects are constructed with parameterless constuctors.
What is the accepted best practise for creating a shared ViewModel?
You could create a ViewModel for your MainWindow which contains a property of Type SharedViewModel: public SharedViewModel SharedViewModel {get;set;}. You set the DataContext of your Window to your MainViewModel and bind to the shared ViewModel like:
<Window>
<Grid>
<UserControl1 DataContext="{Binding Path=SharedViewModel}"/>
<UserControl2 DataContext="{Binding Path=SharedViewModel}"/>
<UserControl3 DataContext="{Binding Path=SharedViewModel}"/>
</Grid>
</Window>
You can just add parameterless constructors for your UserControls
public MyUserControl() : base(new MyViewModel())
{}
public MyUserControl(MyViewModel viewModel)
{}
Note: This may break several design paradigms. :)
Dependency Injection with Unity ( http://msdn.microsoft.com/en-us/library/ff660899(v=pandp.20).aspx ) or MEF are the standard MVVM ways of coupling views to viewmodels
But don't forget that MVVM is a pattern, not a rigid framework. You can have a one-line hookup in the view's code behind:
InitializeComponent();
this.DataContext = new ViewModel(whatever);
without the sky falling.
You can have a base view that'll initialize the viewmodel
I have a WPF Window which contains few UserControls, those controls contain another. And now, what is the most principal way how to create ViewModel for this Window and where to bind it.
I do expect that one firstly needs to create ViewModel for each of sub-controls.
There are a few ways to do this.
Inject the VM
I would recommend this method.
If your window is created in the App class like
var window = new MyWindow();
window.Show();
I would assign the VM before showing the window:
var window = new MyWindow();
window.DataContext = GetDataContextForWindow();
window.Show();
If one of your controls needs an own view model assign the VM wile creating the control instance.
DataBind
If you want to set the VM of a control you can bind the DataContext property to an VM instance provided by the surrounding VM.
<Controls:MyControl DataContext={Binding MyControlsVm} />
Code Behind
You may set the VM using the init method in code behind like
public MyWindow()
{
InitializeComponent();
DataContext = CreateViewModel;
}
You may use a trick if you don't want to create a VM for your main page:
public MyWindow()
{
InitializeComponent();
DataContext = this;
}
and just use the code behind class as VM.
I see the view as a visual representation of the ViewModel so I like WPF picking the view based on the instance of the ViewModel it wants to render.
I call this the View Locator pattern, I use this method to instantiate my view because I have found it to be very simple to implement.
It basically puts an entry in the ResourceDictionary of your app that tells WPF to use an IValueConverter to look up and instantiate the View when it comes across a ViewModel.
So a working example would be:
In your app.xaml:
<Application x:Class="MyApp.App"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
StartupUri="MainWindow.xaml" >
<Application.Resources>
<ResourceDictionary Source="Resources.xaml"/>
</Application.Resources>
</Application>
In resources.xaml:
<DataTemplate DataType="{x:Type vm:ViewModelBase}">
<ContentControl Content="{Binding Converter={StaticResource ViewModelConverter}}"/>
</DataTemplate>
Set the DataContext of your startup Window Control e.g.
public MainWindow : Window
{
InitializeComponent();
DataContext = new MainViewModel();
}
And you're pretty much done. So if you have a MainViewModel like so:
public class MainViewModel : ViewModelBase
{
public ChildViewModel1 Child1 {get;set;}
public ChildViewModel2 Child2 {get;set;}
}
and you have a UserControl that resolves to your MainViewModel like so:
<UserControl x:Class="MainView">
<StackPanel>
<ContentPresenter Content="{Binding Child1}"/>
<ContentPresenter Content="{Binding Child2}"/>
</StackPanel>
</UserControl>
So your ViewModelConverter will return an instance of the appropriate View without any extra effort on your part.
On the child controls issue, why wouldn't one of the properties of the root view model be an instance of the child view model that you would pass onto the child control? The other option would be a converter that converts the non-view model based property into an instance of the child view model (like an adapter pattern).
You might be interested in the sample applications of the WPF Application Framework (WAF). They show how composite Views and ViewModels can be instantiated and how they interact which each other.
Consider that I have an application that just handles Messages and Users I want my Window to have a common Menu and an area where the current View is displayed.
I can only work with either Messages or Users so I cannot work simultaniously with both Views. Therefore I have the following Controls
MessageView.xaml
UserView.xaml
Just to make it a bit easier, both the Message Model and the User Model looks like this:
Name
Description
Now, I have the following three ViewModels:
MainWindowViewModel
UsersViewModel
MessagesViewModel
The UsersViewModel and the MessagesViewModel both just fetch an ObserverableCollection<T> of its regarding Model which is bound in the corresponding View like this:
<DataGrid ItemSource="{Binding ModelCollection}" />
The MainWindowViewModel hooks up two different Commands that have implemented ICommand that looks something like the following:
public class ShowMessagesCommand : ICommand
{
private ViewModelBase ViewModel { get; set; }
public ShowMessagesCommand (ViewModelBase viewModel)
{
ViewModel = viewModel;
}
public void Execute(object parameter)
{
var viewModel = new ProductsViewModel();
ViewModel.PartialViewModel = new MessageView { DataContext = viewModel };
}
public bool CanExecute(object parameter)
{
return true;
}
public event EventHandler CanExecuteChanged;
}
And there is another one a like it that will show Users. Now this introduced ViewModelBase which only holds the following:
public UIElement PartialViewModel
{
get { return (UIElement)GetValue(PartialViewModelProperty); }
set { SetValue(PartialViewModelProperty, value); }
}
public static readonly DependencyProperty PartialViewModelProperty =
DependencyProperty.Register("PartialViewModel", typeof(UIElement), typeof(ViewModelBase), new UIPropertyMetadata(null));
This dependency property is used in the MainWindow.xaml to display the User Control dynamicly like this:
<UserControl Content="{Binding PartialViewModel}" />
There are also two buttons on this Window that fires the Commands:
ShowMessagesCommand
ShowUsersCommand
And when these are fired, the UserControl changes because PartialViewModel is a dependency property.
I want to know if this is bad practice? Should I not inject the User Control like this? Is there another "better" alternative that corresponds better with the design pattern? Or is this a nice way of including partial views?
why not use a ContentPresenter/ContentControl with a datatemplate in your mainwindow?
instead of UserControl Content="{Binding PartialViewModel}" />, you can use a:
<ContentPresenter Content="{Binding Path=PartialViewModel}" />
all you have to do: is set your PartialViewmodel to your child viewmodel and create a datatemplate, so wpf will know how to render your childviewmodel
<DataTemplate DataType={x:Type UserViewModel}>
<UserView/>
</DataTemplate>
<DataTemplate DataType={x:Type MessageViewModel}>
<MessageView/>
</DataTemplate>
when ever you set your PartialViewmodel in your MainViewmodel, the right View will render in your ContenControl.
Edit 1
at least you have to implement INotifyPropertyChanged in your ViewModel and fire it when ever the PartViewModel property is set.
Edit 2
if you use Commands in your viewmodels take a look at some mvvm framework implementations like DelegateCommand or RelayCommand. handling ICommand become much easier with this. within your mainviewmodel you can create commands simple like that
private DelegateCommand _showMessageCommand;
public ICommand ShowMessageCommand
{
get
{
return this._showMessageCommand ?? (this._showMessageCommand = new DelegateCommand(this.ShowMessageExecute, this.CanShowMessageExecute));
}
}
This isn't a bad approach at first sight, it might be just fine to use in a small app.
However, there are a couple of things that aren't that nice:
ViewModelBase needs to be a DependencyObject to have a DependencyProperty. In the real world I 've found that it's very annoying to have to treat ViewModels in a single-threaded manner (there are lots of async operations one might want to perform).
It doesn't scale; changing the layout will require significant amounts of work.
Any decent MVVM framework makes UI composition easy by providing infrastructure to compose sub-Views into your main View. In Prism (which is my personal preference), this happens with Regions.
I would look at using an MVVM framework such as Caliburn.Micro which makes view composition incredibly easy. If you have a property on your view model which is a view model type, and a ContentControl on your view which is named the same as your property, then Caliburn.Micro will locate that view models corresponding view via conventions, do the binding for you automatically, and inject the view into the ContentControl.
I would also avoid using dependency properties on your view models, and instead implement INotifyPropertyChanged. Caliburn.Micro comes with a PropertyChangedBase type which implements this interface, and also provides a helper method for invoking the PropertyChanged event using lambda expressions rather than magic strings (which is much better for refactoring later).
EDIT
http://msdn.microsoft.com/en-us/library/ms743695.aspx shows an example of implementing INotifyPropertyChanged.
To achieve what you want to do in Caliburn.Micro, you would do something like the following (a crude example, but it shows you how easy it is doing view composition using an MVVM framework):
public class MainViewModel : Conductor<IScreen>.Collection.OneActive
{
private UsersViewModel usersViewModel;
private MessagesViewModel messagesViewModel;
public UsersViewModel UsersViewModel
{
get { return this.usersViewModel; }
set { this.usersViewModel = value; this.NotifyOfPropertyChanged(() => this.UsersViewModel);
}
public MessagesViewModel MessagesViewModel
{
get { return this.messagesViewModel; }
set { this.messagesViewModel = value; this.NotifyOfPropertyChanged(() => this.MessagesViewModel);
}
public MainViewModel()
{
this.UsersViewModel = new UsersViewModel();
this.MessagesViewModel = new MessagesViewModel();
this.Items.Add(this.UsersViewModel);
this.Items.Add(this.MessagesViewModel);
// set default view
this.ActivateItem(this.UsersViewModel);
}
public ShowUsers()
{
this.ActivateItem(this.UsersViewModel);
}
public ShowMessages()
{
this.ActivateItem(this.MessagesViewModel);
}
}
Note that UsersViewModel and MessagesViewModel would derive from Screen.
To invoke the ShowUsers or ShowMessages verbs with Caliburn.Micro, you just need to create view controls with the same name. The conductor type has an ActiveItem property which is the currently conducted item, so you can add a ContentControl to your MainView.xaml which is named ActiveItem, and Caliburn.Micro will take care of injecting the correct view.
So your MainView.xaml may look like:
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="200" />
<ColumnDefinition Width="*" />
</Grid.ColumnDefinition>
<!-- Menu in left hand column -->
<StackPanel Grid.Column="0">
<Button x:Name="ShowUsers">Show Users</Button>
<Button x:Name="ShowMessages">Show Messages</Button>
</StackPanel>
<!-- Currently active item -->
<ContentControl x:Name="ActiveItem" Grid.Column="1" />
</Grid>
you should take a look at prism. It gives you region handling.
I would also take a look at MEF to Export Views and on this way maintain an extensibility for your project.
My WPF project will be organised like this :
Screens
Group1
Screen1
View.xaml
ViewModel.cs
Group2
Screen2
View.xaml
ViewModel.cs
To show the Screen1 from the Screen2 I'll use something like this: ScreenManager.Show("Group1.Screen1") This looks (using reflection) in the Screens.Group1.Screen1 namespace for a View and a ViewModel and instantiates them.
How can I eliminate the magic string without coupling Screen1 and Screen2 (I don't want the classes in Screen2 to use the Screen1 namespace). Also I would like some kind of screen discovery (autocompletion/intellisense)
Or maybe some way (automate test) to verify that all calls to ScreenManager.Show are valid.
Update :
I came up with this:
public class ScreenNames
{
public Group1Screens Group1;
public class Group1Screens
{
public ScreenName Screen1;
}
}
public sealed class ScreenName
{
private ScreenName() { }
}
public class ScreenManager : IScreenManager
{
public void Show(Expression<Func<ScreenNames, ScreenName>> x) {}
}
Usage:
screenManager.Show(x=>x.Group1.Screen1);
Not ideal but I suppose violating DRY is still better than magic strings. And I can automatically test (with reflection) that all calls are valid.
You don't need all that ScreenManager stuff in WPF, because the DataTemplate engine can take care of this for you with pure markup.
You can simply databind a particular area of your application with a ContentPresenter and a bunch of DataTemplates. Bind the area to a property of a 'root' ViewModel, and let the 'root' ViewModel implement INotifyPropertyChanged so that WPF knows if you change the ViewModel in that area.
public class RootViewModel : INotifyPropertyChanged
{
public object Screen1ViewModel { get; }
public object Screen2ViewModel { get; }
}
Databind one ContentPresenter control to the Screen1ViewModel property using
<ContentControl Content="{Binding Path=Screen1ViewModel}" />
and similarly for the next one. When you need to change the content of Screen1, you simply re-assign Screen1ViewModel from code, and because of the raised PropertyChanged event, WPF will pick it up and bind the new ViewModel to a new View.
The DataTemplates may be as simple as this:
<Window.Resources>
<DataTemplate DataType="{x:Type foo:MyViewModel}">
<self:MyControl />
</DataTemplate>
<DataTemplate DataType="{x:Type foo:MyOtherViewModel}">
<self:MyOtherControl />
</DataTemplate>
</Window.Resources>
In case you are not familiar with it, this article on MVVM in WPF is an excellent introduction.
Finally I used T4 code generation to generate my ScreenNames class. I did that by adapting this code : Auto generate strong typed navigation class for all user controls in ASP.NET web application