Chapter 1

ActiveX Myths


My publisher told me it's not customary or appropriate for a chapter to be only a few pages long. But length is relative. This chapter may be short in terms of length, but it is equal in terms of importance to any of the longer chapters that follow.

Any time you begin to learn a new technology, it is important to start on the right track. Erroneous assumptions or early misconceptions can get in the way of understanding a technology and make it difficult to use correctly.

There are a number of myths relating to ActiveX technology that have become quite widespread. This is due in part to the rapid changes in technology we've seen recently. It is also due to the nature of Microsoft's marketing efforts, as you will see in the next chapter.

If you are one of those individuals who is relatively new to ActiveX and have not heard any of these myths, count yourself lucky, for you'll have fewer misconceptions to overcome. Don't worry if you don't fully understand some of the terms I use in this brief chapter; they'll all be explained in the chapters that follow.

Meanwhile, let us begin by laying some of these myths to rest, so we can begin our study of ActiveX with a clean slate.

MYTH:ActiveX is only important for Internet programming and Web sites.
FACT:ActiveX =/ Internet.

While there are certain specific aspects of ActiveX that relate to Internet programming, the vast majority of ActiveX technologies have nothing to do with the Internet.

Now, I realize that some of you reading this might be taken aback by this statement. You might point out that Microsoft created ActiveX controls to replace OLE controls. In doing so, however, you make my case-that early misconceptions can get in the way of understanding new technologies. You see, ActiveX controls did not replace OLE controls. ActiveX controls are OLE controls. No difference. None whatsoever. Why this is the case, and how it happened, will be covered in the next chapter.

MYTH:ActiveX is only for advanced VB programmers.
FACT:ActiveX should be one of the first things any new VB programmer learns.

There is a natural tendency to learn and teach Visual Basic in a sequence that roughly corresponds to the order in which features were added to the language. You can see this in many Visual Basic 4.0 books, where a discussion of classes appears, almost as an afterthought, at the end of the book after other language features are covered.

This is a terrible mistake.

The most important feature that appeared in Visual Basic 4.0 from a programming perspective was the class module. For the first time, Visual Basic was able to support object-oriented programming. True, VB was not (and is not) a true object-oriented language in the strictest definition of the term. But class modules make it possible for you to implement several key object-oriented features. The most important of these is the ability to hide information behind a clearly defined interface. In other words, the data in a class can be hidden from the rest of the program and access to that data limited to the functions you add to the class.

What does this have to do with beginning programmers?

Consider the steps many Visual Basic programmers use to create an application:

  1. Draw controls on a form (create the user interface).
  2. Start attaching code to various events.
  3. Place additional functions in the declaration section of forms or modules, depending on whether they are shared among forms or by programmer's whim. Define variables and otherwise write the program.

This is fine for trivial programs or "throwaway" code. But if this is the approach you use in general, I would like to invite you to consider another way:

  1. Think about the design of the application. Goals. Algorithms. User Interface. Data Structures. Schedules. Resources.
  2. Define the classes the application will use. Classes correspond to key data structures or areas of functionality. Classes may be made up of other classes. Remember to think of forms as a type of class as well! You may wish to go through the additional step of defining user interface components (ActiveX controls) with which to implement your application.
  3. Now go ahead and draw the form and implement the program.

Design always comes first. Taking the time to design your application is the single most important thing you can do to improve the quality of your code, reduce its size, increase its reliability, and accelerate its performance.

And implementing your application as a collection of classes will make your programs even better. Object-oriented programming is not a marketing buzzword that language vendors put into their ad copy to sell more software. (Well, it is, but that's beside the point.) Object-oriented programming is a design discipline and implementation methodology that will help you write better code. And it is something that should be learned by every Visual Basic programmer-even beginners.

What does this have to do with ActiveX? Simple. As you will see in Chapter 2 classes are ActiveX components. Since Visual Basic 4.0, VB was implemented internally using ActiveX technology.

MYTH:ActiveX is only important if you are creating servers or controls.
FACT:ActiveX is important to every VB programmer.

If ActiveX is the implementation technology for classes, and classes are the implementation technology for object-oriented programming, and object-oriented programming is important to all VB programmers, it follows naturally that ActiveX is important for all VB programmers. The case has already been made.

But allow me to expand slightly on this point. ActiveX is the fundamental technology for objects under Visual Basic, and this technology can be deployed in many different ways. Thus, during the design process for your application, you have two distinct issues to consider.

First, you must define the object model of your application. What are the objects and interfaces that will best implement your application? Second, you must determine how to deploy those objects. Which are public and which are private? Should an object be part of an application class, an in-process code component (DLL server), out-of-process code component (EXE server), ActiveX control (OLE control), or ActiveX document (DocObject)?

As a Visual Basic programmer, your technology options with Visual Basic 5.0 are far greater than those available under earlier versions. Learning about those options is what this book is about.

Let us begin.