Summary: ROCKY LHOTKA Shows You How To Write Code That You Can Add to Your Business And Collection Classes to Better Support The Features of Windows Forms Data Binding. (19 Printed Pages)
Download the vbobjectbinding.exe sample file.
Microsoft worked hard to make data binding useful when creating both Windows Forms and Web Forms interfaces. For the first time since data binding was introduced to Microsoft Visual Basic® years ago, it is truly practical in a wide range of application scenarios.
One key advancement is that data binding supports not only the DataSet, but also objects, structures and collections of objects, or structures. The basic ability to bind an object or collection to a control on a Windows Form or Web Form requires no extra work on Our Part. It is an automatic feature of data binding.
Web Forms data binding is read-only. In other words, it pulls data from the data source (DataSet, object, or collection) and uses the data to populate controls that are then rendered to the client device. This is straightforward behavior and requires No Extra Work On Our Part As We Create Either Objects or The UI.
Windows Forms data binding is read-write, and therefore more complex. In this case, data is pulled from the data source and displayed in our UI controls, but any changes to the values in the controls are automatically updated back into the data source as Well. Much of this Behavior Is Automatic and Requires No Extra Work ON Our Part, But There Are A Number of Features Available To US IF We Choose To Write Some Extra Code.
That is the focus of this article-code we can add to our business and collection classes to better support the features of Windows forms Data Binding. Thase Features Include:
Having the object or collection notify the UI that data has changed. Allowing the DataGrid to bind correctly to an empty collection. In-place editing of child objects in a DataGrid. Dynamic addition and removal of child objects in a DataGrid.For simple objects, we can implement events to notify Windows Forms data binding when our property values have changed. By adding these events, we enable the UI to automatically refresh its display any time the data in our object is changed. We also need to understand how to notify the Ui That a validation rule Has been Broken by Newly Entered Data. Improper Implementation of Validation Can make Data Binding Behave In Undesirable Ways.
In addition, there are a number of optional features we can support in our collections. Collections are typically bound to list controls such as the DataGrid. By properly implementing strongly-typed collection objects, we enable the DataGrid to intelligently interact with our collection and its CHILD Objects. We can also import the ibindinglist interface SO Our collection can intelligently interact with the datagrid in various woman.
Finally, there are some optional features we can support in objects that will be contained within a collection. We'll call these child objects. Child objects can implement the IEditableObject interface so the DataGrid can properly interact with the object during in-place editing. .
In the end, by adding a bit of code to our classes and collections, we can take advantage of one very powerful features of windows forms data binding.
Simple Windows Forms Data Bindings IN Object To Properties Of Controls On A Form Is Not Complex. For Instance, Consider The Following Simple Order Class:
Public Class Order
Private mid as string = "" "
Private MCUSTOMER AS STRING = ""
Public property ID () AS STRING
Get
Return MID
END GET
Set (byval value as string)
MID = Value
End set
End Property
Public property customer () AS STRING
Get
Return MCUSTOMER
END GET
Set (byval value as string)
MCUSTOMER = VALUE
End set
End Property
END CLASS
The Only Special Code Here is in The Declaration of the Variables:
Private mid as string = "" "
Private MCUSTOMER AS STRING = ""
Notice That The Variables Are Initialized with Empty Values As They Are Declared. This is not type by becault...
The reason we explicitly initialize them like this is because if we do not, the data binding will fail. It turns out that the automatic initialization of the variables does not occur by the time data binding tries to interact with our object, causing a Runtime Exception to Be Thrown When Data Binding Attempts to Retrieve The Value from the uninitialized variables.
However, explicit initialization of the variables occurs before data binding interacts with our object. This means that the variables are properly initialized by the time data binding retrieves their values so we avoid the runtime exception.
IF WE CREATE A FORM SIMILAR TO The One Shown in Figure 1. We can Simply Bind The Properties of the Object to the controls as the form loading.
Figure 1. Simple form layout for the order Object
THE CODE TO BIND An ORDER Object To The Form Would Would Look Like this: Private Morder As Order
Private sub orderrentry_load (Byval Sender as system.object, _
BYVAL E as system.eventargs) Handles mybase.load
Morder = new Order ()
TXTID.DATABINDINGS.ADD ("Text", Morder, "ID")
TXTCUSTOMER.DATABINDINGS.ADD ("Text", Morder, "Customer")
End Sub
The secret lies in the fact that every Windows Forms control has a DataBindings collection. This collection contains a list of bindings between the properties of the control and the properties of our data source (or data sources). An interesting side effect of this scheme is That We can Bind Properties from a Data Source To Several Different Control Properties. Also, We can Bind Different Control Properties To Properties from Multiple Data Source.
Just by using this simple data binding code we can create some pretty complex user interfaces. For example, in the sample code for this article you'll find that we bind the Enabled property of the Save button to an IsValid property on the business object. This Way the button is only available to the user.
Remember that this data binding is bi-directional. Not only is the data from the object displayed on the form, but any changes the user makes to the data is automatically updated back into our object. This occurs when the user tabs off each field. For instance, if the user changes the value in the txtID control, the new data is updated into the object as the user tabs out of the control. The data is updated into our object through the property Set routine. This is nice because it means Our EXISTINGPERTY CODE IS Automatic Or INVOKED; We don't need to do anything extra to support bi-directional data binding.notification of change Properties
Now that we've seen how simple data binding an object and the controls is, let's discuss how we can enhance our object to support automatic notification of changed properties. The issue here is that if some other code in our application changes the data in an Object, There is no way for the controls in the ui to know...............
What we need is a way for the object to notify the UI any time a property value changes. This is supported through events that we can optionally declare and raise from our object. When we bind a control to a property on our object, data binding Automatical Starts Listening for a Property Changed, WHERE Property Is The Name of the Property of the object.
For instance, our Order class defines an ID property. When the ID property is bound to a control, data binding starts listening for an IDChanged event. If this event is raised by our object, data binding automatically refreshes all controls bound to our object. We can Enhance Our ORDER CLASS BY DECLARING THESE Events:
Public Class Order
Public Event IDChange AS EventHandler
Public Event CustomerChanged As EventHandler
Notice that the events are declared to be of type EventHandler. This is required for data binding to understand the event. If we do not declare the events this way, we'll get a runtime exception when data binding attempts to interact with our object .
The EventHandler Is The Standard Event Model Used THROUGH Windows Forms. It defines The Event with Two Parameters-Sender (The Object Raising The Event) and E (An Eventargs Object).
With these events declared, we need to make sure to raise these events any time the corresponding property value changes One obvious place to do this is in the Set routines For instance, in the ID property we would do this..:
Public property ID () AS STRING
Get
Return MID
END GET
Set (byval value as string)
MID = Value
RaiseEvent Idchanged (Me, New Eventargs ())
End set
End Property
What can be trickier is to remember that any time we change mID anywhere in our class, we also need to raise this event. Most classes include code that modifies internal variables in addition to property Set routines. We must raise the appropriate event any time a Value Is Changed That Will Impact A Property.
For a better example, let's assume that our Order object will have a collection of LineItem objects We'll implement the collection a bit later, but right now let's look at the event and variable declarations of the basic LineItem class:. Public Class LineItem
Public Event ProductChanged As EventHandler
Public Event QUANTITYCHANGED AS EventHandler
Public Event PriceChanged As EventHandler
Public Event AmountChanged As EventHandler
Private MProduct As String
Private MQUANTITY AS INTEGER
Private MPRICE AS DOUBLE
Notice That We Have Four Events, But We Only Have Three Variables. The Amount Property Will Be Calculate by Multiplying Quantity and Price:
Public Readonly Property Amount () AS DOUBLE
Get
Return Mquantity * MPRICE
END GET
End Property
It is a read-only property. However, it can change. In fact, it will change any time that the value of either Price or Quantity changes, and thus we can raise an event to indicate that it has changed. For instance, when The Price Changes:
Public property price () As Double
Get
Return MPRICE
END GET
Set (ByVal Value As Double)
MPRICE = Value
RaiseEvent PriceChanged (ME, New EventArgs ())
RaiseEvent AmountChanged (ME, New Eventargs ())
End set
End Property
Not only do we raise the PriceChanged event because the Price property changed, but we also raise the AmountChanged event because we've indirectly caused the Amount property to change as well. This illustrates how we must be vigilant in our coding to ensure that these events Are raised when appropriate.
That said, it turns out that the AmountChanged event may not be strictly necessary. When we bind controls on a form to properties of an object, data binding listens for propertyChanged events for each property to which our controls are bound. If any one of them is raised, all the controls bound to that object are refreshed.In other words, if our form has controls bound to both the Price and Amount properties, raising the PriceChanged event will cause data binding to refresh not only the control bound to the Price property , but also the one bound to the Amount Property.
The downside to taking advantage of this fact is that the UI becomes tightly bound to the object implementation. If we later decide to only bind to Amount, our UI will not work correctly because no AmountChanged event will be raised. Because of this, it IS BEST to Declare and Raise a PropertyChanged Event for Each Property on Our Object.
THE REST OF THE CONTE for the LineItem Class Is Contained in The Sample Code Download for this article.
Binding to a strongly-type color
As we've noted, our Order object contains a collection of LineItem objects. In our UI, we can bind a DataGrid to this collection, allowing the user to easily add, remove, or edit the LineItem objects. The resulting UI is shown in Fighe.
Figure 2. Form with DataGrid Bound To Collection of Objects
We can Bind A DataGrid Control to an Array Or Collection with one line of cotne:
DIM arlineitems as new arraylist ()
DGLineItems.DataSource = arlineItems
While this works in that the data from the array is displayed in the grid, it does not provide all the features we'd expect from binding to a DataGrid control. This is because the basic array and collection classes do not provide enough information for the DataGrid to work the way it does when it is bound to a DataTable.We can create our own strongly-typed collection object, which can include some extra code to better support the features of the DataGrid. In particular, we'll end Up Being Able To Support The Following:
Binding to an empty collection not the collection Dynamic Addition and Removal of child Objects in-place editing of child objects
Let's tackle these issues one at a time. The first one, binding a DataGrid to an empty collection, is relatively easy to solve. The problem here is that the DataGrid needs to be able to figure out the columns that are available from the data source . IF WE BIND THE DATAGRID TO A Simple Array, ArrayList, or Collection Object, How does it figure? Out?
The answer is that it looks at the first item in the collection and then uses reflection to get a list of the Public properties and fields of that item (be it a structure, object, or simple type such as Integer).
If the collection is empty, then this technique will not work and the DataGrid is unable to automatically generate a list of columns. The result is that the control is displayed to the user with no content whatsoever, as shown in Figure 3.
Figure 3. DataGrid Bound to Empty Collection
To fix this, all we need to do is create a custom, strongly-typed collection that has a default, strongly-typed Item property. The DataGrid can use the type of the Item property to get a list of the specific Public properties and fields of that type. Because of this, it no longer needs to look at the first item in the collection to get the list of columns, so we can bind to an empty collection and have it work nicely.Figure 4. DataGrid bound to empty, Strongly-typed collection.
WHEN You Compare Figure 3 To Figure 4 It is obvious That The strongly-type collection is preferable Because The DataGrid Displays The List of columns, Even Though no items are presentin either case.
Implementing a strongly-typed collection is straightforward. The Following Steps Outline The Basic Process:
Add A New Class To The Project Inherit from System.Collections.CollectionBase Implement A Default, Strongly-Typed Item Property Implement Strongly-Typed Add and Remove Methods
For instance, in the code download you'll find a LineItems class that implements a strongly-typed collection of LineItem objects The key to allowing the DataGrid to bind to an empty collection is the Item property.:
Default Public Readonly Property Item (Byval Index AS Integer)
As lineItem
Get
Return CType (List (INDEX), LINEITEM)
END GET
End Property
Note that the property is strongly-typed in that it returns objects of type LineItem. It is also important that it is marked as Default and is a Property, not a Function. Data binding requires this specific declaration in order to work.
In the class from the code download you'll also see that there are strongly-typed implementations of Add and Remove methods, which are part of any strongly-typed collection, but are not required for data binding to work.With very little extra Coding, We've Solved The First Is S.
Implementing ibindinglist
Data binding has a formal scheme by which a collection can indicate that the collection has been changed. This is done by having the collection implement the IBindingList interface, which includes a ListChanged event. Any time the collection changes (due to the addition, removal, OR Change of An Item This Should Raise This Event To Tell Data Binding That The Underlying Data Has Changed.
IbindingList Supports More Than Just Change Notification. The Following Table Lists The Optional Features We can support by Implementing The Interface:
Optional featureDescriptionChange notificationNotifies the UI of any changes (additions, removals, or edits) to the collectionAutomatic addition of itemsAllows the DataGrid to insert new items into the collection as the user moves to the end of the gridAutomatic removal of itemsAllows the DataGrid to remove items from the collection when the user presses the Delete key in the gridIn-place editing of itemsAllows the DataGrid to perform in-place editing of items in the collection (this also requires that the item implement IEditableObject, which we'll discuss later) SearchingEnables a Find Method to search the collection for a specific ItemsortInables
Note that it is up to us to implement each of these functions. The IBindingList interface merely defines the properties, methods, and events. We must write the actual code. Fortunately each of these features is optional. The IBindingList interface defines a set of Boolean Properties We User Particular Collection Supports: SupportSchangeNotification Allownew Allowedit Allowremove SupportsSsearch Supportssorts
We only return True for those features we choose to implement. In the code download, you'll find the LineItems collection that implements change notification, add, edit, and remove. It does not support searching or sorting, so those two properties return False .
Basic Implementation of The Interface Requires That We Use The IMPLEments Keyword:
Public Class LineItems
Inherits CollectionBase
Implements IbindingList
By adding this statement, we indicate that we're implementing the interface, so we must provide implementations for all the methods defined by the interface. This includes methods that we might not actually want to implement, such as SortDirection (since we're not Implementing sorting. The thing is, we don't name the method; we just need to code the shell of the method:
Public Readonly Property Sortdirection () _
As system.componentmodel.listsortdirection _
Implements system.componentmodel.ibindingList.SortDirection
Get
END GET
End Property
For The Methods That We Are Implementing, We'll Write Real Code.
Change Notification
For instance, we're supporting change notification, so we notify data binding anytime the collection is changed. This means that any time an item is added, removed, or changed, we need to write some code.The first step is to indicate that WE Support Change Notification:
Public Readonly Property SupportsChangeNotification () _
As boolean imports_
System.componentmodel.ibindingList.supportschangeNotification
Get
Return True
END GET
End Property
We Also Must Declare The ListChanged Event As Defined by The Interface:
Public Event ListChanged (Byval Sender As Object, _
Byval e as system.componentmodel.listchangedendeventargs _
Implements system.componentmodel.ibindinglist.listchanged
Then all we need to do is raise this event any time the collection changes. This is not as hard as it might sound because the CollectionBase class defines a set of methods we can override so we know exactly when the collection has been changed. The Ones We need.
OnclearComplete OnInsertComplete OnremoveComplete OnsetComplete
WE CAN SIMPLY RAISE The ListChange Event INSIDE EACH OF THESE MESE Methods. For instance, WHEN an ITEM IS INSERTED, WE RAISE THE EVENT:
Protected Overrides Sub OnInsertComplete (Byval Index As INTEGER, _
Byval value as object)
RaiseEvent ListChanged (_
ME, New ListChangeDeventArgs (ListChangedType.Itemadded, Index))
End Sub
Of affairs.
Editing and removing items
The IBindingList interface defines the AllowEdit and AllowRemove properties so we can control whether we want to allow the DataGrid to allow in-place editing and dynamic removal of items in the collection. There are no other IBindingList methods to support these features. They are simply toggles we can use to control what is allowed.However, if we return True for AllowEdit, then our child objects themselves must support in-place editing by implementing the IEditableObject interface, which we'll discuss later in this article. No exceptions will be thrown If the child objects don't import the interface, but to get prot behavior as expected by the user theme.
Add Items
We can also allow the DataGrid to dynamically add new items to the collection. This is a nice feature as it allows the user to simply navigate to the bottom of the grid and they automatically get a new row into which they can add data. This feature is dependant on our support for in-place editing. If we allow adding of items, we must also enable editing of items, so AllowEdit must return True, and our child objects must implement the IEditableObject interface.
IBindingList defines the AllowNew property, which must return True if we support this feature. It also defines an AddNew method that we must implement. This method must include code to create a new child object, add it to the collection, and return it as a RESULT OF THE METHOD.
For Instance, We can create A New LineItem Object As Follows:
Public Function AddNew () AS Object IMplements_
System.componentmodel.ibindingList.AddNew
DIM ITEM As new lineItem ()
List.add (item)
Return Item
END FUNCTION
The most common difficulty with this action is that we must be able to create child objects without any user input. The DataGrid itself requests the addition of the child object, so we must be able to programmatically create a new child object on request at any time as shown in the code.Some object designs require that constructor data be provided as child objects are created, so they are preloaded with information. that type of model will not work in this case because there's no way to get child-specific information from The User Before Creating The Child Object.
Once we've implemented AllowNew and AddNew, the DataGrid will allow the user to navigate to the bottom of the grid, and new child objects will be automatically inserted into the collection (and thus the grid) for the user to edit.
Implementing IeditableObject in Child Classes
As we've discussed, in-place editing requires not only the implementation of the IBindingList interface in our custom collection, but also the implementation of the IEditableObject interface in the child classes.
The IEditableObject Interface Appers Deceptively Simple. It merely defines threeem.
MethodDefinitionBeginEditCalled by data binding to indicate the start of an edit process, and that the object should take a snapshot of its current state.CancelEditCalled by data binding to indicate that the edit process is over, and that the object should reset its state to original values .Endeditcalled by Data Binding to indicate That The Edit Process Is over, and this the object shouth keep any call value.
Copying data
Implementing this interface requires that we have the ability to take a snapshot of the current state of our object. This typically means somehow making a copy of the values of all the instance variables in our object. There are a variety of ways to make this copy , Unfortunately, That Discussion Is Outside The Scope of this Article. In this article, we'll simply Copy the variable value value to another set of variable values: moldproduct = product
moldprice = price
Moldquantity = quantity
To restore the values, We Simply Copy The VALUES The Other Direction.
Knowing if we are new
It turns out that to properly implement IEditableObject we need to know whether this particular child object has been newly added to the collection. The reason is that we need to remove a new child object from the collection if the user presses the Esc key to cancel the EDIT. ON THE OTHER HAND, IF The User Is Editing a Preexisting CHild Object and The Press Esc, We don't want to remove the object from the collection. We Just Want to restore Its State To The Previous VALUES.
To Solve this Issue, WE NEED A Variable To Track WHETHER THE OBJECT IS New or Not. We'll Declare A Variable Named Misnew and We'll Set The Value To True When It Is First Declared:
Private Misnew as boolean = True
IT WILL GET SET TO FALSE AFTER The First Edit Process IS Complete. This is where caledit or endedit is caled.
Beginedit
What makes this tricky is that BeginEdit can (and will) be called numerous times during the edit process. The on-line help for the .NET Framework SDK makes it clear that we should only honor the first call, and ignore all others. To Do this, we'll Declare and use a boolean variable, medity, as stock:
Public Sub BeGinedit () Implements_System.comPonentModel.ieditableObject.Beginedit
IF not mediting then
Mediting = TRUE
MoldProduct = Product = Product
moldprice = price
Moldquantity = quantity
END IF
End Sub
This Variable Will Be set to false in Both The Canceledit and Endit Methods, SO Any Future Edit Process Will Work Properly.
Endedit
The EndEdit method is the easiest to implement because this method is called when the edit process is over and we want to keep any changes to the data All we need to do is set mEditing to False to indicate that the edit process is over.:
Public Sub endedit () Implements_
System.componentmodel.ieditableObject.endedit
Mediting = false
Misnew = false
End Sub
Note That We Also Set Misnew To False In this method. At this point we know That The User Has Accept The child Object, SO IT IS No Longer New (at Least from The Perspective of Data Binding and The DataGrid).
Canceledit
The CancelEdit method is perhaps the most complex of the three. It not only needs to restore the values of the object to the values we stored when BeginEdit was called, but we also need to see if the child object is new. If the child object Is New, We need to ensure That it is remove from the collection.
To Tell The Collection Object That We want to be removed, We'll Declare an Event:
Friend Event Removeme (Byval LineItem As LineItem)
......................... ..
The Canceledit Code The Looks Like this:
Public Sub Canceledit () IMPLEMENTS_
System.componentModel.ieditableObject.canceledit
Mediting = false
Product = MoldProductPrice = Moldprice
Quantity = moldquantity
IF Misnew Then
Misnew = false
RaiseEvent Removeme (ME)
END IF
End Sub
First, we indicate that the edit process is complete by setting mEditing to False. Next, we restore the state of the object to the values we stored in BeginEdit. Each property value is restored to the previous state. Finally, we check the mIsNew variable To See if this Was a newly added child object. if So, We Raise The Removeme Event To Tell The Collection That Should Be Removed.
Handling the removeme Event
Since our child objects may now raise events to the collection, we need to enhance the code in the custom collection class to handle this event. The first step is to add a method to the LineItems collection class to handle the event. This code will be Run when Event is raised:
Private Sub Removechild (Byval Child As LineItem)
List.remove (child)
End Sub
All it does is remove the specified child object from the collection. Notice that there's no Handles clause on this method. How does it get the event? The answer lies in the AddHandler function. This function allows us to dynamically connect an event to an event Handler at runtime. it is particularly useful when Creating Collection Classes, AS IT Allows Us Hook Child Object Events As Each Child Object Is Added To The Collection.
In the collection class, we already have an OnInsertComplete method where we raise the ListChanged event We can add the AddHandler call to this method, so it is sure to be invoked for any newly added child object.:
Protected Overrides Sub OnInsertComplete (Byval Index As INTEGER, _
Byval value as object)
AddHandler CType (Value, LineItem) .removeme, Addressof RemoveChild
RaiseEvent ListChanged (_
ME, New ListChangeDeventArgs (ListChangedType.Itemadded, Index))
End Sub
Now, when a new child object is added to the collection, we establish a link between the RemoveMe event of that object and our RemoveChild event handler. When the user presses Esc on a newly added line item, that child object will automatically be removed from The Collection THROUGH MECHANISM.
Implementing IdataErrorInfo in Child Classes
There's one last optional feature we can add to our child class-the ability to tell the DataGrid when the line item is valid or invalid. This is done by implementing the IDataErrorInfo interface in our child LineItem class.
The IdataerrorInfo Interface Defines Two Methods.
MethodDescriptionErrorReturns text describing what is wrong with this object (an empty string indicates no problem) .ItemReturns text describing what is wrong with a specific property or field on the object (an empty string indicates no problem).
The key method is the Error method. The Item method allows us to provide more detailed information if we choose, but the DataGrid keys off the text returned by Error to determine if the line item is valid or not. In the code download, you ' Ll See That I Only Implement Code in The Error Method:
Private Readonly Property [Error] () AS String Implements_
System.componentmodel.idataerrorinfo.Error
Get
If Len (Product) = 0 Then Return "Product Name Required"
IF quantity <= 0 Then Return "Quantity Must Be Greater Than Zero"
Return ""
END GET
End Property
This method checks a couple business rules for the line item. We're saying that a line item must have a product name and a quantity that is greater than zero. If either of these conditions is not met, we return text that indicates the nature Other hand, if the object is valid, we return an empty string.the result is what the DataGrid Graphically Indicates Which Line Items Are Valid, AS Shown In Figure 5 Below.
Figure 5. DataGrid Indicating The Validity of Line Items
Notice as private. IF we make it it public
Conclusion
Data binding has finally come of age. The implementation of data binding in both Web Forms and Windows Forms is practical and useful in many cases. One of the biggest benefits is that we can now data bind to objects and collections, not just to the DataSet And Related ADO.NET OBJECTS.
As we've seen in this article, with a relatively small amount of extra code in our business and collection classes, we can allow Windows Forms data binding to interact with our objects in very rich and powerful ways. No longer are we stuck using pure Data Technologies in Rad Development. Now We can Be Object-Oriented and Rad At The Same Time!
