Previous | Index | Next 

[INFO] Minor differences between VB6 and VB.NET DataGrid controls

VB Migration Partner converts VB6 applications that use the DataGrid control. However, the VB.NET application produced by the conversion process uses the “original” DataGrid control, which is accessed and manipulated through COM Interp. We have found that a few features of the control don’t work correctly when the control is placed on a .NET form:

  1. Most column properties set at design time – including Visible, Locked, Format, AllowSizing, WrapText, Alignment, DividerStyle, and Width – aren’t migrated.
  2. In VB6, assignments to the DefColWidth property are ignored if the VB6 developer had used the “Retrieve Fields” command to populate the grid’s column. In migrated VB.NET applications, however, assigning a value to this property resizes all the columns to the specified width.
  3. In a VB6 application you typically need to invoke the DataGrid.ReBind method after adding a new column to the grid, in order to fill the new column with values from the database. In VB.NET applications the ReBind method has the effect of restoring the original set of columns, therefore in practice you can’t add a column at runtime.
  4. Modifying the RowHeight property at runtime has no effect if the parent form has its ScaleMode property set to 0-User.
  5. Under VB.NET, the DataGrid control fires a few spurious GotFocus and LostFocus events. For example, when the user clicks on another cell on the same grid, the following events are fired under VB6: MouseDown, MouseUp, Click, RowColChange, RowColChange. The same action fires the following events under VB.NET: LostFocus, GotFocus, MouseDown, GotFocus, MouseUp, Click, RowColChange, RowColChange, LostFocus.

Even not counting these minor issues, we recommend that you don’t use the original DataGrid control through COM interop in real-world business applications, because this control is prone to unexpected behaviors (or crashes) when placed on a .NET form.

 

Previous | Index | Next