When is CollectionView.Refresh() usually required? - c#

I am not familiar at all with using WPF and the application that I am working on had a ListCollectionView.Refresh() every time one of the objects in the ListCollection View Model would change which made the application extremely inefficient (ListCollectionView is binded to List Collection View Model). After removing the Refresh() the application runs a lot smoother and still updates when changes occur in ListCollection View Model. After looking around it seems that any time there is a filter or re-sort on the CollectionView there is an implicit call to Refresh(). So when is it necessary to Refresh() and recreate the CollectionView?

If I understand you correctly, you have a ListCollectionView that is bound to a ListCollectionViewModel (your own class). As long as ListCollectionViewModel implements INotifyCollectionChanged properly (eg. it inherits from ObservableCollection<T>), and the items in the collection implement INotifyPropertyChange properly, then it is not necessary to call Refresh().

CollectionView doesn't handle CollectionChanged events where more than one item is changing (an exception occurs); Refresh() can be used instead, which is why you are seeing calls with filters and sorts.

Related

Why is WPD Datagrid Usercontrol bound to row datacontext not updating?

I have a DataGrid bound via a ListCollectionView to an ObservableCollection of Objects with type Job, say. Each cell in the DataGrid contains a UserControl which has a dependency property named Job which is bound to the DataGridRow.DataContext (using Mode=TwoWay). Everything displays correctly.
The problem is that I have a background process which mutates objects referenced by the Job object and those get displayed by the UserControl. Obviously, Job does not change so the view does not change.
How can I get the user controls in each cell to update themselves with the new data?
With lists there are 3 kinds of ChangeNotification you have to take care of:
the one for each property of the Job Class.
the one if elements are added or removed from the collection. That is the only part ObservableCollection takes care off.
the one on the property exposing the list/CollectionView/whatever. ObservableCollection lacks a AddRange function so on large operations (like a rebuild of the list) it would spam the UI with changes. The solution is to build a new list in the background, then expose it in this property.
One particular issue might be the Background Process too, if it is Multithreading. GUI's are protected against being written from the wrong Thread. But threads are also notoriously good at swallowing Exceptions. Usually you need to write a faulty Catch, but they do it for free. As a result, your might run int oa CrossThread exception and never notice it.
For a better answer, we need some actuall code. Like teh job class, the BackgroundProcess, etc.

