2

I've frequently used WPF to bind a datagrid to a collection of IEditableObject's. Almost every time I do this, it becomes something that I soon regret. Is there an unspoken rule to avoid implementing IEditableObject in my viewmodels altogether?

The most recent problem I've noticed is a memory leak. Some critical internal components (DataBindEngine, CommitManager, BindingGroup) are coordinating together to root memory references. It seems to be happening if the user closes out of a data entry window at an unexpected moment (eg. after a BeginEdit if the user never did anything to trigger a call to "CancelEdit" or "CommitEdit"). The rooting happens in a place that is quite deeply hidden within the databinding engine and it seems extremely difficult to control the default behavior at that level (aside from ensuring that I don't implement IEditableObject in any of my viewmodels).

Unfortunately it isn't always easy to avoid IEditableObject implementations. For example, when binding to ADO.Net, the datagrid wants to use a BindingListCollectionView (for the collection) and the DataRowView class for the individual records. Since the DataRowView class implements IEditableObject, there does not seem to be any way to easily forego the related bugs. I wish there was a way to tell the WPF datagrid to ignore implementations of IEditableObject, and pretend that it wasn't implemented.

On a general basis I'd like to know whether we should avoid binding to IEditableObject (and by that rule we would also avoid binding directly to ADO.Net as well). There seem to be a number of pitfalls to doing so, and I've heard WPF developers who are disparaging of ADO.Net. But I've never seen any formal or authoritative guidance from Microsoft on this matter.

PS. Aside from memory leaks in my databindings, here are some other examples of the types of troubles you can run into when binding to IEditableObject.

  • Unexpected problems with late binding updates

https://social.msdn.microsoft.com/Forums/vstudio/en-US/d48ccbca-6a3c-4aea-9875-4862fc4a49b9/wpf-datagrid-validate-cell-when-leave?forum=wpf

  • IEditableObject conflicts with BindingGroup (both attempt to serve similar purposes)

https://social.msdn.microsoft.com/Forums/vstudio/en-US/7f7196b8-b9dc-487d-93cd-e77f5b3d9906/confused-about-transactional-editing-edititemcanceledit?forum=wpf

  • IEditableObject protocol problems (because of overlapping goals with the BindingGroup class)

WPF DataGrid calls BeginEdit on an IEditableObject two times?

Potential fixes (uservoice idea): Ideally the WPF datagrid would have a property that would allow us to disable all the specialized handling of IEditableObject. This would allow the datagrid to work in a consistent way, whether a viewmodel implemented that interface or not. I found this user voice idea about making the BindingGroup functionality "optional" in a datagrid. I suppose this could have been part of the solution, but the idea was rejected. https://wpdev.uservoice.com/forums/427690-windows-presentation-foundation-wpf/suggestions/6736492-make-internal-use-of-bindinggroup-in-datagrid-opti

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
David Beavon
  • 1,141
  • 9
  • 16
  • to me this looks like something that should be discussed in WPF community feedback – Bizhan Jul 17 '18 at 14:30
  • 1
    Microsoft also suggests people use stackoverflow for community questions. https://learn.microsoft.com/en-us/dotnet/framework/wpf/getting-started/community-feedback There are **plenty** of wpf programmers on stackoverflow and many questions are in here already about IEditableObject and about the datagrid, and about memory leaks in WPF. – David Beavon Jul 17 '18 at 15:13

0 Answers0