User Interface Controls in Visual Basic 6 and Visual Basic 2005

Bill Sempf

January 2006

Applies to:
   Visual Basic 6
   Visual Basic 2005
   Visual Studio 2005

Summary: Convert Visual Basic 6 UI controls into Visual Basic 2005 easily and efficiently. (10 printed pages)

Contents

Introduction
Integrating User Controls
Working with ActiveX Controls and Windows Control Libraries
Upgrading OCXs, DLLs and Third Party Controls
Helping You to Move It Along

Introduction

In the world of conversion of Visual Basic 6 applications, little causes more concern than controls that just won't convert. Between in-project controls that you have the source code for, custom ActiveX controls that you bought back in 1997, and the built-in Microsoft controls that have no real conversion path, the task is not easy.

There is hope, however. Code in Visual Basic 6 user controls convert fairly well to Visual Basic 2005. You can use some third party controls via interop. Tools are provided in Visual Studio 2005 to assist with OCX proxy creation. All is not lost.

Integrating User Controls

The big problem is that Microsoft slightly adjusted what user controls are all about. Because of the use of Inheritance, we can actually define a User Control as a collection of controls that extends the idea of controls. In Visual Basic 6, the User Control was just a form that could be hosted inside another form.

Fortunately, Visual Basic 2005 does a fantastic job making the change. Much of it is under the covers, but even subtle settings are well covered by the Visual Basic 6 Upgrade Wizard. Let me show you what I mean.

Moving a Visual Basic 6 project with User Controls to Visual Basic 2005

I built a small user control in Visual Basic 6 that just implements three textboxes to allow for the entry of a US Social Security Number. I do a little bit of trickeration, setting a few of the settings to see how the conversion wizard does.

Figure 1. The Visual Basic 6 SSN control

I use the TextChanged event to automatically tab between the textboxes when they have the right number of characters. I hosted it in a simple form that just displayed the result in a messagebox, and ran it through the conversion wizard. This is a really straightforward process: just open the Visual Basic 6 project using the File -> Open Project… menu item in Visual Studio 2005.

I am pleased to say that Visual Basic 2005 handled it very, very well. The wizard correctly created the form and user control in Visual Basic 2005 format. There was even a ToolTip ExtenderProvider added for me, to support the ToolTip property that TextBox controls and instances of user controls have by default in Visual Basic 6.

Listing 1. Code comparison for the two versions

Visual Basic 6 Code

Private Sub Three_Change()
    If Len(Three.Text) = 3 Then
        Two.SetFocus
    End If
End Sub

Private Sub Two_Change()
    If Len(Two.Text) = 2 Then
        Four.SetFocus
    End If
End Sub

Public Property Get SocialSecurityNumber()
    SocialSecurityNumber = Three.Text & _
       "-" & Two.Text & "-" & Four.Text
End Property

Visual Basic 2005 Code

Option Strict Off
Option Explicit On
Friend Class UserControl1
  Inherits System.Windows.Forms.UserControl
   
  Private Sub Three_TextChanged(ByVal eventSender As _ 
    System.Object, ByVal eventArgs As System.EventArgs) _
    Handles Three.TextChanged

    If Len(Three.Text) = 3 Then
      Two.Focus()
    End If
  End Sub
   
  Private Sub Two_TextChanged(ByVal eventSender As _
    System.Object, ByVal eventArgs As System.EventArgs) _
    Handles Two.TextChanged

    If Len(Two.Text) = 2 Then
      Four.Focus()
    End If
  End Sub
   
  Public ReadOnly Property _
      SocialSecurityNumber() As Object
    Get
      SocialSecurityNumber = Three.Text & _
        "-" & Two.Text & "-" & Four.Text
    End Get
  End Property

Very little of code was altered at all, but I didn't do anything complex. After all, all we are doing here is checking to see if user controls convert, right? The only kicker that way was a global warning that stated that "UserControls need to be built after upgrading." That sort of makes sense, but I checked out the help file anyway.

