DataGrid101: Using Windows.Forms DataGrid

• Download source files - 56.51 KB

Introduction

Visual Studio .NET comes with an out-of-the-box grid control called DataGrid. Complete with data-binding and many nifty features, it seems like a handy control. However, once you start using it, you may find that its usage is somewhat cumbersome and - in many real-life situations - downright puzzling. This article attempts to lead the beginner through the ropes of using DataGrid, including:

• Data binding complex DataSets and OO class hierarchies
• Adjusting columns and various "style" issues
• Building usable context menus which behave according to position
• Refreshing data updated outside of the grid code

Test Case

DataGrid is extremely easy to use when addressing a single table. Its navigation abilities give a very sexy (although I tend to be a skeptic regarding usefulness) view of table relations. In order to avoid the obvious, I designed a simple yet realistic domain with structure and requirements that do not fit the simple binding abilities of DataGrid. I call this domain Cars and I will use it for examples throughout this article:

• A Car has 3 attributes: licensePlate, carType and price
• A CarType has 2 attributes: name and manufacturer
• A Manufacturer has a name

This domain can be found in the attached ZIP in 3 forms:

1. A Jet Database (Cars.mdb)
2. An XML schema (ObjectCars\CarDataSet.xsd)
3. A set of class files (ObjectCars\Car.vb,CarType.vb, CarManufacturer.vb)

The requirement is simple: write a grid-like screen to manage car prices. A snapshot was given above.

Data Binding

Why does DataGrid binding fall short? DataGrid defines its DataSource as a single IList, be it DataTable or object Array (multiple tables will create a "navigate" interface). While it is easy to infer all data relevant for a car by walking through relations/references, DataGrid column binding does not support a "dot" notation. In other words, when binding to a list of Cars, I can display Car.licensePlate, but not Car.carType.name. Let us walk through 3 possible solutions, each with its pros and cons.

Join Based DataBinding

When it comes to data querying, there is nothing easier or more maintainable than using SQL. A simple SQL join statement can feed the relevant data into a DataTable fashioned for our use. Pros: fast, easy, simple and maintainable. Don't stop reading here, because there are several flaws…

1. While you easily got the data to display, updating is now a major hassle: you need to "break" back into the original table structure before you can update your data base
2. In the 3-tier scenario there is something inherently wrong with requesting the server for data structured specifically for your screen. In cases where you don't own the server it is not only wrong, it is impossible.
3. The inherent data redundancy typical to a join (the same data exists in many rows) is error-prone when it comes to row creation.

An example of this approach can be found in the attached ZIP: SingleQueryCars\SQLJoinBasedForm.vb.

Multiple Table Based DataBinding

Microsoft tutorials emphasize the DataSet ability to store complex table structures allowing higher client independence and fewer round trips. Once we embrace this philosophy, we are required to join the tables on the client side: no SQL. Unfortunately, .NET does not include a Joiner utility class, so we need to join data in our code. The procedure is quite simple:

1. Define a new DataSet and, in it, a table with the required structure
2. Fill it by looping on the child table, in our case Cars

Here is the code:

Dim carRec As DataRow
Dim viewRec As DataRow
For Each carRec In MyCarsDataSet.Tables("Cars").Rows
  viewRec = MyGridViewDataSet.Tables("CarView").NewRow
  viewRec("license") = carRec("license")
  viewRec("type") = carRec.GetParentRow("TypesCars"). _
    Item("typeName")
  viewRec("make") = carRec.GetParentRow("TypesCars"). _
    GetParentRow("ManufacturerTypes").Item("ManufacturerName")
  MyGridViewDataSet.Tables("CarView").Rows.Add(viewRec)
Next

Essentially this is the same as what we did in an SQL join. The main benefit is client/server de-coupling, i.e. no server coding for grid purposes. The biggest drawbacks are client-side performance and additional procedural code. An example of this approach can be found in the attached ZIP: JoinBasedCars\LoopBasedJoinForm.vb.

Object List Data Binding

In many cases, it is best to leave DataSets as a link to the underlying DB and perform data manipulation using a class hierarchy (a.k.a. an "Object Domain"). The more logic in your application, the better this approach will serve you. Furthermore, in some cases Object Models are all we have. An example is when our server insists on handing data in Object form. Since "dot notation" is not supported, how can we display properties of anything but our "root objects" (i.e. cars)?

The solution is simple, although it may seem cumbersome at first: we create a new class (usually referred to as the "viewer" class), which wraps the root object and exports all needed data as properties. For instance, in our example we would code a CarViewer class wrapping a Car object and exporting the properties licensePlate, typeName and manufacturerName. We would then bind an ArrayList of these to the DataGrid.

It turns out that this solution is extremely powerful, since it gives us a natural place for a user-interface related code that is non-trivial: things like calculated attributes, complex use cases (how about "switch plates with another car"), etc. In fact, it usually makes sense to use viewer-based grids instead of performing "procedural joins," even if you have the data in a DataSet and not an Object Domain.

