Browse DevX
Sign up for e-mail newsletters from DevX


A Look Under the Hood of Windows Forms Data Binding : Page 6

In Windows Forms, the data binding machinery is highly sophisticated and designed to meet common needs of former client/server applications, now migrating to the more modern .NET multi-tier design. The binding manager is a logical component that plays a key role as it enables data-bound controls grouped in a container control and bound to the same data source object to detect each other's changes and reflect their own user interface automatically.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

What About Custom Controls?
In Windows Forms only a few controls are data-bound and support the data binding mechanism as described so far. They are: ComboBox, ListBox, and DataGrid. Other controls, including TextBox, support a simpler binding model—the model managed by the PropertyManager object. So what about custom controls?

Can you write a new control that behaves like the DataGrid or the ComboBox? Sure you can.

In an article I wrote in the February 2002 issue of MSDN Magazine I discussed a data-bound ListView control that detects selection changes in a ComboBox or DataGrid and refreshes its own view.

In the set accessor of the DataSource property you retrieve the binding manager and hook up the CurrentChanged event. When the event fires you retrieve the DataMember property and interpret its content the way you like. You are free to employ a completely custom syntax to let callers pass information to your control through the DataMember property. The value assigned to DataMember should be anything your control can understand. A dot-separated navigation path is simply the .NET Framework default syntax. As such, it is arbitrary and can be changed in a custom control.

In summary, Windows Forms data-bound controls follow a pattern that automatically synchronizes them when bound to the same data source object. (Note that I'm talking about the same data source object, not just the same data.) This happens because all controls inherit the container's binding context. To keep two or more controls that are bound to the same data source out of sync, just link them to distinct binding contexts. Here's an example:

cboEmp1.BindingContext = New BindingContext cboEmp1.DataSource = m_dataSet cboEmp1.DisplayMember = "Employees.lastname" cboEmp1.ValueMember = "Employees.employeeid" cboEmp2.BindingContext = New BindingContext cboEmp2.DataSource = m_dataSet.Tables("Employees") cboEmp2.DisplayMember = "lastname" cboEmp2.ValueMember = "employeeid"

This code rewrites the aforementioned example of the two ComboBoxes sharing the same data. By giving each control a distinct binding context, you keep them out of sync.

Cross-Form Binding
All the examples I have considered until now are based on a single form. Can you extend this binding model to work over multiple forms? Yes. The feature revolves around the scope of the binding context. The binding context is a collection of bindings stored in a given control—the form in the simplest case. This means that two distinct forms have distinct binding contexts. Or, at least, this is the default scenario.

Imagine a form that loads and displays some data—for example, all information about customers or employees. Users select a particular record and click to get more details. In this case, though, the application supplies the details view as a separate modeless form. You would like to select a new employee in one form and see his details in the other form, and you'd like to do this with virtually no code and automatically as before. Is this possible? Of course.

The code snippet below shows the code you can use to open the details form.

Sub Button1_Click(ByVal sender As Object, _ ByVal e As EventArgs) _ Handles Button1.Click Dim f As New DetailsForm f.SetData(BindingContext, m_data) f.Show() End Sub

Figure 3: Users select a record on the parent form and child records automatically display in the secondary form.
SetData is a custom method defined on the application-specific DetailsForm class. The method takes a couple of parameters—the binding context of the parent form and the data source. Listing 2 shows the full source code of the DetailsForm class.

The DetailsForm class has a couple of custom members that are set using SetData. These internal members are placeholders for the parent form's data source and binding context. These members are used when the form loads—an event triggered by the Show method—to configure the details form child controls. In particular, the binding context collection of the details form is set to the same binding context as the parent. All data-bound controls in the details form are bound to the parent's data source. In the end, the two forms now share binding context and data source objects. As a result, the binding model works as expected irrespective of the different windows involved. (See Figure 3.)

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date