In this scenario you will take your first look at using the .NET Framework to manage our data binding with no modification to our Employee class and an actual reduction of logic within the form. The code for this scenario appears in the "OneWayDataBindingSolution".
In this solution, I removed the two marshalling functions, LoadValuesToForm and LoadValuesFromForm within the Employee display form. These two functions were replaced with SetDataBindings, which is called from the form's load event handler. Again, the logic to set up the data binding could be included directly in the load event handler, however centralizing the logic in its own function leads to better code reuse and a cleaner implementation. The SetDataBindings method appears in Figure 11.
Figure 11
The method simply defines the data bindings between the GUI elements and the local object's properties. Each binding needs to be set up individually, such as the code in lines 243 - 244. Examining this line close, you see the following syntax:
Figure 12
From this you can conclude that each control has a collection of data bindings associated with it. Within this collection, each property of the control can have a data binding. One important point is that no property can have more than one data binding associated with it. You can assign more than one; however, a System Argument exception will be thrown. This is why each binding is preceded with a check to see if a binding already exists for the specified control's property and if it does, it is removed. An example of this code appears in line 239 - 241:
Figure 13
Looking closer at the syntax to create the binding (Figure 12, Lines 242 - 244), you see that you specify the property of the control, "Text", the data source, _oEmployee, and the property on the data source, "firstName". It is interesting to note that in the case sensitive world of C#, the property names specified for the control and data source are not case sensitive.
Because the control's property to use for the binding is specified within the binding syntax, it is just as easy to bind to other properties, such as the "checked" property of a check box, which you do in lines 271 - 272.
Another point of interest is that the data binding mechanisms automatically handle conversion for us. No longer do you need to write code to convert our decimal and DateTime values to and from strings. This is a nice feature in that as developers you no longer need to worry about such low level plumbing details. Another feature is that the input is filtered. If you run the project and try to enter a non date value for the Hire Date text box or a non numerical value for the Salary text box, the entries will be discarded and the original values are restored.
Note, however, when the application runs, you get a default formatting. In the case of Hire Date text box you get a date and time displayed; however, this is not what you wanted. In the manual data binding example, you were formatting the value using the DateTime's ToShortDateTime() method. Alas, Microsoft addresses this scenario through allowing us to assign an event delegate that will be called when the data binding mechanisms format the data for display in the control. In this case, you need to assign an event delegate to the Format event raised by the binding when it is preparing to format the value for the assigned control. In order to do this, I created a second method within the form to define the data bindings, SetDataBindingsWithFormat. This method adds the necessary event plumbing to control the format of the display. I also defined an additional method as the delegate, DateTimeToShortDateString. As you are running the sample code, you can call either SetDataBindingsWithFormat or SetDataBindings to see the difference. The new code to add the event delegate is shown in Figure 14.
Figure 14
As Figure 14 shows, the binding for the hire date textbox, including registering the event handler is defined prior to assigning the binding to the actual control. This is because when the binding is assigned to the control, the binding mechanism will automatically pull the value from the data source. So, if the binding was defined "on the fly" and then assign the handler as in Figure 15, the formatting would not be applied.
Figure 15
Data binding can be seen working by running the application, changing some of the values in the text boxes, and clicking the Save button. You could either set a break point in the Save click event handler or within the object to inspect the values to see that the object's properties are updated with the new values. Alternatively, you could look at the serialized output in the Employees.xml file.
In this implementation, however, the data flow is only one way - from the form to the object. If the object's property values change, the changes will not be reflected in the form. This can be verified by clicking the Load New Values button. The click event handler for this button changes the objects values behind the scenes. However, the form values do not change. Clicking the Save button at this point will cause the object to save with values different from the values shown in the form.
If data binding is only one way, you may ask, "Why did the initial values populate in the form?". The answer is that when the data binding in assigned, the data binding mechanisms will look at the current values of the properties, but this is the only time that the controls will pull values from the object, until the changes outlined in the next section "Data Binding 301" are implemented.
<< Introduction • • Data Binding 301: Graduate Level Data Binding >>