Not surprisingly, the author did not invent this concept. It is an adaptation of a well-known paradigm called MVC (Model-View-Controller) and you are welcome to read any of the multitudes of excellent articles available on the Internet. An example of this approach can be found in the attached ZIP: ObjectCars\ViewerBasedForm.vb.

Refreshing the Grid

No matter how you perform data binding, if your application views dynamic data you are bound to refresh the grid at some time. It turns out that this is another trivial task that was made "un-obvious." Here's how:

1. Get the DataGrid CurrencyManager
2. Call its refresh method

Note the parameter to BindingContext. This is where most people fail. It should be a reference to the exact object you bound.

' Get currency manager 
Dim cs As CurrencyManager = _
  CType(MyDataGrid.BindingContext(MyCarsDataSet.Cars), _
        CurrencyManager)
' Refresh
cs.Refresh()

For all you c#/c++/j# types: CType is the VB.NET cast operator.

Formatting the Grid

Now that we have all relevant data bound, it's a good idea to make it human-readable. Grid formatting is relatively easy, but from the amount of discussion devoted to it in news groups, one can infer that Microsoft did not expose it very neatly. I will try to sort the basics and give some pointers to more advanced stuff.

Basic Column Formatting

All grid formatting is centered about the TableStyles collection accessible via the grid property window. Here is how it works:

1. A style defines most of the grid formatting properties, including column format (via a collection called GridColumnStyles)
2. At any given moment, the grid adheres to one style selected according to the style MappingName property

Once you understand this, many of the basic tasks are, well, basic. Here are some examples:

• Column caption, width, Read/Write, control type (text box / check box) and more are defined in the column style
• Column order is determined by GridColumnStyle order
• If we want to "hide" a column, we don't map it to any column style

The only trick left is to determine the right mapping name:

• When grid shows a DataSet DataTable, use the table name as defined in the schema
• When grid shows an object data structure, use the structure data type (i.e. ArrayList)

Examples for this can be found in all 3 forms supplied in the attached ZIP. Of course, all these properties are accessible at runtime, allowing easy implementation of features such as "re-arrange columns," "hide column," etc.

Advanced Formatting

Unfortunately, some extremely useful features we expect of a DataGrid are not easily implemented and require more advanced programming. Chief among these are:

• The ability to use controls other than text box and check box
• The ability to dynamically control colors and fonts at cell level

Once we understand that the heart of formatting is the DataGridColumn class, then it is evident that to achieve advanced formatting we need to extend it in a manner that fits us. Excellent pointers for such work can be found here (combo in grid).

Context Menus

In real life applications, grids will usually have more than one context menu: column header menu will differ from cell menu; row header menu might differ from both and sometimes the menu may be affected by selection areas. Although DataGrid has only one ContextMenu, managing this kind of behavior is simple enough:

1. Create all needed menus, either on the designer or dynamically
2. Write a handler for the DataGrid.MouseDown event:
   1. Check for right-click
   2. Compute the row/column clicked
   3. Set the DataGrid.ContextMenu according to context

Note that this works since your handler is called before the context menu is displayed. Here is an example that shows a context menu only when clicked over a cell. It stores cell coordinates for later use by the context menu handlers:

Private Sub MyDataGrid_MouseDown(ByVal sender As Object, _
    ByVal e As System.Windows.Forms.MouseEventArgs) _
    Handles MyDataGrid.MouseDown
  Dim hi As System.Windows.Forms.DataGrid.HitTestInfo
  hi = MyDataGrid.HitTest(e.X, e.Y)

  ' Test if the clicked area was a cell.
  If hi.Type = DataGrid.HitTestType.Cell Then
     Me.MyDataGrid.ContextMenu = Me.GridContextMenu
     Me.manipulatedRow = hi.Row
     Me.manipulatedColumn = hi.Column
     ' of course I could have saved the whole "hi" structure.
  Else
    Me.MyDataGrid.ContextMenu = Nothing
  End If
End Sub

The Attached Source Code

That's it, folks. The attached ZIP contains 3 projects:

1. SingleQueryCars is a read-only grid based on an SQL join; it mainly shows column customization.
2. JoinBasedCars has similar functionality, but it also exemplifies client side join of several DataSet tables
3. ObjectCars is a bit more interesting (as I believe this is the best way most of the time); it demonstrates all discussed and a bit more, including:
   • Simple mapping a data set to an object domain
   • Viewer management
   • Column formatting
   • Context menu usage
   • Adding lines, deleting lines, hiding lines

Summary

There are already several .NET grids on the market which look much better than DataGrid and more will come. However, when used correctly, DataGrid can still take you a long way to a usable user interface and it is certainly worth your while experimenting with it further.

History

• 15 May, 2003 -- Original version posted
• 11 September, 2003 -- Updated