I am using MVC 2.
I have 5 view models and each has different message properties that i need to populate from the DB. The property names are different, per the message type.
In the view models, i have type available, for which i need to pull the messages.
If the type is Welcome, then i want to pull the 3 welcome messages.
I want to write a generic function that i will call from each action. This generic function will then look at the object being passed and its type property and then will fill the message properties specified in this view model. How can i accomplish this? From my actions, i don't want to call a separate function for each messages type.
I am trying to do some thing like following:
public void GetMessage(object viewModel, bool isCheckMessages)
{
viewModel = (AnnualReportWelComeViewModel)viewModel;
}
But the viewModel in this instance is not picking properties specified in AnnualReportWelComeViewModel.
Am i thinking straight here or just making it way over complicated than it needs to be?
The problem with your code is that you are reusing same variable when converting types. Your viewModel is of type object and even if you try to convert it to another type you will still see it as object. You should try something along these lines:
public void GetMessage(object viewModel, bool isCheckMessages)
{
var reportMessage = viewModel as AnnualReportWelComeViewModel;
if (reportMessage != null)
{
// viewModel passed was of type AnnualReportWelComeViewModel
}
}
If you want this function to check for many possible types of viewModel then you could do something like:
public void GetMessage(object viewModel, bool isCheckMessages)
{
if (viewModel is AnnualReportWelComeViewModel)
{
var reportMessage = viewModel as AnnualReportWelComeViewModel;
// ...
}
else if (viewModel is MonthlyReportWelComeViewModel)
{
var reportMessage = viewModel as MonthlyReportWelComeViewModel;
// ...
}
}
You should create interface IViewModelWithMessage and inherit all your viewmodel from it.
public interface IViewModelWithMessage
{
string Message { get; set; }
}
In your viewmodels you should map inherited property Message to this model messages:
public class AnnualReportWelComeViewModel : IViewModelWithMessage
{
public string ViewModelMessage { get; set; }
....
string IViewModelWithMessage.Message {
get { return ViewModelMessage; }
set { ViewModelMessage = value; }
}
}
Do what you want with Message property of interface and this value will be passed to other properties.
public void GetMessage(IViewModelWithMessage viewModel, bool isCheckMessages)
{
...
viewmodel.Message = ...
}
Related
I have problem to understand how to implement this with Caliburn Micro, event aggregator, i have a view model that call 2 different window, and before show, I subscribe to an handle of type string, it works, but now I want to know in the handle method, from which subscribe came the message:
public void Causale()
{
var asm = Assembly.LoadFrom(#"V.M.Tabelle.Magazzino.Causale.dll");
var module = _shell.LoadModule(asm);
if (module != null)
{
_eventAggregator.Subscribe(this);
module.Show("Add");
//_shell.CurrentView = (new ShellMenuItem { Caption = "Tiard", ScreenViewModel = module });
}
}
public void CausaleList()
{
var asm = Assembly.LoadFrom(#"V.M.Tabelle.Magazzino.Causale.dll");
var module = _shell.LoadModule(asm);
if (module != null)
{
_eventAggregator.Subscribe(this);
module.Show("List");
//_shell.CurrentView = (new ShellMenuItem { Caption = "Tiard", ScreenViewModel = module });
}
}
public void Handle(string message)
{
_eventAggregator.Unsubscribe(this);
BackValue = message;
NotifyOfPropertyChange(() => BackValue);
}
I've serached for a property, like subscribe(this).name("")
to pass something like a token.
Thank you
Instead of subscribing to a type of string, you could create a custom class which includes the message and the sender information, and then subscribe to it. For example,
public class ActionMessage
{
public object Sender{get;set;}
public string Message{get;set;}
}
You could now publish the Message as,
_eventAggregator.PublishOnUIThread(new ActionInvokedMessage { Message = "Add", Sender = this });
This Sender property would include the source of message. You could verify the type of source when handling the event.
public void Handle(ActionInvokedMessage message)
{
if(message.Sender is UserControl1ViewModel)
{
}
if(message.Sender is UserControl2ViewModel)
{
}
}
Eventaggregator passes the message as a parameter to the subscriber.
Hence your method:
public void Handle(string message)
Will receive either "Add" or "List" as the message parameter.
That parameter can be any type you like. That type can be a complex type rather than a value type. In fact it is usually a good idea to define a class ( type ) for each sort of message you want to send since it is the type which differentiates which handlers are fired when any message is raised.
In any case, if string is not enough information somehow you could instead define a class with numerous properties and pass as many parameters you like in that way. EG you could have class Foo with Mode and Source properties. Mode being Add/List and Source being wherever the message originates from.
So I have seen some responses to similar questions as this, but I was wondering if a certain paradigm that I am thinking of is even possible in C#. First, I'll lay out the issue:
I have a MVVM application that I am developing in C#. The model has properties that change, and when a single property changes in the model, it often times affects multiple properties in the view-model. So the view-model listens for changes on the model. And the view listens for changes on the view-model.
In my view-model, I end up getting some code that looks like this:
private void OnModelPropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
string prop_name = e.PropertyName;
if (prop_name.Equals("some_property_on_the_model"))
{
NotifyPropertyChanged("some_property_on_the_view_model");
NotifyPropertyChanged("some_property_on_the_view_model");
NotifyPropertyChanged("some_property_on_the_view_model");
NotifyPropertyChanged("some_property_on_the_view_model");
NotifyPropertyChanged("some_property_on_the_view_model");
}
else if (...)
{
... etc ...
}
}
This gets annoying because it just seems messy. And if I forget to edit this function after adding a new property to the view-model then it can easily lead to bugs.
So here is what I would like to do, but I don't know if this is possible. So I would like one of you to help me understand if it is possible or not.
It would be really cool if I could use C#'s "attributes" feature to take care of the property changed propagation.
So maybe something like this:
[ListenToModelProperty("some_property_on_the_model")]
[OnPropertyChanged("MyButtonVisibility")]
public Visibility MyButtonVisibility
{
get
{
if (model.some_property_on_the_model == true)
{
return Visibility.Visible;
}
else
{
return Visibility.Hidden;
}
}
}
private void OnModelPropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
prop_name = e.PropertyName;
foreach (var property in view_model)
{
var attributes = property.GetCustomAttributes(typeof(ListenToModelPropertyAttribute));
var descriptions = attributes.Select(x => x.Description);
if (descriptions.Contains(prop_name))
{
notification_to_make = property.GetCustomAttributes(typeof(OnPropertyChangedAttribute));
string notification_string = notification_to_make[0].Description;
NotifyPropertyChanged(notification_string);
}
}
}
Please note that the above code is not meant to be real code. It will definitely not compile and will not work. But I would like to see if something like the above is possible in C#. Is it possible to do something like this using attributes? Or is there a library out there that makes something like this possible?
I have figured out how to do it! It is fairly simple. I will post the relevant code here, and those who are interested can find all the code at this github repository that I just made: https://github.com/davepruitt/model-subscribe
First, I created a custom attribute class. It is a simple class that takes an array of strings as a parameter to its constructor. This allows you to listen to multiple properties on the model for changes. It looks like this:
using System;
using System.Collections.Generic;
namespace TestPropagationOfPropertyChanges
{
[AttributeUsage(AttributeTargets.All)]
public class ListenForModelPropertyChangedAttribute : System.Attribute
{
public List<string> ModelPropertyNames = new List<string>();
public ListenForModelPropertyChangedAttribute (string [] propertyNames)
{
ModelPropertyNames.AddRange (propertyNames);
}
}
}
I then created my model. For simplicity's sake, it only contains two properties. They are strings that store a "first name" and a "last name":
using System;
using System.ComponentModel;
namespace TestPropagationOfPropertyChanges
{
public class Model : NotifyPropertyChangedObject
{
#region Constructors
public Model ()
{
}
#endregion
#region Private data members
private string _first = string.Empty;
private string _last = string.Empty;
#endregion
#region Public properties
public string FirstName
{
get
{
return _first;
}
set
{
_first = value;
NotifyPropertyChanged ("FirstName");
}
}
public string LastName
{
get
{
return _last;
}
set
{
_last = value;
NotifyPropertyChanged ("LastName");
}
}
#endregion
}
}
The view-model, in this case, has a "full name" property. So it wants to listen to any changes that happen to the first or last name on the model, and then react to changes on either of those. I realize this isn't the best "real world" scenario in which this kind of system would be used, but it does help illustrate the concept. The first part of my view-model is below:
using System;
namespace TestPropagationOfPropertyChanges
{
public class ViewModel : NotifyPropertyChangedObject
{
#region Private data members
//This is public for testing purposes
public Model _model = new Model();
#endregion
#region Constructors
public ViewModel ()
{
_model.PropertyChanged += ReactToModelPropertyChanged;
}
#endregion
#region Properties
[ListenForModelPropertyChangedAttribute(new string [] {"FirstName", "LastName"})]
public string FullName
{
get
{
return _model.FirstName + _model.LastName;
}
}
Finally, the view-model finishes with the method that reacts to changes on the model. Normally, in a large and complex application, this method could contain a large if-else statement with lots of calls to NotifyPropertyChanged. Instead, we now just iterate through the properties of the view-model and see which ones subscribe to the model's property that was changed. See below:
void ReactToModelPropertyChanged (object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
//Get the name of the property that was changed on the model
string model_property_changed = e.PropertyName;
//Get a System.Type object representing the current view-model object
System.Type t = typeof(ViewModel);
//Retrieve all property info for the view-model
var property_info = t.GetProperties();
//Iterate through each property
foreach (var property in property_info)
{
//Get the custom attributes defined for this property
var attributes = property.GetCustomAttributes (false);
foreach (var attribute in attributes)
{
//If the property is listening for changes on the model
var a = attribute as ListenForModelPropertyChangedAttribute;
if (a != null)
{
//If the property that was changed on the model matches the name
//that this view-model property is listening for...
if (a.ModelPropertyNames.Contains(model_property_changed))
{
//Notify the UI that the view-model property has been changed
NotifyPropertyChanged (property.Name);
}
}
}
}
}
Overall, it works excellently, and is exactly what I needed. This code can easily be expanded upon to be even more functional for those interested.
I have three ViewModels: MainViewModel, PreferencesViewModel and ColourControllerViewModel - the latter 2 are properties of the MainViewModel.
ColourControllerViewModel is used for the 'ColourSelector' view, where various colours can be created and deleted. It contains an ObservableCollection of ColourViewModel, which has a property detailing the colour, and a bool property determining if it should be shown on the preferences tab (DisplayOnPreferences).
PreferencesViewModel is used for the 'Preferences' view, which contains a combo box of colours - this is represent by an ObservableCollection of ColourViewModel, and only those ColourViewModels where DisplayOnPreferences == true should be displayed.
My question is, what's the easiest way to do this? Currently, I am using an Action delegate called UpdateList() which passes the updated list from ColourControllerViewModel to MainViewModel, which in turn updates the PreferencesViewModel. I don't really like this though, it feels like there's a better way.
Should there be a single ObservableCollection of ColourViewModel on MainViewModel that is updated/accessed by either instance?
Here are the classes:
public class MainViewModel : ViewModel
{
private ColourMappingControllerViewModel _colourMappingControllerViewModel;
private PreferencesControllerViewModel _preferencesTabViewModel;
public MainViewModel()
{
// Initialise the database Handler
dbHandler = DatabaseHandler.DbHandlerInstance;
_colourMappingControllerViewModel = new ColourMappingControllerViewModel(dbHandler.GetColourMappingsList(), UpdateColourList);
_preferencesTabViewModel = new PreferencesControllerViewModel(dbHandler.GetPreferences, ColourMappingList)
}
public ObservableCollection<ColourMappingViewModel> ColourMappingList
{
get { return ColourMappingControllerViewModel.ColourMappingList; }
}
public void UpdateColourList(ObservableCollection<ColourMappingViewModel> colourList)
{
PreferencesTabViewModel.UpdateColourList(colourList);
}
}
public class ColourMappingControllerViewModel : ViewModel
{
public ColourMappingControllerViewModel(IEnumerable<ColourMapping> colourMappingsList, Action<ObservableCollection<ColourMappingViewModel>> updateColourListAction)
{
InitialiseCommands();
ColourMappingList = new ObservableCollection<IColourMappingViewModel>(InitialiseColourMappingsList(colourMappingsList));
}
public ICommand AddColourMappingCommand { get; set; }
private void InitialiseCommands()
{
AddColourMappingCommand = new DelegatingCommand(AddColourMapping);
}
private void AddColourMapping() // Attached to Command on View
{
var newColourMapping = new ColourMappingViewModel(
new ColourMapping());
ColourMappingList.Add(newColourMapping);
ColourMappingsCollectionView.MoveCurrentToLast();
UpdateColourMappingList();
}
private void UpdateColourMappingList()
{
UpdateColourListAction.Invoke(ColourMappingList);
}
}
public PreferencesControllerViewModel : ViewModel
{
public PreferencesControllerViewModel(object preferenceInfo, ObservableCollection<ColourMappingViewModel> colourMappingsList)
{
var pciTrendBlocks = pciBlocks;
ColourMappingsList = colourMappingsList;
}
public void UpdateColourList(ObservableCollection<ColourMappingViewModel> colourList)
{
ColourMappingsList = colourList;
}
}
I know the ObservableCollection class is being misused - it's probably not necessary on the Preferences as it will only be updated in ColourMappingController.
I would agree that you need a single ObservableCollection that is shared between views. This effectively becomes your "Model" in MVVM.
You may also want to enforce different access semantics by having a ReadOnlyObservableCollection that can be passed to your preferences VM etc. This ensures that only ColourControllerViewModel (Which gets the underlying ObservableCollection) can actually alter the collection.
In my apps I tend to have a separate data layer, but yes, for now it would be simplest to just add them to MainViewModel.
The alternative would be to have ColourControllerViewModel be the thing that owns the collection (and exposes it as a ReadOnlyObservableCollection), and have you MainViewModel just pass the collection into any other VM's that need it.
A property in ViewModel, that is bound to an element in View, usually takes value from
some model class instance and when the value is updated in the View, the property propagates the change of the value into the underlying model class instance.
However in case when you have a property in ViewModel returning e.g. an ObservableCollection that is constructed from values
from the model, the change of the values in the View only changes the values in the ObservableCollection. It does not propagate the change of values into the underlying model class instance.
So for example, you have a modal dialog (= the View), you display this dialog together with its datacontext (=ViewModel) and the ViewModel contains an instance of a model class.
Now
situation A) you have a ViewModel that has only properties that return non-collection types (int, string ...), when you close the dialog
you know that the model class instance has the updated values.
situation B) you have a ViewModel that has a property exposing an ObservableCollection<>, when you close the dialog, the model class
instance does not contain the updated values.
What is the common pattern/practice of dealing with this?
I thought you could have a method that writes the data that are present in ViewModel into the Model instance and call this method when the dialog closes. But this seems unnatural to me with the philosophy of MVVM and WPF so far.
Please keep in mind that the before mentioned example is just an example. This applies to any View-ViewModel-Model interaction in general.
In case someone didn't understand what I was trying to describe:
Let's have a model class
public enum A
{
A1,
A2,
A3
}
public class MyModel
{
private float[][] array;
public MyModel()
{
array = new float[Enum.GetNames(typeof(A)).Length][];
foreach (A a in EnumUtil.GetValues<A>())
{
array[(int) a] = new float[3]; // any number, really, but it will be referenced later in text
}
}
public A EnumerationA { get; set; }
public float this[A a, int b]
{
get
{
return array[(int) a][b];
}
set
{
array[(int)a][b] = value;
}
}
public float[] ArraySlice
{
get
{
return array[(int) EnumerationA];
}
}
}
and a ViewModel class
public class MyViewModel : ViewModelBase
{
private MyModel _myModel;
private ObservableCollection<float>[] _tmp = new ObservableCollection<float>[Enum.GetNames(typeof(A)).Length];
public MyViewModel()
{
// in constructor we will add 3 values to each collection
}
public A EnumerationA
{
get
{
return _myModel.EnumerationA;
}
set
{
if (Enum.Equals(_myModel.EnumerationA, value) == false)
{
_myModel.EnumerationA = value;
RaisePropertyChanged("EnumerationA");
RaisePropertyChanged("ArraySlice");
}
}
}
public ObservableCollection<float> ArraySlice
{
get
{
return _tmp[(int) EnumerationA];
}
}
}
The ArraySlice can be bound to anything DataGrid etc....
So in this example, when user is done, the values stored in the array of ObservableCollections are not saved in the model instance.
However if instead of the property returning ObservableCollection, we had three properties, each returning float, the values would easily be propagated into the underlying model class instance right in the property setter.
Preferably I would welcome an idea / solution that wouldn't require me to do anything once the interaction between View / ViewModel / Model ends.
I have a big problem with MVVM design. I am trying to catch every PropertyChanged of my inner nested objects, including futhermore propertchanged of their nested objects, inside my ViewModel but I dont know how to do it.
Here is my structure:
class MyVM
{
public MyVM()
{
this.SomeData = new SomeData();
this.SomeData.NestedObj = new MyNestedDat();
this.SomeData.Str = "This tiggers propertychanged inside MyDat class";
// this triggers propertychanged event inside MyNestedDat class
this.SomeData.NestedObj.Num = 123;
}
// and here should be a method where i catch all possibe propertychanges from my nested objets and their nested objets, how do i do that?
public MyDat SomeData
{
get;
set;
}
}
class MyDat : INotifyPropertyChanged
{
private string str;
public string Str;
{
get { return this.str;}
set
{
this.str = value;
this.PropertyChanged(this, "Str");
}
}
publicMyNestedDat NestedObj
{
get;
set;
}
}
class MyNestedDat : INotifyPropertyChanged
{
private int num;
public int Num
{
get{ return this.num;}
set
{
this.num = value;
this.PropertyChanged(this, "Num");
}
}
}
How do i get this to work? I am really clueless where to start.
MyNestedDat class throws PropertyChanged, MyDat class throws propertychanged and i want to catch them all inside my viewmodel. How can i do that?
In my opinion there are a few conceptual things wrong with what you are asking. Just imagine you get a solution that works for your scenario (that you are happy with) and consider the following:
What happens if another layer is added? do you still expect it to work the same?
Should property changes be propagated (viewModel1.propA notifies viewModel2.PropA)?
Should property changes be transformed (viewModel1.SomeProp notifies ViewModel2.AnotherProp)?
Is performance a concern? how will this perform if you need to propagate the property changed events through many levels?
This should be raising alarm bells that the current approach is not the right path to tread.
What you need is a way to provide communication between your viewModels in a loosely coupled way so that you viewModels do not even need to know about each others existence. The beauty of this is that this will also work in other situations not just for property changes.
For your case of property changed events, one viewModel wants to know when something happens (it could be something other than a property changed event, remember). This means the other viewModel needs some way of saying "Hey, a property has changed" (or "My state has changed", "That database call has finished" etc).
Now in C# you can provide events which provide this feature....except, now your objects know about each other which leaves you with the same problem you had before.
To overcome this problem you need another object, a mediator (lets call it Messenger in this example), whose sole purpose is to handle the message passing between the objects so that they can live in ignorance of each other.
The general idea is this. In the viewModel that provides notifications you might do something like this:
public string MyProp
{
get { return _myProp; }
set
{
_mProp = value;
OnPropertyChanged("MyProp");
Messenger.PostMessage(new VMChangedMessage { ViewModel = this, PropertyName = "MyProp" });
}
}
And in the viewModel that is interested in the event you might do something like this:
public class ViewModel2
{
public ViewModel2()
{
Messenger.Subscribe<VMChangedMessage>(handleMessage);
}
private void handleMessage(VMChangedMessage msg)
{
// Do something with the information here...
}
}
Notice that the two viewModels never reference each other. They are now loosely-coupled.
There are a number of pre-existing implementations already available and it isn't difficult to create your own (the messenger basically keeps a list of objects that are interested in a certain message and iterates the list when it needs to notify the interested parties). There are a few things that can be implemented differently (some implementations just pass string messages around rather than encapsulating the information in objects, and some handle the clean-up of observers automatically).
I would recommend using Josh Smiths (excellent) MVVM Foundation which includes a messenger class. It's also open source so you can see how it works.
There is no clear constraint about what PropertyName should contains in PropertyChangedEventArgs.
See Subscribe to INotifyPropertyChanged for nested (child) objects.
Here is an example :
class A : BaseObjectImplementingINotifyPropertyChanged {
private string m_name;
public string Name {
get { return m_name; }
set {
if(m_name != value) {
m_name = value;
RaisePropertyChanged("Name");
}
}
}
}
class B : BaseObjectImplementingINotifyPropertyChanged {
private A m_a;
public A A {
get { return m_a; }
set {
if(m_a != value) {
if(m_a != null) m_a.PropertyChanged -= OnAPropertyChanged;
m_a = value;
if(m_a != null) m_a.PropertyChanged += OnAPropertyChanged;
RaisePropertyChanged("A");
}
}
}
private void OnAPropertyChanged(object sender, PropertyChangedEventArgs e) {
RaisePropertyChanged("A." + e.PropertyName);
}
}
B b = new B();
b.PropertyChanged += (s, e) => { Console.WriteLine(e.PropertyName); };
b.A.Name = "Blah"; // Will print "A.Name"
The best thing to do here is to separate the idea of a Model and a ViewModel.
By having a ViewModel object that is flatter than the Model you can avoid this scenario. Using an automatic mapping tool like Automapper then allows you to map the Model to the ViewModel and vice versa.
https://github.com/AutoMapper/AutoMapper/wiki/Flattening
class MyDatViewModel : INotifyPropertyChanged
{
public string Str
{
// ... Get Set
}
public int NestedObjNum
{
// ... Get set
}
}
// Configure AutoMapper
Mapper.CreateMap<MyDat, MyDatViewModel>();
// Perform mapping
MyDatViewModel viewModel = Mapper.Map<MyDat, MyDatViewModel>(someData);