Migrating Applications to Visual Basic 5.0

Valor Whisler
Senior Engineer, Crescent Division of Progress Software

February 21, 1997

Valor Whisler is a senior engineer for Crescent, a leader in the business of developing components and tools for Visual Basic. He has a lead role in helping Crescent deliver high quality, innovative, and useful products.

Abstract

Microsoft® Visual Basic® version 5.0 offers many new features and functions that make it worthwhile to move your applications to this platform. Of course, the most compelling reason for migration may be the fact that this latest version of Visual Basic creates native code executables—resulting in impressive performance gains over previous versions. In addition, the ability to create ActiveX™ controls and ActiveDocs, as well as other features, is well worth the migration from Visual Basic 3.0 or Visual Basic 4.0. This article will consider and discuss the following topics about migrating your existing Visual Basic 3.0 and 4.0 applications. Then, it will explain how to accelerate and ease that process using the Migration Wizard that ships with Visual Basic 5.0.

• Issues to consider
  
  
• Notable changes to Visual Basic
  
  
• Types of change
  
  
• Plan of attack
  
  
• Migration Wizard

Issues to Consider

What are the issues to consider prior to migration? Most of the issues listed here are not specific to migrations of Visual Basic projects—rather, they are issues to consider when migrating to any type of software system.

• Deployment platforms—Visual Basic 5.0 is 32-bit only. This means that it can only run on Microsoft Windows® 95 or Windows NT®. As much as we developers would like to see 16-bit systems disappear, you must consider whether your target customer is 32-bit enabled or not. Now with ActiveDocs, ActiveX controls, and substantial performance gains, you have real ammunition/reason to migrate.
  
  
• Scale of the change—What is the size of the project that you intend to migrate?  If your project is small it may be possible to proceed with the change using a less formal set of management guidelines than you would normally use when developing a new project. Conversely, if your project is large it is probably appropriate to manage this migration as you would any new software project. This might include existing system designs being modified, along with revised strategies for project management, version control, configuration management, and quality assurance.
  
  
• Scope of the change—What is the scope of the change you intend to undertake?  Do you plan to make a complete change, a partial change, or a set of phased changes?  The same issues apply here as were discussed in the preceding section. The scope of the change may also involve some redesign and re-engineering of your application to take advantage of new features, for example, the new asynchronous processing capabilities of RDO.
  
  
• Impact and risk analysis—The word “analysis” brings up connotations of some formal process that takes a long time and the word “risk” implies concerns about proceeding. Risk analysis means understanding the potential issues and planning around them. I am not advocating a formal process, but am suggesting that you must consider the impact and risks of the change. Consider such points as whether you have the expertise to make the change and the resources to make the change. Other key impact and risk considerations are cost, schedules, interoperability, installed base, data consistency, version incompatibilities, software deployment, and component dependencies. Remember that the larger the scale or scope of the change, the greater the impact and risk.
  
  
• Configuration management and version control—I believe any migration should involve some type of versioning of the product. This means you will have to establish all of the processes and procedures required for a product version.
  
  
• Unit and integration testing—If the scope or scale of your change is small, you may be able to use test plans that were constructed for the original version. On the other hand, large-scale changes or changes that affect the entire application probably call for your test plans to be revisited. The other critical area to consider with migrations or new software versions is the installed base. Remember that changes to component interfaces, databases, or data structures require consideration of how the installed base will be affected and updated.
  
  
• Synchronizing with vendor controls—Many systems have dependencies to vendor controls. Consider the availability and compatibility of new versions of these vendor controls when planning your migration. Some of the biggest performance benefits are associated with controls, so you want to make sure your performance gains from the migration.

Notable Changes to Visual Basic

This section provides a short list of changes to Visual Basic. This is by no means a complete list and only those changes that affect migration are discussed. Before I discuss some of these specific changes, I wanted to mention what I feel is the most significant change of all—the new approach to problem solving that was introduced in Visual Basic 4.0. The new architecture of Visual Basic 4.0 made possible the use of class modules and forms-as-objects as well as a major shift toward OOP. Fortunately, this same architecture is present in Visual Basic 5.0 along with the obligatory extensions and enhancements. This object-oriented shift in thinking really invites a change in the design of your Visual Basic 3.0 applications. Although it is not mandatory, undertaking this task can result in huge gains, such as modularization, which allows components to be reused. That aside, it is possible to merely migrate a Visual Basic 3.0 application directly to Visual Basic 5.0 without a redesign. And, as mentioned, the migration from Visual Basic 4.0 to Visual Basic 5.0 is much easier since the fundamental development process did not change.

