Do I need a BindingSource AND a BindingList for WinForms DataBinding?
Asked Answered
W

2

13

I want to display a list of people in a DataGridView in a Windows Forms app. I want my service layer to return a list of Person objects (e.g., IList<Person>). I want changes in the list to be reflected in the DataGridView and vice versa. My understanding is that using the BindingSource facilitates working with DataGridView. My question is for the two-way databinding to work, do I need:

//pseudo code
BindingSource.DataSource = IBindingList<Person>

or can I do:

BindingSource.DataSource = IList<Person>

What's the difference? If my make changes to the list will the DataGridView be updated either way? And if I have to use the BindingList, it seems a little wonky (because of creating a dependency) to return a BindingList from my service layer, is there a way around that?

Microsoft says of the BindingList (in the Remarks section) http://msdn.microsoft.com/en-us/library/ms132679.aspx:

"However, the typical solutions programmer will use a class that provides data binding functionality, such as BindingSource, instead of directly using BindingList<T>."

Warmth answered 13/1, 2011 at 1:17 Comment(0)
F
5

If you use BindingList<T> then changes that you make through the underlying list will be reflected in the data bound controls because BindingList raises an event when the list is changed. Most other collections do not.

If you use a normal collection as the data source then changes that you make through other data bound controls (or through the BindingSource) will still be reflected, but changes to the underlying collection directly will not.

Foggy answered 13/1, 2011 at 1:31 Comment(1)
Part of my confusion was that some people seemed to suggest you did not need to use a BindingList to get two-way databinding as long as you were using a BindingSource. But I guess what you're saying is that's only true if you only modify the list through the BindingSource.Warmth
V
12

Binding to an IList<Person> will only give you one-way binding; changes to the list or list items will not be reflected in the DataGridView. You can use a BindingList or BindingSource to get this functionality instead, but your Person class will still need to support INotifyPropertyChanged or else you will only get synchronisation when items are added/removed to/from the list, not when the list items themselves change.

If you want to avoid a dependency on System.Windows.Forms, you could use ObservableCollection<Person> instead; this supports the necessary change notifications and can therefore be used as a two-way binding source.

Veneration answered 13/1, 2011 at 1:33 Comment(3)
Unless he's using .NET 4, ObservableCollection carries an even more burdensome dependency because it is defined in a WPF assembly (WindowsBase). It was only moved to System.dll in .NET 4.Foggy
What's the difference between BindingList<T> and BindingSource? I tried both and both seem to work. Is one newer than the other? Should one prefer BindingList<T> because it is typed?Unscientific
@Unscientific The main difference is that BindingSource is a WinForms component whereas BindingList<T> can be used in any type of application. BindingSource has a few extra display/presentation features that improve the user experience in WinForms.Veneration
F
5

If you use BindingList<T> then changes that you make through the underlying list will be reflected in the data bound controls because BindingList raises an event when the list is changed. Most other collections do not.

If you use a normal collection as the data source then changes that you make through other data bound controls (or through the BindingSource) will still be reflected, but changes to the underlying collection directly will not.

Foggy answered 13/1, 2011 at 1:31 Comment(1)
Part of my confusion was that some people seemed to suggest you did not need to use a BindingList to get two-way databinding as long as you were using a BindingSource. But I guess what you're saying is that's only true if you only modify the list through the BindingSource.Warmth

© 2022 - 2024 — McMap. All rights reserved.