The Purpose of ActiveX

The Purpose of ActiveX

This chapter covers the theory and concepts of ActiveX, which is built on the
Component Object Model (COM). Until recently, the technology built on COM was
called OLE, and OLE still exists, but the emphasis now is on ActiveX. Most new
programmers have found OLE intimidating, and the switch to ActiveX is unlikely to
lessen that. However, if you think of ActiveX technology as a way to use code already
written and tested by someone else, and as a way to save yourself the trouble of
reinventing the wheel, you'll see why it's worth learning. Developer Studio and MFC
make ActiveX much easier to understand and implement by doing much of the
groundwork for you. There are four chapters in Part V, "Internet Programming," and
together they demonstrate what ActiveX has become. In addition, ActiveX controls,
which to many developers represent the way of the future, are discussed in Chapter 20,
"Building an Internet ActiveX Control," and Chapter 21, "The Active Template Library."

These are best read after Chapters 18 and 19.
Windows has always been an operating system that allows several applications running
at once, and right from the beginning, programmers wanted to have a way for those
applications to exchange information while running. The Clipboard was a marvelous
innovation, though, of course, the user had to do a lot of the work. DDE (Dynamic Data
Exchange) allowed applications to "talk" to each other but had some major limitations.
Then came OLE 1 (Object Linking and Embedding). Later there was OLE 2, and then
Microsoft just called it OLE, until it moved so far beyond its original roots that it was
renamed ActiveX.
NOTE: Experienced Windows users will probably be familiar with the
examples presented in the early part of this chapter. If you know what
ActiveX can do for users and are interested in why it works jump ahead to
the "Component Object Model" section, which looks under the hood a
little. n
ActiveX lets users and applications be document-centered, and this is probably the most
important thing about it. If a user wants to create an annual report, by choosing
ActiveX-enabled applications, the user stays focused on that annual report. Perhaps
parts of it are being done with Word and parts with Excel, but, to the user, these
applications are not really the point. This shift in focus is happening on many fronts and
corresponds to a more object-oriented way of thinking among many programmers. It seems
more natural now to share work among several different applications and arrange for
them to communicate than to write one huge application that can do everything.
Here's a simple test to see whether you are document centered or application centered:
How is your hard drive organized?
The directory structure in Figure 13.1 is application centered: The directories are named
for the applications that were used to create the documents they hold. All Word
documents are together, even though they might be for very different clients or
projects.
FIG. 13.1 An application-centered directory structure arranges documents by type.
The directory structure in Figure 13.2 is document centered: The directories are named
for the client or project involved. All the sales files are together, even though they
can be accessed with a variety of different applications.
FIG. 13.2 A document-centered directory structure arranges documents by meaning or content.
If you've been using desktop computers long enough, you remember when using a program

involved a program disk and a data disk. Perhaps you remember installing software that
demanded to know the data directory where you would keep all the files created with
that product. That was application-centered thinking, and it's fast being supplanted by
document- centered thinking.
Why? What's wrong with application-centered thinking? Well, where do you put the
documents that are used with two applications equally often? There was a time when
each product could read its own file formats and no others. But these days, the lines
between applications are blurring; a document created in one word processor can easily
be read into another, a spreadsheet file can be used as a database, and so on. If a client
sends you a WordPerfect document and you don't have WordPerfect, do you make a
\WORDPERFECT\DOCS directory to put it in, or add it to your \MSOFFICE\WORD\DOCS
directory? If you have your hard drive arranged in a more document-centered manner,
you can just put it in the directory for that client.
The Windows 95 interface, now incorporated into Windows NT as well, encourages
document-centered thinking by having users double-click documents to automatically
launch the applications that created them. This wasn't new - File Manager had that
capability for years - but it feels very different to double-click an icon that's just
sitting on the desktop than it does to start an application and then double-click an
entry in a list box. More and more it does not matter what application or applications
were involved in creating this document; you just want to see and change your data,
and you want to do that quickly and simply.
After you become document-centered, you see the appeal of compound documents--files
created with more than one application. If your report needs an illustration, you create
it in some graphic program and then stick it in with your text when it's done. If your
annual report needs a table, and you already have the numbers in a spreadsheet, you
don't retype them into the table feature of your word processor or even import them;
you incorporate them as a spreadsheet excerpt, right in the middle of your text. This
isn't earth-shatteringly new, of course. Early desktop publishing programs such as
Ventura pulled together text and graphics from a variety of sources into one complex
compound document. What's exciting is being able to do it simply, intuitively, and with so
many different applications.