We Keep Coding

How can I prevent the initial assignment of property values from triggering an event in a WPF application?

I have a WPF project which has a main window containing a tab control which, in turn, contains several user controls.
I need the main window to display a warning when the value of certain properties have changed on the various user controls. I am using an event handler to populate a TextBlock when these properties change.
The remaining problem I have is that when the application is started, and the different UI properties get assigned an initial value, this assignment seems to be triggering the event. I only want to display this warning when the user has changed something.
Here's what I have:
An abstract class which facilitates the event
public class ViewModelBase {
Boolean isBusy;
protected virtual void OnConfigurationChanged(EventArgs args) {
EventHandler handler = ConfigurationChanged;
handler?.Invoke(this, args);
}
public event EventHandler ConfigurationChanged;
}
User controls which trigger the event when applicable properties change
class MyViewModel : ViewModelBase {
String myTextField;
public MyTextField {
get => myTextField;
set {
myTextField = value;
OnConfigurationChanged(null);
}
}
}
In my main window, I instantiate the user control and subscribe to the event. I also have the unsaved changes property in here
class MainWindowVM : ViewModelBase {
String unSavedChanges;
public MainWindowVM() {
MyViewModel MyVM = new MyViewModel();
MyVM.ConfigurationChanged += onConfigurationChanged;
}
String UnsavedChanges {
get => unSavedChanges;
set {
unSavedChanges = value;
OnPropertyChanged(nameof(UnsavedChanges));
}
}
void onConfigurationChanged(Object sender, EventArgs args) {
UnsavedChanges = "Configuration not saved.";
}
}
A XAML TextBlock bound to UnsavedChanges
<TextBlock Text="{Binding UnsavedChanges}"
Foreground="Red"
Margin="10"/>

I guess this is obvious to most folks, but for anyone else that struggles with this issue:
In order for an initial value to be reflected in a property-bound UI component, the value must be assigned to the underlying field in the object constructor. Changes to the field outside of the constructor will not be seen by the corresponding property and, in turn, will have no effect on the property-bound UI component.
Assigning a value to a property which invokes OnPropertyChanged() on set will always trigger the subscribed event. The constructor is not exempt in this regard.

WPF switching views

I am implementing a WPF application and I am switching view models on button click. I had to implement an navigation store by youtube tutorial. When I click a button, navigateCommand will execute, creating a new viewModel and notifying view to change. However I dont understand what is method OnCurrentViewModelChanged() doing and why is it needed, action CurrentViewModelChanged is returning void, and is empty? Or am I missing something? What is CurrentViewModelChanged doing? Can someone please explain?
public class NavigationStore
{
public event Action CurrentViewModelChanged;
private NotifyPropertyChanged currentViewModel;
public NotifyPropertyChanged CurrentViewModel
{
get => currentViewModel;
set
{
currentViewModel = value;
OnCurrentViewModelChanged();
}
}
private void OnCurrentViewModelChanged()
{
CurrentViewModelChanged?.Invoke();
}
}
public class NavigateCommand<TViewModel> : CommandBase where TViewModel : NotifyPropertyChanged
{
private readonly NavigationStore _navigationStore;
private readonly Func<TViewModel> _createViewModel;
public NavigateCommand(NavigationStore navigationStore, Func<TViewModel> createViewModel)
{
_navigationStore = navigationStore;
_createViewModel = createViewModel;
}
public override void Execute()
{
_navigationStore.CurrentViewModel = _createViewModel();
}
}
public class MainViewModel : NotifyPropertyChanged
{
private readonly NavigationStore _navigationStore;
public NotifyPropertyChanged CurrentViewModel => _navigationStore.CurrentViewModel;
public MainViewModel(NavigationStore navigationStore)
{
_navigationStore = navigationStore;
_navigationStore.CurrentViewModelChanged += OnCurrentViewModelChanged;
}
private void OnCurrentViewModelChanged()
{
OnPropertyChanged(nameof(CurrentViewModel));
}
}

