Visual Basic Books

ActiveX controls are comparable to applets written in Java. An applet is any small program or utility, but of late, the term applet has come to mean a small application embedded in an HTML document that can be displayed by a Web browser. In fact, the Microsoft Java VM (virtual machine) exposes Java Bean components as ActiveX controls. The advantage to this is that applets can be thought of as ActiveX controls, which in turn means that they can be scripted using ActiveX Scripting languages such as VBScript or JScript.

Despite all the racket I made in previous pages about true programmers being felled by Visual Basic interlopers, creating an ActiveX control is (fortunately) difficult, even in Visual Basic. Controls are definitely one of the most complex project types to develop—so much so, that even experienced Visual Basic developers might have a hard time grasping the essence of creating ActiveX controls. Part of this complexity stems from the fact that controls are very different creatures from other types of software that you can build with Visual Basic.

For starters, having two personalities is beneficial when you are engaged in creating ActiveX controls in Visual Basic. ActiveX controls (and their developers) basically have two separate personalities. You are a Dr. Jekyll when you are developing a control in Visual Basic, sacrificing yourself on the altar of science. The developer using your component, however, sees you as a Mr. Hyde: a ruthless, self-serving murderer of innocent code. Once you comprehend both facets of working with an ActiveX control, developing an ActiveX control in Visual Basic will be much easier.

Let’s leave nineteenth-century literature and return to contemporary software. Think of a Standard EXE project. You develop the program in design mode and then test the program in run mode. Once you have the program working, you create an EXE file that always executes in run mode. Controls, likewise, are developed in design mode and are tested in run mode. However, since controls never run as stand-alone applications, you always need a test container in which to execute the control. The oddity is that once you have developed a control, produced an .OCX file1, and given it to other developers to use in their software, the control is back to working in Visual Basic’s design mode. This is the peculiar fact about the life of a control: even when Visual Basic is in design mode, controls are running.