Is there anyway to force XAML to completely redraw all of its elements and thereby have all of the data being displayed updated? This is within a MVVM architecture.
In a MVVM architecture, the View-Model implements INotifyPropertyChanged interface and its properties fire the PropertyChanged event. When this event is fired, the View (which is bound to the View-Model using XAML Binding System) receives a notification about the changes in the value of the properties in the View-Model and it refreshes, showing the updated data on screen.
Therefore, if you are using the MVVM architecture, the only thing you need to do in order to reflect changes in the view is updating the properties in your View-Model.
If you have any specific situation in which the binding system is not giving you the desired results, can you please explain in more detail so that it is possible to address your problem better?
Related
So I am new to MVVM with WPF and am having trouble with a few concepts.
So as soon as you run, my MainViewModel will set up the model and will start pulling from the database in order to populate a list which is binded to one of my controls.
Now the problem is that, after it pulls data from the db it then needs to listen to another source which will fire an event and then add to this list. Now, this data source will fire events infinitely, so I would like to display the UI with the DB-pulled data and then update this list as events fire.
My initial idea was to only start this listen for updates once I have loaded and presented my control, but how is this done using the OnLoaded event in MVVM, I think this has been my biggest struggle.
Thanks
Decided to go with Clemens' comment.
I now, bind the datasource in code and run the viewModel's listen method when the window is loaded, using the Loaded event. I am still not sure if this is a good MVVM solution so will probably change it again soon if it isn't.
I'm currently in the need of setting the SelectedIndex property of my TabControl when a certain event (IEventAggregator) takes place and thought about how I'd implement that.
I came up with 2 possibilities:
Use GetView() provided by ViewAware in order to access my TabControl and set the SelectedIndex to my value
Use a property in my associated ViewModel and bind this property to my TabControl's SelectedIndex property via XAML
Both options are working fine but I personally want to get this question answered since this is not the first time I'm wondering where to implement the functionality in such cases.
I know that the first option won't enable the Notify support but besides that: What would be the proper way?
Having a GetView() method to manipulate the view directly from the viewmodel completely breaks MVVM. You might as well just put all your logic in codebehind. The whole point of MVVM is to abstract away the actual view so that it is decoupled from the logic, and the app can be unit tested.
What if you change your mind about the tabs in the future and decide to show your multiple views some other way? You've now got to start editing your viewmodel to edit the new view instead of just tweaking some XAML.
And for unit testing you're going to have no way to mock out your TabControl.
I'm creating a simple database application in C# WPF using MVVM as Relay Commands and databinding. For in-memory storage of database content I use ObservableCollection, which is binded to the Datagrid as follows:
<DataGrid ItemsSource="{Binding Path=Softwares, Mode=OneWay}" SelectedItem="{Binding Path=SoftwareSelection, Mode=TwoWay}">
when the item is selected user can chose to edit it. For editation a form is opened with a bunch of textboxes with the data of given entity. All the fields are validated using IDataErrorInfo, unless all textboxes are valid, the ok button is not enabled, and therefore no changes can be saved to the collection and to the database.
Here is how the example textbox looks like:
<TextBox Text="{Binding Name, Mode=TwoWay, ValidatesOnDataErrors=True, UpdateSourceTrigger=PropertyChanged, ValidatesOnExceptions=True}"/>
But the tricky part is, in case I change some values in textboxes and then close the window, the new values are propagated to the ObservableCollection, which I don't want to. Do you have any idea, how to prevent such behaviour? I would like the databinding work only after clicking the button. Otherwise the databindng works well, so as the button (dis/en)abling and reflecting changes to the database and to the collection after clicking. Both views are serviced by different ViewModels, data between views are passed by firing events.
I tried to add to the DataGrid UpdateSourceTrigger=Explicit to the ItemsSource binding, but didn't help. Perhaps, I'm missing some application logic?
Thank you very much for your help.
This is where most WPF developers make mistakes of assumptions!
In MVVM dirty data can be stored in the ViewModel and that's what the layer of VM is for! It mimics the View from Model's perspective and because View is in error, the ViewModel would also be in the error. Thats perfectly valid.
So having said that, the question remains
How will you NOT allow the temporary / dirty data to flow to your
ObservableCollection?
Two ways...
If your ObservableCollection is specific to your model class (say MyItem) then if your Model class (MyItem) is an Entity class \ DAL class \ NHibernate class create a wrapper of MyItem class called ViewModelMyItem and then instead of ObservableCollection<MyItem> use ObservableCollection<ViewModelMyItem>.
This way dirty data from your View would be inside ViewModelMyItem and it can only be legitimately flown back to your model class (MyItem) ONLY when Save button is clicked. So that means in Save Command's Execute() delegate you can copy \ clone the ViewModelMyItem's properties into Item's properties, if validations in ViewModelMyItem are fine.
So if Item is an EntityType class / NHibernate class / WCF client model class, it would always only valid data as ViewModelMyItem is filtering the temporary / dirty information upfront.
You could use Explicit binding model. It stops the TwoWay data to flow back to the sorce Item unless BindingExpressions.UpdateSource() is explicitly called.
But according to me, this defeats MVVM in straightforward way because ViewModel will not have what UI is showing! Still however you can use *Attached Behavior * to govern explicit binding by staying in MVVM space!
Let me know if this helps!
You're better off putting the code into the domain object's property setter. Then synchronize with the visuals by triggering the NotifyPropertyChanged handler.
More on this topic:
http://msdn.microsoft.com/en-us/library/ms743695.aspx
http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx
Setting the Binding Mode to Explicit should require you to call the binding expressions UpdateSource() method to send changes back to your model. Because you only mentioned that you set Explicit on the DataGrid's binding, I'm guessing you only need to make sure that you have that mode explicitly set on any property that is being bound directly back to your model. Such as your TextBox's Text Binding, in the case above. That will likely fix your problem but require you to call UpdateSource() on each target's BindingExpression one way or another.
If you're using one of the mainstream ORM's (EF, Linq to SQL, etc), then chances are your Entities automatically implement INotifyPropertyChanged and INotifyPropertyChanging. Because you are sharing a reference to your single instance, all changes in your edit will be reflected in your main view and anything else Binding to that instance. As a dirtier alternative, you can just create a separate instance of the same type and manually copy the values back over when the window's dialog result is true.
The first approach requires you to manually update the bindings, the second approach requires you to manually update the values from the Edit's instance.
With some more code, I can help with your specific approach.
I'm new with MVVM and I'm stuck...
I have a ListBox in the MainWindow. The ListBox contains Items of type WhatEverViewModel which are displayed by DataTemplates. The user can interact with these items and the WhatEverViewModel has several DependencyProperties which may change during interaction.
The question I have is:
How can I elegantly react (in the MainWindowViewModel) to changes of DependencyProperties of the CURRENTLY SELECTED WhatEverViewModel. I personally would implement some events in the WhatEverViewModel and when the SelectedItem of the ListBox change, I would attach to the events of the currently selected WhatEverViewModel. But I think in MVVM there might be a more elegant way to solve this...
Thank you.
Make CurrentWhatEver a property of your MainWindowViewModel and bind the Listbox.SelectedItem property on it. This way, MainWindowViewModel knows when the selected WhatEver changes and can register/unregister to events it's interested in.
communication between viewmodel can be done in several ways.
Messenger/Mediator like the one form MVVM Light
Eventstuff like the one from PRISM
or simply use harcoupling and subscribe to the events from the WhatEverViewModel in your mainviewmodel.
btw why in hell to you use DependencyProperties in your Viewmodels? simple Properties with INotifyPropertyChanged are the way to go.
one more thing. why you want to react to changes in the SelectedViewmodel(or better what you want to achieve, with the selected viewmodel.)? if you just want to display some information in your view, simply bind the SelectedViewmodel to it. you should specify your question in that way.
EDIT
The WhatEverViewModel has a list which is also bound to a listbox (in
datatemplate) and depending on what I select in the WhatEverViewModel
I want to display some kind of "Configurator" in the MainViewModel. –
JensPfister1 1 hour ago
why not simply bind the SelectedWhatEverViewmodel.SelectedListEntryProperty to your configurator view? can you post some code?
You should implement the INotifyPropertyChanged interface on each of your ViewModels. Then when one of your properties changes call the PropertyChanged event, your views will get notifications that the property has changed (as long as your Binding is correct). If a property is a list or collection make sure that the list is based off an INotifyCollectionChanged.
Add a property for the Selected WhatEverViewModel to your MainWindowViewModel, bind that in your ListBox. Then in your MainWindowViewModel you can hook on to the property changes of your Selected WhatEverViewModel.
For more guidance read:
WPF MVVM INotifyPropertyChanged Implementation - Model or ViewModel
http://blogs.msdn.com/b/soultech/archive/2011/06/07/mvvm-tips-when-implementing-inotifypropertychanged.aspx
I have a view containing a ListView and an "Edit" Button. The ListView's ItemSource is bound to an ObservableCollection<Account> property on the underlying view model. Its SelectedItem property is also bound to the view model.
When the edit button is clicked, the existing view model launches an editing view/view model pair ("editing screen") allowing the user to edit the currently selected Account. The Account to edit is determined by the main view model's SelectedItem property.
Problem: Any changes made in the editing screen are immediately reflected in the other screen's ListView, even before the edit screen's "Save" button is clicked. Why this happens makes sense--Account is raising property change events when its properties are changed and the ListView is processing those notifications.
Desired Outcome: Bound controls (like the ListView) should only see editing screen changes after"Save" is clicked.
Possible Solutions
Suspend Account's property change notifications while editing is underway. Disadvantages: If a manual data-binding update is performed while an Account instance is being edited, the "in-progress" changes will appear on the ListView even though those changes haven't been raising notifications. Also, if the user launches a second edit window for the same Account, they will see the "in-progress" changes. Idea rejected.
Have the editing screen view model wrap the Account instance in some kind of EditingAccount class that copies changes made to it back to the original Account only when Save() is called. Should the editing screen take on the responsibility of facilitating this wrapping or should it ask the service layer to do it?
What do you think of these options? How do you solve this problem when you encounter it?
I would go with some version of the second option. Basically this is a variation of the MVVM pattern which is considered the "right" way to do WPF/Silverlight code. Basically you should have a ModelView object for each "screen" (View) that wraps the model and exposes the model in a format specific to the View so it does exactly what the View needs and NO MORE.