• New data types—Object, Byte, Variant Decimal, other. You may want to take advantage of the new data types to improve your existing application. Changes of this nature are not required but may affect performance, readability, and maintainability.
  
  
• New language constructs—For … Each, With … End With. Again, these new constructs can improve your existing application’s performance, readability, and maintainability.
  
  
• Class modules and forms as objects—This powerful set of capabilities introduced in Visual Basic 4.0 can cause a rethinking of the design of your software. These are by no means straightforward changes and may require significant redesigns.
  
  
• “Public” supersedes “global”—The changing of this keyword is basically cosmetic, but may enhance readability in the long run. There are many other cosmetic, or style, changes that you may want to make as you move your code base forward.
  
  
• Conditional compiles for dual OS support—Conditional statements of this type used in Visual Basic 4.0 are no longer needed, as Visual Basic 5.0 is 32-bit only. Removal of this “dead” code will reduce clutter.
  
  
• “Enum” allows enumeration of constants—This Visual Basic 5.0 capability may enhance code organization and readability.
  
  
• Optional arguments need not be variant—Changing optional arguments to non-variants can affect the size of .exe files, as the size of a variant is larger than many other data types. You can also remove any IsMissing functions necessary to test for the presence of variants.
  
  
• “AddressOf” operator allows callbacks—This built-in operation can be used to replace work-arounds that involve the use of third-party controls.

Types of Change

There are several types of change to consider prior to your migration. Some changes are mandatory—that is, they must be done in order for your application to work in the new environment. Other changes are more to do with style or are cosmetic in nature. Some changes you make can increase coding efficiency or optimize your logic. Finally there are changes to the interface necessitated as older controls are phased out or newer controls with more functionality become available.

• Mandatory changes—These changes tend to be mechanical in nature: change this to that. An example of a mandatory change is changing Windows API declaration and usage from 16- to 32-bit. Information about API declarations can be found in the \WinAPI directory installed with Visual Basic and Daniel Appleman’s book Visual Basic 5.0 Programmer's Guide to the Win32 API (Ziff Davis Press, 1997).
  
  
• Style—These changes are cosmetic in nature but may affect readability and maintainability of code. An example: the use of the keyword “public” in favor of “global.” Another example: newer versions of Visual Basic support control and reference TypeLibs with large numbers of built-in constant names—these can be used to replace constants that were previously declared in code, such as CheckBox.Value = vbChecked. Remember that every declared constant you replace in this way does two things: reduces the .exe size and assures naming consistency.
  
  
• Increased efficiency/optimization—One of the most significant, but difficult, types of change you can undertake is to change the way you solve the problem. This involves the use of class modules, forms as objects, and general encapsulation to reduce globals. In addition, use of the new constructs such as For…Each and With…End With can result in faster code execution. Other examples include the use of built-in functions in favor of home grown ones: the new StartUpPosition property for forms can replace functions that had been written to center forms. Every line of code that can be removed means gains in .exe size and speed.
  
  
• Interface—Many new controls have entered the market, many base controls now have features that previously required a third-party control, and some controls do not exist in ActiveX. A number of controls are being phased out by Microsoft and, one would expect, by control vendors. As this happens, they must be replaced. In addition, newer breeds of controls can be used to enhance interfaces. For example, replace the use of the Outline control with a TreeView control.

Plan of Attack

As mentioned earlier, it may be necessary to consider a migration as a full-blown versioning of the product. This, of course, depends on the scale and the scope of the change. This should go without saying, but make sure you back up your old project!

• Make mandatory changes first—Changes of this type must occur and also tend to be mechanical in nature. Make all of these changes, such as changing Windows API declarations and calls, first. Check in the project. Now proceed with style and optimization changes.
  
  
• Multiple sweeps—I like to focus on one area of change and “sweep” through the whole project with that change in mind. I do this by proceeding through all of the project components as they are listed in the project explorer, from top-to-bottom.
  
  
• Incremental check-ins—Make sure that you are incrementally checking in your project as you progress with your changes. I occasionally find that when I am undertaking a particularly involved change I get to a point where I have lost confidence in that change. At that point I fall back to the version that was previously checked in.
  
  
• Don’t replace all—I don’t recommend using the Replace All button on the Replace dialog unless you are really, really sure of the consequences.

The Migration Wizard

Crescent Migration Wizard

A Migration Wizard developed by the Crescent Division of Progress Software is included in Visual Basic 5.0. It can be found in the directory \Tools\Unsupprt\Migrwiz. This tool provides a wizard-style interface that walks you through the process of migrating an earlier-version Visual Basic project to Visual Basic 5.0.

The Migration Wizard processes source files from a Visual Basic application, searching for Windows API Declare and Call statements, as well as declares and calls to third party DLLs. The Wizard performs one of two operations when it encounters an API or DLL function: it inserts a TODO: comment at the offending location, telling you what must be done to upgrade, or it changes the code automatically.

The wizard provides for the selection of a Visual Basic project and specification of a new directory where the modified source will be generated—it does not directly modify the original project. There are several options provided, including the following:

• Provide a report of changes that are necessary or have the wizard perform the changes.
  
  
• Produce a summarized or detailed report.
  
  
• Convert 16-bit Win API and ODBC to 32-bit and optionally comment out the 16-bit declares or just mark the code with a TODO statement.
  
  
• Highlight third-party and DAO declares and calls with TODO statements.
  
  
• Highlight potential optimization areas with TODO statements.

After all of the options have been selected in the wizard, the source files are then processed according to your specifications. This versatile tool can not only perform migrations itself, but can be used to learn what types of things to look for during a migration by reviewing the comments it generates.