What is the point of INotifyCollectionChanged in terms of databinding (C# WinRt)

Background:
I was trying to roll my own observable collection, by implementing IEnumerable, INotifyPropertyChanged and INotifyCollectionChanged. It works fine, but when I databind the CollectionChanged event is always null. The databound property does however updated, since I am sending a Items[] property changed event.
So this got me wondering what the point of INotifyCollectionChanged is in terms of databinding, since in my class it never gets triggered, but the databinding still works (it updates all the bindings to the collection).
I then decided to do some more digging, and decompiled ObservableCollection. When I databind to an ObservableCollection the CollectionChanged event isn't null like in my implementation.
So really I am wondering why ObservableCollection gets 'special' treatment, and what role INotifyCollectionChange plays in databinding (if any)
INotifyCollectionChanged can be implemented by collections so that when elements are added or removed from the collection, interested parties can be notified of those events. This is useful, for example, when you want a ListView or GridView or some other display control that displays the contents of collections to update its display when the contents of the collection have changed (through adding or removing elements). More generally, any object could data bind to the event to be notified when items are added/removed from the collection to do whatever the data bound component needs to do—it doesn't just have to be a GUI control. Any other operations on the collection, however, will result in no notifications being made to data bound controls/objects. In order for that to occur, you would also need to implement INotifyPropertyChanged on the collection, creating the other PropertyChanged events you also want to publish to notify data bound objects, and raise the event when the operation in question occurs.
Additionally, if you want each item within the collection to update its presentation in the UI when something about the item itself has changed, then the type representing the item should implement INotifyPropertyChanged.
It seems to me that you need to implement your own CollectionChanged event. The built-in System.Array and/or System.Collections.ArrayList classes do not have any events associated with them. So if you're using one of these classes as your backing store, then on each addition/removal of an item, you would need to be sure to raise the CollectionChanged event for your custom collection implementation.
However, I need to ask, why roll your own observable collection when Microsoft already provides the ObservableCollection<T> object, which you could possibly subclass and receive the functionality you're looking for for free?

Performance, is it better to use Observable collection or INotifyPropertyChange?

I have to make some programs in c# and in order to perform IO between programs i have to use, or property using INotifyPropertyChange(on a List<>) or ObservableCollection<>.
I'd like to know which one is the better to perform IO operation between c# programs.
Thank you for reading
Based on the criteria you list in the question & comments, you're best off with an ObservableCollection.
The INotifyPropertyChanged interface exists to tell you just that - a property changed. When you're talking about a list, the properties will be things like Count and Item[]. This means that, effectively, all you're actually being told is "the contents of the list have changed" but not any details as to what that change actually was. Without any such information, all your control can really do is redraw itself completely based on the current state of the collection.
With ObservableCollection, however, you get told when an item is added (and what that item was and where it was added) and when an item is removed (and what that item was and where it used to be). This is enough information for your UI control to only have to redraw what has actually changed, which is far more efficient than redrawing the entire thing. This is why ObservableCollection was invented - use it!
Take a note that ObservableCollection inherits both INotifyCollectionChanged, and INotifyPropertyChanged.
[SerializableAttribute]
public class ObservableCollection<T> : Collection<T>,
INotifyCollectionChanged, INotifyPropertyChanged
See documentation from link above:
In many cases the data that you work with is a collection of objects. For example, a common scenario in data binding is to use an ItemsControl such as a ListBox, ListView, or TreeView to display a collection of records.
You can enumerate over any collection that implements the IEnumerable interface. However, to set up dynamic bindings so that insertions or deletions in the collection update the UI automatically, the collection must implement the INotifyCollectionChanged interface. This interface exposes the CollectionChanged event, an event that should be raised whenever the underlying collection changes.
WPF provides the ObservableCollection class, which is a built-in implementation of a data collection that implements the INotifyCollectionChanged interface.
Before implementing your own collection, consider using ObservableCollection or one of the existing collection classes, such as List, Collection, and BindingList, among many others. If you have an advanced scenario and want to implement your own collection, consider using IList, which provides a non-generic collection of objects that can be individually accessed by index. Implementing IList provides the best performance with the data binding engine.
INotifyPropertyChanged is used to notify the UI when the bounded property value or collection is changed. Whereas ObservableCollection is used to notify the UI when the bound collection is modified(Ex adding or removing object from the collection) It cant notify the UI if the property value in one of the collection object is changed.
These two alternatives do not do the same thing. You are choosing between these two options:
a list property implementing INotifyPropertyChanged, where you throw the event every time the list is modified
a property of type ObservableCollection
With option 1, when you modify the list, an event is raised that says "the entire list has changed." If you have a UI element bound to this list (say, a ListBox), the entire element will have to be redrawn, because it has to assume that the entire list has been changed (that is: it may no longer be the same list!).
With option 2, you are raising specific events about individual items that were added or removed in the list. If you have a UI element bound to this list, it can respond by only modifying the UI that is relevant for these elements.
Consider the example where you remove an item from your list, and the list is bound to a WPF ListBox control. With option 1, the entire content of the list is re-created. With option 2, the removed item's control is removed but the rest of the list is left intact.
It should be clear from this example that the ObservableCollection - because it supports an event that is specific to what you are doing - will be more efficient in many cases. That said, unless you have a huge amount of data in the collection or a very complex UI, the performance gain will be negligible. Further, if you're making large modifications to your list, you may well find that it's faster to refresh the whole list.
Ultimately, no performance question can be answered accurately on StackOverflow without repeating the mantra: profile your code, and make a decision based on the results.

How to refresh UI from ViewModel with ObservableCollection?

I have a listbox with items bound to an ObservableCollection.
Now, from within the viewModel, I need to cause an update to the UI.
I dont have a refernce to the listbox from my view model.
If I remove or add an item from my ObservableCollection, the ui gets updated.
Based on some other logic I need to update the UI...but the ObservableCollection is the same.
How can I update the UI WITHOUT either adding or removing items from my ObservableCollection?
Thanks
If you need to change your UI because you've edited the items in your collection, then you should arrange for those items to implement the INotifyPropertyChanged interface. If the objects within your collection have a PropertyChanged event, the UI will be listening for that event from individual items. (If possible, you could also change the items in your collection to be DependencyObjects with DependencyProperties, which accomplishes the same goal.)
If you really need to trigger a UI update when nothing at all about your collection has changed, the way to do it is to manually raise the CollectionChanged event. This can't be done with the ObservableCollection<> as is, but you could derive a new collection from that class, and call the protected OnCollectionChanged method from within some new, public method.
I've had a similar issue where I wanted to change the background on an item, but obviously neither the item nor the collection changed.
It was achieved by calling:
CollectionViewSource.GetDefaultView(your_collection_name).Refresh();
This refreshed the view from the view model without altering the collections
This is a good case for an extension method. It hides away the implementation in case it changes in future versions, can be modified in one place, and the calling code looks simpler and less confusing.
public static void Refresh<T>(this ObservableCollection<T> value)
{
CollectionViewSource.GetDefaultView(value).Refresh();
}
Usage:
myCollection.Refresh();

Create a custom collection like BindingList that works with ListBox to create a ListChanging event

I have a situation where I need to know when an item is going to be added/removed/modified in the collection.
I tried by inheriting BindingList in a class that will trigger these events, however the "adding" event doesn't work. The only way I found it working is by overriding EndNew() method, however I don't find a way to get which object is going to be added in this method (if someone has a solution for this, it's ok too!).
So built a totally new class which inherits from same interfaces/class of BindingList and implemented everything (I didn't inherit, however, ICancelAddNew).
I bound it through databindings to my listbox and I find out that nothing works (listchanged events neither listchanging events). How can I simulate BindingList behavior on a listbox?
Any suggestion heavily appreciated, I don't have any other ideas for a workaround
EDIT 1:
This is my collection: http://pastie.org/1978601
And this is how I bind the collection to the ListBox
SpellCasterManager.CurrentProfile.ButtonsMacro.ListChanged += new ListChangedEventHandler(ButtonsMacro_ListChanged);
SpellCasterManager.CurrentProfile.ButtonsMacro.ListChanging += new Expand.ComponentModel.ListChangingEventHandler(ButtonsMacro_ListChanging);
gumpButton.DataBindings.Add("Value", SpellCasterManager.CurrentProfile.ButtonsMacro, "GumpIndex", false, DataSourceUpdateMode.OnPropertyChanged);
Actually under subscribed events there is just a MessageBox.Show("bla");
Your collection won't detect property changes in an existing item because it doesn't hook into the item's property changed events as it is added to the collection.
BindingList<T> does listen to PropertyChanged on your item and does fire a ListChanged event when an item is added to the BindingList and it does include the index at which is is added. Try it in a test app without WinForms.
Adding an existing item is not the same as AddNew(). The AddingNew event is only called when AddNew() is called and allows you to supply the new instance.
When WinForms is involved, things get more complicated. There is the CurrencyManager to think about and also BindingSource. If no events are firing at all then check to see if you are using the CurrencyManager/BindingSource you think you are.
I don't think anything in the framework uses INotifyPropertyChanging, only the original INotifyPropertyChanged. You might want to use Reflector on BindingList to see how the hooking is done and then try to incorporate INotifyPropertyChanging if your item supports it.
Did you follow MSDN guidelines? Your collection class should extend CollectionBase and implement IBindingList - and that should be fine.
Also, you might want your collection item to implement IEditableObject in order to support *Edit operations. This however is not required - more importantly, your collection item should have a way to notify parent collection when it changes (either by following code provided on MSDN, or using for example INotifyPropertyChanged).
You can find working binding sample implementing custom CustomersList on IBindingList doc page (Customer class can be found on IEditableObject doc page).
After getting clear idea of what you are looking for i will suggest following things
Here is a great undo framework which provides lot of functionality.
http://undo.codeplex.com/
Here is sample,
http://blogs.msdn.com/b/kirillosenkov/archive/2009/07/02/samples-for-the-undo-framework.aspx
And in your case, instead of trying to hook on adding/editing events, it's better to track after added/modified/deleted event if you store their initial state. So if the item was removed, in your previous state you will have the item already if you started tracking from the start state of your program.

Categories

Resources