So first of all, I also followed his tutorials (it's most likely SingletonSean's) and I don't share #BenicCode's opinion on that (tho I'm not a professional at WPF like he may be), I really like his explanations and solutions to problems. Besides, he keeps changing the project throughout the guide, implementing better solutions and explaining why it's better to use this than that.
The OnCurrentViewModelChanged() method raises an event so that any method that is subscribed to it will be invoked. However, you actually don't need it, you can implement NavigationStore like this:
NavigationStore.cs
public class NavigationStore : INavigationStore
{
private ViewModelBase? _currentViewModel;
public ViewModelBase? CurrentViewModel
{
get => _currentViewModel;
set
{
_currentViewModel?.Dispose();
_currentViewModel = value;
NavigationStateChanged?.Invoke();
}
}
public event Action? NavigationStateChanged;
}
And now, in your MainViewModel, you can simply subscribe the NavigationStateChanged action to OnCurrentViewModelChanged() instead of having one more method in your navigation store.
MainViewModel.cs
public class MainViewModel : ViewModelBase
{
private readonly INavigationStore _navigationStore;
public ViewModelBase? CurrentViewModel => _navigationStore.CurrentViewModel;
public MainViewModel(INavigationStore navigationStore)
{
_navigationStore = navigationStore;
_navigationStore.NavigationStateChanged += OnNavigator_NavigationStateChanged;
}
private void OnNavigator_NavigationStateChanged()
{
OnPropertyChanged(nameof(CurrentViewModel));
}
}
It's basically the same, but a bit simpler (correct me if I'm wrong). By subscribing NavigationStateChanged to OnNavigator_NavigationStateChanged, whenever NavigationStateChanged is raised, OnNavigator_NavigationStateChanged will fire too, which will notify your UI to change (since you bind the ContentControl's Content property to the CurrentViewModel property).
MainWindow.xaml
<Grid>
<ContentControl Content="{Binding CurrentViewModel}" />
</Grid>
At this point of the tutorial he just wanted to demonstrate really basic navigation. As you progress further, things get cleaner and more complicated. I really suggest finishing his tutorials, there might be better guides, but as a starting point, I couldn't find any better channel.

Action on ComboBox selection changed

I'm using MVVM to bind a ComboBox to a ViewModel, and I have few question about heavy actions and selection change.
I want to trigger some actions when the selected item is changed, my initial approach was to put the logic in the setter of the field to which the selected item is binded.
So my first question is, is this good practice or there is a better approach?
Those actions may be very expensive in time and resources (need to retrieve data through a web service) and I don't want the UI to freeze, so lately I've started to send a message from the set which is received in the view's code-behind and that call a ViewModel command asynchronously.
Am I just wasting time or does this make any sense?
The problem is that when I'm debugging the UI sometimes freeze anyway (it doesn't happened on release). Reading here and there I've come to know that it may be debugger related, can anyone confirm this behavior on VS 2015?
Additional information
As requested I provide some examples. This is my first approach:
(XAML)
<ComboBox SelectedItem="{Binding SelectedField}"/>
(ViewModel)
public class ViewModel
{
private MyObject _selectedField = null;
public MyObject SelectedField
{
get
{
return _selectedField;
}
set
{
if(_selectedField != value)
{
// Expensive action
_selectedField = value;
RaisePropertyChanged(() => SelectedField);
}
}
}
}
The expensive action make some web service calls and may take long, is this design good or is there a better way to achieve this?
My second approach is through messages, as shown in this example:
(ViewModel)
public class ViewModel
{
private MyObject _selectedField = null;
public MyObject SelectedField
{
get
{
return _selectedField;
}
set
{
if(_selectedField != value)
{
Messenger.Default.Send(new DoStuffMessage());
_selectedField = value;
RaisePropertyChanged(() => SelectedField);
}
}
}
private RelayCommand _doStuffCommand = null;
public ICommand DoStuffCommand
{
get
{
if (_doStuffCommand == null)
_doStuffCommand = new RelayCommand(async () => await DoStuff());
return _doStuffCommand;
}
}
private async Task DoStuff()
{
// Expensive action
}
}
(Code-behind)
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
Messenger.Default.Register<DoStuffMessage>(this, DoStuffMessage_Handler);
}
private void DoStuffMessage_Handler(DoStuffMessage msg)
{
(DataContext as ViewModel).DoStuffCommand.Execute(null);
}
}
Is this approach better or is just bad and useless?

