Feel free to load your guns and take aim, but I want to understand why you shouldn't do this.
I have created a custom class designed to replace any instances of List (which I use to update XML objects behind them):
public class ListwAddRemove<T> : List<T> {
public event EventHandler<ListModifyEventArgs> OnAdd;
public event EventHandler<ListModifyEventArgs> OnRemove;
new public void Add(T o) {
base.Add(o);
if (OnAdd != null) {
OnAdd(this, new ListModifyEventArgs(o));
}
}
new public void Remove(T o) {
base.Remove(o);
if (OnRemove != null) {
OnRemove(this, new ListModifyEventArgs(o));
}
}
}
The idea is whenever I add or remove an item from this list my bound events will fire and I can deal with the XML behind automatically.
This works like a charm, so far so good.
But how do I handle a conversion between object.ToList() and my derived version?
A lot of people are saying you should derive from Collection instead... why?
You should derive from
Collection<T>because it's designed to allow you to overrideInsertItem, andRemoveItemto add custom behavior such as what you're doing (alsoSetItem, to add custom behavior when changing an existing item).It can therefore be used as an
IList<T>, and any insertion/removal will automatically use the customisation.In your case, anyone who casts to
IList<T>or the base classList<T>will bypass your custom Add/Remove functionality.Collection<T>also provides a constructor to wrap an existing list. You can expose this from your derived class to wrap a list generated byEnumerable<T>.ToList().UPDATE
Very simple:
Then use it as follows: