ActiveX controls have replaced OCXs, which replaced VBXs

Since Visual Basic 4, Visual Basic has used OCXs rather than VBXs. The 16-bit version of Visual Basic 4 can use either, provided the controls are 16-bit. When you port a project to Visual Basic 5 or 32-bit version 4, you need to replace any VBXs with equivalent ActiveX controls. With the VBXs supplied by Microsoft, this is not a problem. However, with third-party OCXs, it may present a serious problem. Some vendors have taken the opportunity of rewriting their controls for the 32-bit world and ActiveX to redesign the way the controls work, and the new ActiveX control might not be completely compatible with the old VBX. Controls that are completely compatible with a preceding VBX add an entry to the VB.INI file and will port automatically.

When Visual Basic 4 came out, many third-party controls either were not available or were extremely unreliable. Those same controls can now be used with Visual Basic 5, but they have benefited from more than a year’s use. Most have been through several bug-fix releases. These controls are now far more stable than they were a year and a half ago.

Tip If you buy your controls from a distributor, particularly outside the United States, check to see that you have the latest release from the supplier’s Web site or CompuServe forum because the inventory held by distributors is often several versions behind.

There are at least four ways to deal with controls that do not upgrade automatically. You can probably use the method that involves the least amount of work for your project.

• You can simply import the project and then manually change the picture boxes that have replaced the controls that have not upgraded.

  Note If you load a file into Visual Basic that references a control with a class name not loaded into your current Visual Basic session, Visual Basic replaces the control with a PictureBox control that has the same dimensions as the original control, pops up an error message, and writes an entry into a file named formname.log.

• You can use a text editor to search the original Visual Basic code files, saved as text, for all occurrences of unsupported controls and replace them with the class names of controls that are upgradable.
  
  
• You can use 16-bit Visual Basic 4 as a staging post. Import your Visual Basic project, keeping the VBXs that cannot be upgraded. These VBXs can then, according to their functionality, be wrapped up in 16-bit ActiveX servers or replaced by cutting and pasting their code into their nearest OCX equivalents. For large projects with many forms, it may be worth writing a 16-bit Visual Basic 4 add-in to perform this largely mechanical function. It is relatively easy to write a program to iterate through all the controls on a form and replace them on a new form with an alternate control. While you’re replacing the control’s properties, design-time values can be remapped, and event code can be moved. The only procedure in this kind of process that requires any smoke-and-mirrors programming is navigating through the modules in a form. For this, it’s necessary to resort to the Visual Basic SendKeys function.

  Tip If Visual Basic 4 is the currently active application, using SendKeys to send Ctrl+V, Ctrl+R, Down Arrow, and Enter will make the second form in the project window the active form. This form can then be manipulated from the VBIDE’s properties and methods. This technique of using SendKeys to control applications is extremely unreliable, however, and you should use it only as a last resort.

• You can write your own ActiveX control that replicates the functionality you require. This may be a relatively straightforward exercise, or it may be a complete project in its own right. For example, writing your own masked edit control can be quite simple, while creating your own grid control may take a little longer.