Using ActiveX Controls with Windows Forms in Visual Studio .NET

Article
04/30/2007

Craig Utley
CIO Briefings

November 2001

Summary: This document examines how to use Microsoft ActiveX controls with Windows Forms in Microsoft Visual Studio .NET. (11 printed pages)

Objectives

ActiveX controls and Windows Forms controls defined
How ActiveX controls work in Windows Forms
Learn to upgrade projects with ActiveX controls

Assumptions

The following should be true for you to get the most out of this document:

You understand what ActiveX control are
You have built Windows Forms using Visual Basic 6.0 and ActiveX controls
You have both Visual Basic 6.0 and Visual Basic .NET on the same machine (don't worry; they do coexist well on the same machine)

ActiveX Controls and Windows Forms Controls
Using ActiveX Controls on Windows Forms
Upgrading Projects Containing ActiveX Controls
Summary

ActiveX Controls and Windows Forms Controls

With the release of Microsoft® Visual Studio® .NET, Microsoft introduces new technology for building Microsoft Windows® applications. One piece of this new technology is a new forms package called Windows Forms, which is shared by all the languages that run on the Microsoft .NET run time. Windows Forms are different from the forms that Microsoft Visual Basic® developers are used to using, although they may appear to be the same at first glance. This document will explore these changes.

Along with the new Windows Forms engine comes a new set of controls. These controls are not based on Microsoft ActiveX® as they were in previous versions of Visual Basic. Instead, these controls are built using the Microsoft .NET Framework and the System.Windows.Forms.Control class.

If you have written Visual Basic applications containing any sort of user interface, it is almost guaranteed that you have some ActiveX controls on your forms. If you are going to move your existing applications from Visual Basic to Visual Basic .NET, you may be curious about what will happen to your ActiveX controls. In addition, you will be curious about how to handle those controls that do not have equivalent Windows Forms controls.

This document examines how to use ActiveX controls with Windows Forms. Not all ActiveX controls can be used with Windows Forms. ActiveX controls placed on Windows Forms automatically gain new properties that are common to Windows Form controls, as you will see. And you will explore how the upgrade process affects ActiveX controls.

What Makes Windows Forms Controls Different

Most likely, you've been using ActiveX controls for a number of years. ActiveX controls are built on COM, which has been limited to the Windows platform. Windows Form controls are part of the .NET Framework, and you might be tempted to think that, if the .NET Framework was ported to another operating system, the Windows Form controls would be available as well. This is not the case, because Windows Forms rely heavily on the Win32 API. They are, after all, forms designed to take full advantage of the Windows platform.

Windows Form controls have certain features that were not available in the Visual Basic 6.0 form engine, including Dock and Anchor. These new properties are available to just about any Windows Forms controls, just as the Top and Left properties were available to almost any ActiveX control that was visible.

Windows Forms controls are objects, just as ActiveX controls were objects in Visual Basic 6.0. Now, thanks to the inheritance provided by the .NET Framework, it is possible to truly inherit from these controls in any language supporting .NET, including Visual Basic .NET. This means that you can truly subclass controls in ways that weren't possible before. In fact, if you design your own controls, it is likely that you will inherit from System.Windows.Forms.Control in order to gain the base services provided by this class.

Using ActiveX Controls on Windows Forms

The good news is that most ActiveX controls can be used with Windows Forms without any problem. To see this in action, open Visual Studio .NET and create a new Windows Application named AxTest1 in Visual Basic .NET.

Once the project is open, a form named Form1 will be automatically loaded into the Windows Forms Designer. Hovering the cursor over the Toolbox tab to the left opens the Toolbox, revealing a host of Windows Forms controls. These are not ActiveX controls, of course, so you'll need to add your own ActiveX controls to the Toolbox. In the Toolbox, right-click and choose Customize Toolbox to open the Customize Toolbox dialog box as shown in Figure 1.

Figure 1. The Customize Toolbox window is how you add ActiveX controls to the Toolbox

For the purpose of this example, include a control that came with Visual Basic 6.0. There is a Windows Form control that replaces it, but it is ideal to use something that you already have on your machines as a test case. Scroll down and select Microsoft DBList Control, version 6.0, as shown in Figure 1. Click OK.

The DBList control is now added to the Toolbox, as shown in Figure 2. Notice that there is no indication in the Toolbox that this is an ActiveX control. The control can now be added to a form, just as in Visual Basic 6.0.

Figure 2. The ActiveX Control DBList has been added to the Toolbox

Add the control to the form by either double-clicking it or dragging it to the form. Once the control is on the form, you'll notice several things about it that are different from what you would have seen in Visual Basic 6.0.

First, the name is different. Had you added the control to a Visual Basic 6.0 form, the name would have been DBList1. In Visual Basic .NET, the name given to the control is AxDBList1. Visual Basic .NET places the "Ax" prefix before any ActiveX control you add to a Windows Forms. This is a quick way to spot ActiveX controls.

Next, take a look at the Properties window and examine the properties for AxDBList1. There are a number of differences in the properties shown for this control from Visual Basic 6.0 to Visual Basic .NET. Although not an exhaustive list, here are some of the properties that appear in Visual Basic .NET that do not appear for the same control in Visual Basic 6.0:

Accessible Description
Accessible Name
Anchor
Dock

There are some properties that are missing, as well. DragIcon and DragMode are not found in the properties shown in Visual Basic .NET, because drag-and-drop works quite differently with Windows Forms. You'll also notice that the Custom property is not shown in Visual Basic .NET. In order to open a control's custom property sheets, you need to click on the ActiveX – Properties link under the Properties list, as shown circled in Figure 3.

Figure 3. Access the ActiveX control custom property pages by clicking the ActiveX - Properties link

Using the New Properties

As you saw in the list above, it appears that your control has some new properties. For example, you now have Anchor and Dock properties, which you didn't have in Visual Basic 6.0. How did these properties get added, when they are not part of the ActiveX control?

ActiveX controls had common properties, known as extender properties, such as Left, Right, Visible, and so forth. The Windows Forms engine replaces the ActiveX extender properties with its own set of properties. This is accomplished by creating a Windows Forms wrapper for each ActiveX control. This wrapper combines the ActiveX extender properties with the new Windows Forms properties.

Windows Forms have both extender properties and inherited properties. Some of the new properties, such as Dock and Anchor, are actually inherited from the base System.Windows.Forms.Control class. Extender properties are provided by the host, not the base class. An example of a Windows Form extender property is the ToolTip property, which you only see if you add a ToolTipProvider control.

If this seems complicated, the good news is that things look pretty transparent to you as a developer. As has already been mentioned, to pull up property pages, you only have to click the link at the bottom of the property list. Otherwise, the properties appear in the Properties window, and you use them regardless of whether or not they were originally ActiveX extender properties or Windows Forms extender properties or inherited properties.

Take a look at the Dock property. This is a property that was not available to the DBList control in Visual Basic 6.0. If you click the down arrow for the Dock property, you get a small window that drops down and allows you to choose where your control should dock. In Figure 4, the developer has chosen to dock the control to the right-hand side of the form. After doing this, when you run the application, AxDBList1 will be docked to the right-hand side of the form. The control will automatically resize and move as the form is resized. This is a tremendous timesaver because you do not have to write all that code yourself. Figure 5 shows how the control will automatically resize and stay docked as the form size changes.

Figure 4. Windows Forms makes new properties, such as the Dock property, available to ActiveX controls

Figure 5. Using the Dock property, an ActiveX control automatically grows or shrinks and stays locked to the area of the screen to which you dock it

ActiveX Controls That Do Not Work in Windows Forms

The good news is that most ActiveX controls work just fine in Windows Forms. Most doesn't mean all. Some of the controls that don't work on Windows Forms are some of the ones that appear to be so basic in Visual Basic 6.0: the Line and Shape controls, for instance. Visual Basic 6.0 let you have such controls, called "windowless" controls. Visual Basic .NET does not let you have any windowless controls, and it makes windowless controls windowed. The process of making normally windowless controls windowed can lead to unexpected results, however. Due to this, the Line and Shape controls are gone. The best solution for the absent Line control is to use the GDI+ library, or to use a label with the Height property set to a value of 1 pixel and the BorderStyle property set to FixedSingle. As an alternative to the Shape control, you can use the GDI+ library.

Other ActiveX controls that don't work in Windows Forms include the UpDown control, the ssTab control, and the Coolbar. The UpDown control (included with Microsoft Windows Common Controls – 2) can't be used because the scrollbar in it can't link to the "buddy" control (the text box). The ssTab control (Microsoft Tabbed Dialog Control) can't be used because it cannot contain other ActiveX or Windows Forms controls on a Windows Forms. Don't fear when you read that these ActiveX controls don't work in .NET; most of them have replacement controls native to Windows Forms, such as the TabControl.

Use of the Line, Shape, ssTab, UpDown, or other controls that can't be used on Windows Forms causes problems when upgrading a project from Visual Basic 6.0 to Visual Basic .NET. You'll examine these upgrade issues in the next section.

Upgrading Projects Containing ActiveX Controls

Given the large number of existing Visual Basic 6.0 projects, it is inevitable that many people will want to migrate their Visual Basic 6.0 applications to Visual Basic .NET. The good news is that Visual Basic .NET includes an Upgrade Wizard to help you make this move. Although the Upgrade Wizard is quite good, it is just one step in the process. Let's see what happens when you use the Upgrade Wizard to upgrade applications that contain ActiveX controls.

By default, the Upgrade Wizard attempts to upgrade any ActiveX controls to equivalent Windows Forms controls. To see this, let's create a simple project and upgrade it.

Upgrading a Simple Visual Basic 6.0 Application

In Visual Basic 6.0, create a new Standard exe. On the form, add a label, a text box, and a button. Draw a line on the form. Then, add a Shape control and change its properties to make it a solid circle. What the form actually looks like isn't that important. You can see an example in Figure 6.

Figure 6. A simple Visual Basic 6.0 application about to be upgraded

Save the project as SimpleUpgrade.vbp, and then open Visual Basic .NET. In Visual Basic .NET, open a project. In the Open Project dialog, navigate to the directory where you saved SimpleUpgrade.vbp. You'll need to change the drop-down list box Files to Visual Basic Project Files in order to see a .vbp file. Open SimpleUpgrade.vbp in Visual Basic .NET to automatically start the Visual Basic Upgrade Wizard.

In the Upgrade Wizard, leave all the defaults as they are, except perhaps the Project Name (step 3 of the wizard). After the upgrade is complete, examine the resulting project.

If you look in the Solution Explorer window, you'll see a file called _UpgradeReport.htm. If you double-click this file, you'll see that there were two errors during the upgrade. Neither the Shape control nor the Shape1.Shape property were upgraded. Earlier, you read that the Shape and Line commands were both gone from Visual Basic .NET, but you have not received an error regarding the Line. To see why, double-click the form to open it in the Designer.

You'll notice that the form looks similar to what you had in Visual Basic 6.0, but the circle you had is now a rectangle, as shown in Figure 7. The Line looks the same, but if you click it once, you'll discover that it isn't really a line at all. After clicking the line, look at the Properties window; you'll notice that the name of the Line control may be Line1 but the control is actually a label. Technically, it's a System.Windows.Forms.Label. It's just that the Height property of the label has been set to 1 pixel and the BorderStyle property set to FixedSingle. In addition, the yellow rectangle where the Shape control used to be is also a Label. If you examine the button or text box, you'll see that they both come from the System.Windows.Forms class, which means that they have been upgraded to Windows Forms controls.

Figure 7. The simple Visual Basic 6.0 form after upgrading in Visual Basic .NET

Upgrading a More Complex Visual Basic 6.0 Application

Go back to Visual Basic 6.0 and create a new Standard exe. Add a label, and then add a single text box. Copy and paste the text box, and click Yes to create a control array. The form now has one label and two text boxes, but the text boxes are part of a control array.

On the Label, change the DragMode property to 1 – Automatic and then double-click the text box Text1(0) to bring up a code window. Modify the Text1(0) DragDrop event handler to appear as shown:

Private Sub Text1_DragDrop(Index As Integer, _
   Source As Control, X As Single, Y As Single)
    Text1(0).Text = Label1.Caption
End Sub

This code will change the Text1(0).Text to whatever is in the label if you drag Label1 and drop it on Text1(0).

Next, select the Change event procedure from the procedure drop-down box in the code window. Add the following code to this event procedure:

Private Sub Text1_Change(Index As Integer)
    Text1(1).Text = Now
End Sub

By adding the line of code to the Change event procedure of the text box Text1, whenever the data in the Text property changes in this text box, the Change event fires. By dragging the label control onto either text box, the caption in the label will be placed into the Text1(0).Text property. At the same time, the Change event fires because the Text1(0).Text property just changed. The code within the Change event will now fire, which will fill in the current date and time into the Text1(1).Text property.

Save the project as MoreComplexUpgrade.vbp and open Visual Basic .NET. Upgrade the project, and examine the _UpgradeReport.htm file. You will receive one error and one warning, as shown in Figure 8.

Figure 8. The errors encountered when upgrading drag-and-drop events

As you can see, Visual Basic .NET had a hard time upgrading the drag-and-drop parts of the application.

If you look at the form, you'll notice several other differences between the Visual Basic 6.0 form and the Visual Basic .NET form. In the component tray (the small window below the form) you'll see two controls: Text1 and ToolTip1. Visual Basic .NET doesn't handle control arrays the way Visual Basic 6.0 does, so it creates a control in the component tray of type Microsoft.VisualBasic.Compatibility.Visual Basic 6.0.TextBoxArray. The compatibility layer is there to help make moving from Visual Basic to Visual Basic .NET smoother. Avoid using it if you can, because it is slower to go through the compatibility layer than it is to use native Windows Forms controls.

ToolTip1 is shown in the component tray because Windows Forms controls do not have the ToolTip property but instead use an extensible property extender architecture. This is an added control that gives all the controls tooltips if desired. Another examples of extender providers is the HelpProvider which adds help-related properties to controls.

If you examine the names of the TextBoxes, you'll notice that the names have changed. The first is now called Text1_0 and the second is called Text1_1. Control arrays in Visual Basic .NET are handled using different object names and therefore, different methods.

Summary

You have now examined how to use ActiveX controls in your Windows Forms applications. The good news is that most work just fine. Some Visual Basic controls do not work, for a variety of reasons. It is always better to use Windows Forms controls whenever possible, to avoid any confusion. Keep these points in mind:

Control arrays are handled through different control names and methods in the code.
ActiveX control custom property pages are accessed via a link below the Properties list.
ActiveX controls automatically gain Windows Forms controls properties, such as Anchor and Dock.
Controls such as Line and Shape will upgrade to the Label control in Visual Basic .NET.
Drag-and-drop operations work much differently in Visual Basic .NET, and the code for this is not upgraded for you. If you use a lot of drag-and-drop, you'll end up modifying it by hand after the upgrade.

About the Author

Craig Utley is President of CIOBriefings LLC, a consulting and training company focused on Microsoft development. He has been working with and writing about .NET since it was first announced. Recently, Craig has been writing about .NET for Sams Publishing and Volant Training.

About Informant Communications Group

Informant Communications Group, Inc. (www.informant.com) is a diversified media company focused on the information technology sector. Specializing in software development publications, conferences, catalog publishing and Web sites, ICG was founded in 1990. With offices in the United States and the United Kingdom, ICG has served as a respected media and marketing content integrator, satisfying the burgeoning appetite of IT professionals for quality technical information.

Technical editing: PDSA, Inc.