Mappings for Visual Basic 6 ActiveX Controls

Mappings for Visual Basic 6 ActiveX Controls

Visual Basic 6 provides a number of ActiveX controls, such as the RichText, Masked Edit, and Common Dialog controls, as well as the Windows common controls ProgressBar, Slider, StatusBar, Toolbar, TreeView, and so on. Table 19-1 lists the Windows Forms controls that make suitable replacements for Visual Basic 6 ActiveX controls.

Table 19-1 Mapping of Visual Basic 6 ActiveX Controls to Visual Basic .NET Windows Forms Controls

Visual Basic 6 ActiveX Control	ActiveX Control Library	Visual Basic .NET Windows Forms Control
ADO Data control*	MSAdodc.ocx	ADODC control provided by the Visual Basic compatibility library
Common Dialog	ComDlg32.ocx	OpenFileDialog, SaveFileDialog, FontDialog, ColorDialog, and PrintDialog
DataGrid	MSDatGrd.ocx	No equivalent control; Windows Forms DataGrid does not bind to ADO data, just to ADO.NET data
Rich TextBox	RichTx32.ocx	RichTextBox
SSTab Denotes an ActiveX control that is automatically upgraded to the equivalent Windows Forms control.	TabCtl32.ocx	TabControl
ListView	MSComCtl.ocx	ListView
TreeView	MSComCtl.ocx	TreeView
ImageList	MSComCtl.ocx	ImageList
TabStrip	MSComCtl.ocx	TabControl
Toolbar	MSComCtl.ocx	ToolBar
StatusBar	MSComCtl.ocx	StatusBar
ProgressBar	MSComCtl.ocx	ProgressBar
Slider	MSComCtl.ocx	TrackBar
UpDown	MSComCt2.ocx	NumericUpDown
MonthView	MSComCt2.ocx	MonthCalendar
DTPicker	MSComCt2.ocx	DateTimePicker

ActiveX Controls vs. Windows Forms Controls

For the most part, the Windows Forms controls listed in Table 19-1 offer the same functionality as their ActiveX control counterparts. One of the main differences as demonstrated by the ProgressBar upgrade example given earlier is that features of a Windows Forms control are not exposed in the same way. For example, the same type of properties may exist but have different names. In the case of the ProgressBar control, the Windows Forms control s Maximum and Minimum properties equate to the Max and Min properties of the ActiveX control. For properties such as these, a simple one-to-one mapping exists, and it is easy to find the equivalent property, method, or event when replacing an ActiveX control with a Windows Forms control.

We refer to controls that do not contain any subobjects, such as a collection of items or nodes, as having a flat object model. This means that all the properties and methods for the control exist directly on the control. You need to use only one dot (or period) to access any one of the properties or methods when writing code. Replacing a flat-model ActiveX control such as a ProgressBar or Slider with its Windows Forms equivalent is a relatively straightforward task. With both controls the ActiveX version and the Windows Forms version on a form side by side, you can use IntelliSense or the Object Browser to take a quick inventory of each control and compare how you map the properties, methods, and events from one control to the other.

We refer to controls that have properties that return objects such as collections or other complex structures as having a deep or rich object model. Controls such as TreeView and ListView fall into this category. The TreeView control, for example, has a Nodes property representing a collection of Node objects. The Nodes collection is itself an object having its own set of properties and methods. One of these methods the Item method returns a Node object that in turn has its own set of properties and methods. You can navigate from the control to a child object by using a dot (or period) to separate each successive object in the object hierarchy.

Replacing a rich-model ActiveX control with the equivalent Windows Forms control presents a unique challenge. The challenge stems from differences in how the object models allow you to interact with subobjects of ActiveX and Windows Forms controls. ActiveX controls take a more property-centered approach to adding or navigating a control s subobjects. Windows Forms controls take a more object-oriented approach. This difference affects the way you write code to add or find a subobject for a control. The challenge is to figure out the code that you need to write to achieve the same results in a Windows Forms control as are achieved in its ActiveX counterpart.

Let s take a look at adding child nodes to a TreeView control as an example. This example highlights the general differences between ActiveX and Windows Forms controls having rich object hierarchies, such as the ListView, ToolBar, StatusBar, and tabbed dialog controls.

The following is an example of code written to add a single parent and child node to a TreeView control. The code is associated with a Visual Basic 6 form containing a TreeView control and an ImageList control named TreeView1 and ImageList1, respectively. Assume that the ImageList control contains at least one image added at design time.

Set TreeView1.ImageList = ImageList1 TreeView1.Nodes.Add , , "Parent", "Parent node", 1 TreeView1.Nodes.Add 1, tvwChild, "Child", "Child node", 1

The ActiveX controls provided with Visual Basic 6 do not allow you to create a subobject directly. For example, you cannot dimension a variable of type Node using the New qualifier. Instead, you create a node indirectly by calling the Add method on the Nodes collection and passing in a number of arguments representing property settings for the newly created node. Because this type of object model directs you to specify the properties of the Node object rather than the Node object itself, it is a property-centered model for creating nodes.

To achieve the same result using the Windows Forms TreeView control, you must think in a more object-oriented fashion. In the object model used in Windows Forms, it is preferable to create Node objects and then add them to the Nodes collection. We should note that the Windows Forms TreeView control, and other Windows Forms controls for that matter, do allow you to create collection member objects in a property-centered way. For example, you can create a Node object by calling the Add method on the Nodes collection and passing the Text value for the node. However, the Add method on collections generally does not support a large number of arguments unlike collections related to ActiveX controls, where the arguments represent properties for the new item. You must get back into the object-oriented mindset and set the property values on the object after it is created.

The following code is the equivalent of the previous example; it adds a single parent and child node to a Windows Forms TreeView control:

Dim nodeChild As TreeNode = New TreeNode("Child node", 0, 0) Dim childNodes() As TreeNode = {nodeChild} Dim nodeParent As TreeNode = New TreeNode("Parent node", _    0, 0, childNodes) TreeView1.ImageList = ImageList1 TreeView1.Nodes.Add(nodeParent)

Compared to the ActiveX TreeView control, the Windows Forms TreeView control requires you to take a more structured, bottom-up approach to creating the nodes within the TreeView. In the Windows Forms version of TreeView, you cannot add individual nodes relative to other nodes in an ad hoc fashion. Instead, you must add the child nodes for a parent node at the time you add the parent node. You do this by passing in an array of TreeNode child objects as an argument to the TreeNode constructor for the parent node. As this code demonstrates, you add nodes in a bottom-up manner by first allocating the child nodes and then creating the parent node and passing it an array of its children. The code has a more object-oriented feel to it, as you construct the Node objects and then pass the objects as arguments to other methods such as Add to be added to the Nodes collection.

We intentionally used the ImageList control in this example to point out another difference between ActiveX controls and Windows Forms controls that use the rich object model. The ActiveX controls provided in Visual Basic 6 assume the value of 1 as the index for the first item in a collection. Windows Forms controls, on the other hand, always assume an index value of 0 for all collections. That is why the code for the ActiveX TreeView control passes a value of 1 as the index for the first image in the ImageList ListImages collection, whereas the Windows Forms code example uses 0.