For MVVM, I prefer to use RelayCommands to bind an EventTrigger in XAML to an ICommand in the viewmodel. I feel this creates the best separation of code and is clearer than adding a lot of logic to my setters, where it might be overlooked during troubleshooting. Here is an overview of the process: https://msdn.microsoft.com/en-us/magazine/dn237302.aspx
This is to wire up a button and pass in a parameter, so obviously you would need to modify it for your use case, but it will show the basic technique. In XAML:
<Button Content="Click Me">
<i:Interaction.Triggers>
<i:EventTrigger EventName="Click">
<Custom:EventToCommand Command="{Binding MyCommand}" CommandParameter="foo"/>
</i:EventTrigger>
</i:Interaction.Triggers>
</Button>
In your VM:
public static ICommand MyCommand { get; set; } // declare an ICommand - bind to this!
public MainViewModel(IDataService dataService)
{
// associate your ICommand with a method. If you don't use a parameter, you don't need the lambda expression here.
MyCommand = new RelayCommand<string>((paramater) => MyCommandMethod(parameter));
}
public void MyCommandMethod(string parameter)
{
Debug.WriteLine("This is the code I want to run in my VM. The parameter is " + parameter);
}
I use the [free] MVVMLight toolkit for my applications, which was written by the guy who wrote the article that I linked to, but a lot of this is baked into .Net also. Using Expression Blend can make it easier to wire this stuff up when you are designing.

You can do whatever you like in setter as long as it is async.
private string _test;
public string Test
{
get { return _test; }
set
{
Task.Run(() =>
{
//do stuff
});
_test = value;
}
}
If you don't want to place logic in setter, because for example the Single Responsibility principle is violated, you should use interactions to catch the SelectionChange event and call a command in VM which should call an async method.
Here you have a sample that uses interactions : cute link
That's it!

UWP MVVM on click bind to function

This is probably the easiest thing in the world to do but I'm struggling a bit.
I have this in XAML:
<Button Name="browseButton" Content="Browse" Grid.Column="1" />
I've got everything binding correctly from the view to the viewmodel, like radio buttons and input text boxes etc... but what I want is to bind this button to a function, such that when the user clicks it some operation occurs.
But I'm really having a hard time figuring out how to bind clicking this button to a function in the viewmodel. I've played a bit with ICommand and didn't get very far, and I don't want to do the hack-ish thing of just sticking it in the code behind.
I'm using MVVMLight (Galasoft) if that helps.
Any guidance appreciated.
Edit
Following the example from https://msdn.microsoft.com/en-us/magazine/dn237302.aspx I have, but where does canExecuteMyCommand come into it? And how do I bind it in the XAML?
public RelayCommand BrowseCommand
{
get;
private set;
}
public LoadFilesViewModel()
{
BrowseCommand = new RelayCommand(executeBrowse, () => _canExecuteMyCommand);
}
private void executeBrowse()
{
// Do something
}
Solution
<Button Name="browseButton" Content="Browse" Grid.Column="1" Command="{Binding BrowseCommand}" />
And
public RelayCommand BrowseCommand
{
get;
private set;
}
public LoadFilesViewModel()
{
BrowseCommand = new RelayCommand(executeBrowse, () => true);
}
private void executeBrowse()
{
// Do something
}