Turns out, hosted controls were compiled in real time in Visual Basic 6 (remember having to close the window every time you hade a change?) and that isn't the case in Visual Basic 2005. Just build the solution once before you use it.

One thing that doesn't work is control arrays. You notice that I didn't use them in my example—even though it would be a great place to—and I wouldn't recommend it. When working with simple controls the one thing you can do to get yourself in a mess is to use a control array. Why? There is not complementary system in .NET. They removed the concept altogether.

ASP.NET: a Totally Different World

So it seems that if you have developed your own Visual Basic user controls, conversion should go well. I didn't test every part of the Visual Basic language as part of this example, but the control code itself seems to not cause too much in the way of problems.

The same can't be said for ASP.NET user controls. They are part of a whole different architecture, and are not handled by the Visual Basic 6 conversion wizard. In fact, there isn't really a corresponding feature in ASP3 to convert to ASP.NET, so that makes sense.

The concern that I hear most often is that of using a Windows server control in a web environment, though, like you can use some ActiveX controls in either a Visual Basic 6 or an ASP 3 environment. That really doesn't happen anymore. Since you can use ActiveX in ASP.NET like you did in ASP3, that option is still available. Windows controls don't run in ASP.NET, though, and ASP.NET controls don't run in Windows Forms applications.

Working with ActiveX Controls and Windows Control Libraries

Windows Control Libraries are class libraries that contain collections of controls in Visual Basic 2005. They are the closest thing to an ActiveX control destined for a Windows Form that Visual Basic 2005 has. The concept of an executable in a web form is something that you should try to get away from. Better is using ClickOnce and deploying a Windows Forms app.

In that line, when you convert an ActiveX control to Visual Basic 2005, you get a Windows Control library. This might come as a surprise to those of us who are used to Visual Basic expecting our ActiveX controls to be primarily for the Web. Fact is, an ActiveX control is just an executable that exposes certain properties in any container. The .NET Framework, with its inheritance model, is a little more controlling than that, so we have a Windows Control Library.

Moving an ActiveX User Control Project to Visual Basic 2005

The Social Security Number control that I built as a user control in the previous project was moved to an ActiveX control project, and run through the upgrade wizard. I am pleased to report that it went just as well as the previous example—this model works just fine. I got a .VB file that compiles into a Class Library.

Figure 2. The control in the toolbox

In fact, as you can see in Figure 2, Visual Studio was nice enough to add the control to other projects in the solution. It is drag and drop, just like the built-in controls!

Upgrading OCXs, DLLs and Third Party Controls

So you have a control that you bought in 1997, and the developer has moved to the third moon of Jupiter and the company has gone out of business. What now?

All is not lost. Because you lack the source code, you can't necessarily do a neat conversion like we did before. You can use the built in tools to automatically generate a .NET Proxy for a COM class—a more common experience than you might think—or do as we just did, and create a COM wrapper for that .NET control DLL.

Using a Visual Basic 6 Compiled Control in Visual Basic 2005

Sometimes you don't have access to the source. Sometimes you even find a normal Visual Basic 6 control that doesn't work in Visual Basic 2005. That's when you have to hope that you can create a Runtime Callable Wrapper.

The problem is that—like putting an old network card in a new machine—you really have no way of knowing if it will work until you try it. ActiveX controls implement older parts of the Win32 libraries to get things done, sometimes parts of the library that aren't even around in .NET or even in the operating system you are using.

If you are converting an application with older controls that runs currently on an older system, the very first thing to try is to install it on the newer system. Even if you are never planning on using the system in Visual Basic 6, you should give it a test if you want to reuse any of the controls. It will give you an idea of the compatibility problems you will have ahead of time.

The control I hear the most about is the Web Browser control from Visual Basic 6. However, there is a new WebBrowser control in Visual Basic 2005, and that solves that. In fact, there are a lot of new controls in Visual Basic 2005 that translate well to Visual Basic 6 controls that we all miss—most notably the SerialPort control, which takes over for mscomm. There are others on the design side as well:

• SoundPlayer
• DataGridView
• SplitContainer
• MaskedTextBox
• ToolStrip

