> The notification isn't that hard. Actually it's a 1 minute job. >It's the state of the average control you can buy (including >the datagridview and datagrid controls shipped by MS, these also have problems) which is much harder to deal with.
I was thinking more in terms of when your business object implements INotifyPropertyChanged. OK, it's not that hard but BindingList automagically subscribe to them to make the control redraw when they change, which is nice. > Microsoft's documentation has a tendency of explaining even the > most stupidist silly things an average joe will run into, >but when framework developers (you know, the people who write a framework >with .net) need documentation, it's hardly there (or >stating the obvious. "Gee, the property Handler returns a handler") Hehe, yeah. I'm particularly intrigued by the documentation of IBindingList.AddNew in MSDN (last sentence). [Note] "If the objects in this list implement the IEditableObject interface, calling the CancelEdit method should discard an object, not add it to the list, when the object was created using the AddNew method. The object should only be added to the list when the IEditableObject.EndEdit method is called. Therefore, you must sychronize the object and the list carefully." One minute job... maybe after you spent a week decoding this note. > ...In which case you have to implement IListSource which returns > the actual > binding object to the grid and on which you implement ITypedList and > IBindingList on. Yeah, IListSource might be the way to go in my situation. I don't want users of my collections to use AddNew to save a line of code and then come complaining about performance when they don't even use data bindning. Then I can also get a better implementation of the case of "mark for delete" at IList.RemoveAt... // Kristofer =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
