Being notified of property changes is all from INotifyPropertyChanged and has nothing to do with ObservableCollection<T>. If you just need to know when a property changes then you should implement INotifyPropertyChanged on your class. ObservableCollection<T>, all it does is notify when an object has been added or an object has been removed from the collection. It doesn't implement bulk operations out of the box, i.e. you can't AddRange or RemoveRange like an IList<T>. I'm sure you have valid reasons for using ObservableCollection<T>. I'm just saying that your suggestion has led Atook to post sample code using ObservableCollection<T> when List<T> would have worked better.
I'm sorry I've mislead someone, because in the first post I've directly referenced OC as a bad choice to start with, and also said the same for building custom collections because of potential problems of overcomplicating. I've emphasized the importance of making things simple so you can easily debug for wich I think is more important then performance. I know my English is bad, but I thought this quote below was clear enough:
If you do, here are some mistakes I have made:
-I've used obsevable collection (useful for CAD) since I could override a lot, but eventully, there was no room to override more
-then I've decided to create from zero, and created something that could be described as observablesorteddictionaryofcadobjects with a whole bunch of methods for search, replace... but eventually it became hard to debug and to add new feature (since it was large, I've found that I'm loosing time just following different program paths travel)
And then you realise that this is just one minor part of your solution and you are loosing a lot of time for features people don't even care. They will first tell you about textbox being too small, or your flow is not covering turbulent case, and not that the objects in your list are updating 1.5 times slower than you hoped for. So - do not waste too mouch time on CAD part, and make it simple to be faster to debug later and than a year later, when you return to your code - to be able to remember what is what.
Nevertheless, overriden OC is still a great to work with in situations where you have to: read a few properies of a bulk of entities (using single transaction and then iterate objects is faster than opening new transactions), store this as a properties of your T in this OC(of <T>), perform PLINQ after CAD is done, show results (if used in WPF), and respond to propertychange and collection change events. In this case, it's just a matter of overriding Add, Remove (RemoveAt), Clear and add your AddRange, RemoveRange and ContainedElementChanged. However, dealing with events (and you have them in overriden add, remove, clear) I find very dirty with plenty of room to forget something, and a lot of time to waste for debuging. Not just in this OC but all across .NET. Avoid events as much you can.
So, this few lines above are in conflict with this post, but consistent with the idea that in .NET you can do things in many ways.
Again, this all depends on what you need
So Atook, make it simple, make it work, and make it you know where is what.
As famous mr. Kalshinkov said half a century ago: everything that is simple is good, and everything that is good is simple.