In an effort to try and find a COM control that doesn't have a .NET assembly, I went for the ShockWave Flash control, which you will also have if you have Flash Web Player installed on your system. There is no .NET assembly for that yet, and I thought it would make a good upgrade example. The question is—will the upgrade wizard find a way to convert it?

Figure 3. the Flash Browser

I built a simple Visual Basic 6 application with the Shockwave Flash OCX control (complete with a client's slash page flash in Figure 4), a textbox and a button, and converted it in Visual Basic 2005.

As expected, the Visual Basic 6 Conversion wizard did a nice job converting the component and making a .NET Interop of the control. Ax was added to the Interop name to show that it is an ActiveX hosted control, which now derives from System.Windows.Forms. Here are the controls referenced by my project after conversion and cleanup:

• AxInterop.ShockwaveFlashObjects (copied locally)
• System (GACed)
• System.Drawing (GACed)
• System.Windows.Forms (GACed)

You can convert a control the same way the conversion wizard does using aximp. Aximp uses the System.Web.Forms.AxHost class as a proxy between the ActiveX control and the Windows Forms container. If you dig into the manifest of the new ShockwaveFlashObjects assembly, you can see that it does derive from AxHost.

.assembly AxInterop.ShockwaveFlashObjects
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::.ctor() 
  .custom instance void [System.Windows.Forms]System.Windows.Forms.AxHost/TypeLibraryTimeStampAttribute::.ctor(string) 
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::.ctor(int32)  .hash algorithm 0x00008004
  .ver 1:0:0:0
}

You can run aximp yourself with the command line:

aximp c:\Windows\System32\Macromed\Flash\flash.ocx

AxHost wraps ActiveX controls and exposes them as fully featured Windows Forms controls. It's not a class you use directly, but rather it is used by aximp to generate these proxys we are looking at. More or less, it is the Lego piece that translates the ActiveX interface to the Windows Forms interface.

If you check out the members, you can see that the properties are derived mostly from the Control class. The reason for the AxHost class at all is to touch the Win32 model, and translate the properties to .NET. Long Live Object Oriented Programming.

Helping You to Move It Along

No one believes that Visual Basic 6 is going away tomorrow. There are clients I have that still are running on a 100 percent Visual Basic 6 codebase. When you go to start to move things, it is nice to know that maybe—just maybe—you won't have to rewrite every line of code. Code can be converted, controls can be wrapped… in short, there is more than one way to get done what needs to be done.

The take home of all this? Take a minute to clean up your Visual Basic 6 code before conversion. A great tool to help with this is the Code Advisor for Visual Basic 6. The tool required Visual Basic 6 to be installed (remember you can have both Visual Basic 2005 and Visual Basic 6 installed on the same machine). It adds a simple taskbar to Visual Basic that comments your code to help you with upgrade tips.

Figure 4. The Code Advisor

The changes it makes to the code are simple, clear and manageable.

Listing 2. the Code Advisor marks up the Control Example

'FIXIT: Use Option Explicit to avoid implicitly creating variables of type Variant         FixIT90210ae-R383-H1984
Private Sub Three_Change()
    If Len(Three.Text) = 3 Then
        Two.SetFocus
    End If
End Sub

Private Sub Two_Change()
    If Len(Two.Text) = 2 Then
        Four.SetFocus
    End If
End Sub

'FIXIT: Declare 'SocialSecurityNumber' with an early-bound data type                       FixIT90210ae-R1672-R1B8ZE
Public Property Get SocialSecurityNumber()
    SocialSecurityNumber = Three.Text & _
       "-" & Two.Text & "-" & Four.Text
End Property

You can download the code advisor here.

Are there are other changes you might need to look outside the assistance of the Code advisor for? Well, is there anything that should have been moved to a user control years ago, that wasn't? It might be in your best interest to move it now. How about that third party control; is there a .NET version? If not, look into that aximp tool sooner rather than later. Planning is the key to any successful fusion of Visual Basic 6 and Visual Basic 2005—and it is just as true with user controls as it is with anything else.

© Microsoft Corporation. All rights reserved.