If you look at the code you provided, the RelayCommand constructor comes with 2 parameters.
public RelayCommand BrowseCommand
{
get;
private set;
}
public LoadFilesViewModel()
{
BrowseCommand = new RelayCommand(executeBrowse, () => _canExecuteMyCommand);
}
private void executeBrowse()
{
// Do something
}
Checking the source code (that's the learning a code base and open-source makes this possible) or Visual Studio IntelliSense, you'll see this signature:
public RelayCommand(Action execute, Func<bool> canExecute)
So the first parameter is an action to be executed, and the second parameter is a check if it can execute. You've correctly identified the executeBrowse as a method to "do something". The _canExecuteMyCommand parameter is a class variable of the type bool that can be either true or false (set somewhere else).
In your own solution (posted in question), you replaced this by true (hardcoded). Note that you can also drop the second parameter in this case:
public LoadFilesViewModel()
{
BrowseCommand = new RelayCommand(executeBrowse); // will always execute
}
Bonus
Note that instead of using a local variable, you can also use a method to defined whether the method can execute (or write the check logic inline with the delegate syntax).
public LoadFilesViewModel()
{
BrowseCommand = new RelayCommand(ExecuteBrowse, CanExecuteBrowse);
}
private void ExecuteBrowse()
{
// Do something
}
private bool CanExecuteBrowse()
{
// Check if we are allowed to browser
return true; // or false :)
}

Designs of a WPF MVVM Application

I have been doing tons of research using MVVM (Model View ViewModel) with WPF. I am developing a desktop application. This application consists of a main window. This main window has some buttons which do something. Also, there is a button that opens a OpenFileDialog box.
Currently, this is my ViewModel to which the main window binds to:
MainWindowPresenter Class
namespace BMSVM_Simulator.ViewModel
{
class MainWindowPresenter : ObservableObject
{
private bool logLoaded; // true if a log is currently loaded, false otherwise
public MainWindowPresenter()
{
logLoaded = true;
}
public ICommand load_data_button_pressed
{
get { return new DelegateCommand(doLoadData); }
}
private void doLoadData()
{
// DO LOAD DATA COMMANDS
}
public ICommand exit_button_pressed
{
get { return new DelegateCommand(doExit); }
}
private void doExit()
{
// DO EXIT COMMANDS
}
}
}
QUESTION 1: I am concerned that this is the "wrong" implementation. Is it correct (per MVVM) for each button to have a property of type ICommand and then a corresponding method implementing the functionality? A main window with a lot of buttons would have a very large ViewModel class, no?
QUESTION 2: If one of the buttons was a File->Open File button. So, in that case it would open up a new OpenFileDialog window. Would this be done in the same way I previously done it above (i.e. have a public ICommand open_file_dialog_button_pressed property and a corresponding public void doOpenFileDialog() method? This seems like I am mixing the "view" of the open file dialog into the ViewModel, although the view is already defined by the built in wpf OpenFileDialog class.
QUESTION 3: Is it true that each "view" of our application should have only a single "presenter" class (which is part of the ViewModel) to which that view binds to? In the example above, my main window view binds to only the MainWindowPresenter class. If I were to make another view (say a graph generated with Microsoft's Dynamic Data Display library in it's own popout window), I would need an additional "presenter" class in my ViewModel, correct?
Thank you very much!
Rich
For reference, I've included these classes, but they may not be useful:
DelegateCommand Class
namespace BMSVM_Simulator.ViewModel
{
public class DelegateCommand : ICommand
{
private readonly Action _action;
public DelegateCommand(Action action)
{
_action = action;
}
public void Execute(object parameter)
{
_action();
}
public bool CanExecute(object parameter)
{
return true;
}
#pragma warning disable 67
public event EventHandler CanExecuteChanged;
#pragma warning restore 67
}
}
ObservableObject Class
namespace BMSVM_Simulator.ViewModel
{
class ObservableObject : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
//basic ViewModelBase
internal void RaisePropertyChanged(string prop)
{
if (PropertyChanged != null) { PropertyChanged(this, new PropertyChangedEventArgs(prop)); }
}
}
}

1) Yes that's correct. You need to create a command property for each command. But thanks to your relay command you don't need to implement it directly. To prevent your ViewModel from busting i would recommend to move all commands into a separate CommandsViewModel serving as command source. Your View then binds to it.
2) Opening the Dialog can be achieved in XAML via routed commands using the CommandBinding property. So the tasks remains in the view. You basically try to avoid the dependency on any view related object. .NET provides some ready to use commands for common purposes (MSDN - ApplicationCommands)
3) You can share ViewModels among Views of course. That's one reason you structure your implementation into Model View ViewModel to be independent from changes and for reusability. It can become critical when more than one view is updating the same source simultaneously.