DataBinding VB6 vs. VB.NET by William Ryan

Most business related applications, in one way or another, involve controls that were populated from a database.  Even in instances where they aren't populated by a database, things have changed dramatically FOR THE BETTER in .Net.  For instance, many times you may know that only x number of choices should even be in a Listbox control, and it's totally appropriate to hard code them in the IDE (a listbox full of all 50 States comes to mind).  After all, if you go to the database to fill the listbox, you will incur some overhead associated with database access.  On the other hand, you get flexibility, if the Puerto Rico were to become a state for instance, you wouldn't have to recompile your app.  On the other hand, if you hard coded the states, you'd gain performance at the expense of some scalability.  However, conisdering the likelihood and frequency of new states becomming members of the US, the tradeoff is probably worth it.  Suffice to say that it really depends on the needs of your app.  Nonetheless, let's look at the old VB6 way of dealing with this:

Private Sub UserForm_Initialize() Call LoadStates(myList) End Sub Private Sub LoadStates(ByVal ctrl As Control)     ctrl.Clear     With ctrl         .AddItem ("Alamaba")         .AddItem ("Arkansas")         .AddItem ("Many other states")         .AddItem ("Wymoming")     End With     End Sub

What's wrong with this approach?  Well, other than the Ugly Ugly Ugly weak typing (after all, I could pass in a TextBox), it takes some serious code to implement all 50 states (50 lines for the .AddItem(s) alone), if I wanted to add Items to the listbox, I have to refer to it directly, or pass the listbox to my function coupled with the new value.  That's just ugly.  Moreover, what if I had a bunch of other things that wanted to use the List of states?  So I could modify this, use an array and iterate through it calling .AddItem at each step.

Now, how have things changed in .NET?  Well, the first thing is that you can databind to a DataTable (and since they didn't exist in VB6 that's one change).  Ok, but big deal?  The cooler part is that you can bind to Collections, Arrays and anything that Implements IList.  So in this example, I could create an Array, ArrayList custom object which implements the IList Interface.

How?

Dim States() as String = ("Alabama", "Arkansas", "Many other states", "Wyoming") myList.DataSource = States

Now, this approach is certainly cleaner and any control or code snippet can use States().  On the other hand, it has some limitations.  The biggest is that you can't change the Items in the array with this method.  Similarly, if you use this, you can't add to the array and have it reflected in the control.  That's a pretty big limitation, but depending on your app, it may or may not be an issue and it's still an improvement over VB6's method.

IList is the way to work around this and make loading controls lightyears better in .NET than it was in VB6.  Check out this simple code snippet:

Dim States() as String = ("Alabama", "Arkansas", "Many other states", "Wyoming")
myList.Items.AddRange(States)

If you add anything to the array, it will immediately be reflected in the control.  Moreoever you can change whatever you want without causing any problems.

This is probably the simplest, but often overlooked differences of binding controls in .NET vs. previous versions.  However, a full discussion of databindings is well beyond the scope of this article and there are more articles on this subject.  My goal is to show you an interesting difference in how you can handle things in .NET.  In my next article, I'll walk you through Complex databinding (and this is where .NET really gets cool)

Enjoy!