Develop Reference

When and where to use NotifyPropertyChanged

Could someone explain the use of notify property changed and in which cases should I be using it?
For example:
I have in my silverlight application the domain data source which loads data and the event LoadedData where I set to some lists (List) the content of the entities from the domain context and bind the lists to the girds.
Do I need to use NotyfiPropertyChanged on the Lists?
Thanks,

I think you are getting the concepts slightly confused here...
There are two relevant notification interfaces for use with XAML Binding technologies.
INotifyCollectionChanged - notifies listeners when the collection of items changes (as in add/remove/replace/reorder actions).
INotifyPropertyChanged - notifies listeners that the content of an object has changed (as in values have been set and itself and other properties have changed).
In your case, if you want to notify that the contents of the List have changed, you need to use an INotifyCollectionChanged enabled collection to do that (i.e. not List - typically ObservableCollection).
If you wanted to notify that an item within the List has changed then the object type contained in the List should implement INotifyPropertyChanged.

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.

Generic Collection - CollectionBase, IBindingList and Firing Events on Item Changes/Edits

I've implemented a GenericCollection using IBindingList, and it works great and fires events for when items are added or removed. It doesn't fire events when items are changed/edited as expected. Is there a simple way to implement logic to catch a change or edit without having to implement INotifyPropertyChanged within each class that uses this collection?
I might be looking for something not possible, but I'm basically looking to mimic functionality of a DataTable without having to code in the INotifyPropertyChanged for each class that uses the collection and I want to have my grid receive the edits/changes.
Thanks,
Mark

You should use the BindingList<T> class, which already does all that.

Use
System.Collections.ObjectModel.ObservableCollection
class.

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.