any developers have a dream: easy and efficient data binding.
To be really quick and profitable, RAD (rapid application development) tools and techniques must be strong in data binding. They must provide a programming interface that is both easy to use and effective, and provide easy design-time composition of user interfaces and effective support for complex scenarios of interrelated data, dependencies, and filtering. 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. This article reviews common Windows Forms data binding techniques and provides answers and explanations.
Like hunters and fishermen, developers always have stories to tell. Most times these stories are spiced up with some emphasis and include unnecessary details that are not necessarily true. I have stories that I tell to show how I brilliantly solved hundreds of tough problems for the uncontrolled happiness of paying clients. The story I'm going to summarize here is a bit different. There's no critical problem to work around to save a valuable deadline, and there's no architectural or design issue behind it. It's a simple story of a mere trick for developersit's not even particularly neat and elegant. However, about three years ago it triggered a process that made me appreciate and take much more advantage of the Windows Forms data binding architecture.
A reader sent me the following message. "I have a Windows form with two ComboBoxes that I want to show exactly the same data. When I select an element on the former, the latter automatically reflects the selection, and vice versa. I'm desperate. Please help."
I replied promptly to ask why on Earth two absolutely identical ComboBoxes were required on the same form. It turns out the form was intended to collect user details including a primary and secondary address. The ComboBox was therefore used to list available zip codes.
It took me a few minutes to reproduce the problem. I created a new Visual Studio .NET project, dropped in a couple of ComboBox controls and created a data source. Next I bound the DataSource
properties of the combo boxes to the same data source object and did the same with display and value fields. The code snippet below illustrates the point.
cboEmp1.DataSource = m_dataSet;
cboEmp1.DisplayMember = "Employees.lastname";
cboEmp1.ValueMember = "Employees.employeeid";
cboEmp2.DataSource = m_dataSet;
cboEmp2.DisplayMember = "Employees.lastname";
cboEmp2.ValueMember = "Employees.employeeid";
The sample application worked like a champthat is, in this context, badly. The two controls worked as if an invisible hand had synched them up. If there was a hand, though, it was not mine. I tried an equivalent piece of code, shown below.
cboEmp1.DataSource = m_dataSet
cboEmp1.DisplayMember = "Employees.lastname"
cboEmp1.ValueMember = "Employees.employeeid"
cboEmp2.DataSource = m_dataSet.Tables("Employees")
cboEmp2.DisplayMember = "lastname"
cboEmp2.ValueMember = "employeeid"
Surprisingly this worked and each ComboBox control retained its own selection completely unaffected by the other's behavior. Happy with the trick, I got back to the reader and presented the workaround as the complete solution to the issue. The reply caused me to pause: What if I have three ComboBoxes?