Previous Page TOC Next Page


5 — ActiveX Documents

by Warren Ernst

When it comes to using a file format for creating information to be distributed and viewed on the Internet, nothing is as popular as HTML (Hypertext Markup Language). Combining both information formatting and linking in the same file, HTML transformed the way most people use and think about the Internet. Before HTML, searching for information required in-depth knowledge of different file formats, communication protocols, and the programs that used them—and keeping track of them all could easily be a full-time job (and was). Today, after the rise of HTML, Internet users no longer need to worry about the formats, protocols, and dozen programs previously needed to work effectively online; instead, Web browsers such as Netscape and Internet Explorer combine retrieving information stored in different Internet servers with file viewing. As long as the information you need on the Net is converted into HTML, Web browsers are all you need to get online information.

Although the near-universal acceptance of HTML as the online information format has opened many doors and broadened the nature of the Internet, it really isn't a perfect solution for all types of information. For example, sounds, graphic images (both two- and three-dimensional), and animation sequences, obviously, can't be represented with HTML. "Live" information—such as video feeds, real-time statistical data, running stock quotes—is tricky too, requiring modules embedded within HTML files (such as ActiveX controls or Java applets) and new Web browsers with new capabilities that enable it to accept and run these modules, or "Helper Applications" that run outside the Web browser itself. If you use several Helper Applications for these new file formats, you're right back where you were before the Web—lots of different programs and formats.

Desktop applications that aren't "wired to the Internet" have also had this historical problem of dealing with different file formats for different jobs; they've handled the problem with varying degrees of success. File format converters, importers and exporters, and copying and pasting have all resulted as viable methods for combining information best suited for different file formats into one "document." However, the most flexible and innovative method by far is Object Linking and Embedding, or OLE. With OLE, you can easily transfer information from one file format to another and edit it in the master file by using the original format's properties and tools, within a single window. It works, however, only if you have OLE-enabled programs and they are all installed on your computer.

ActiveX documents combine the best elements of OLE information sharing and the connectivity of Web browsers, allowing non-HTML formats to zip around the Internet and be viewed and manipulated with Web browsers, because these files transfer their properties and tools along "for the ride," so to speak. This chapter discusses how non-HTML files can call tools from across the Internet to let you work with them within Web browsers, shows how you can write applications that work within Web browsers and other programs, and illustrates how ActiveX documents are doing this today.

The Problems of New Information and New File Formats

Much of the information on the Internet is now stored in HTML, even if that information isn't especially well suited for the HTML format. Of course, video and audio information can't be stored in HTML. Although this wasn't much cause for concern two years ago when text and still-graphics images were almost all that was available on the Internet, it's a problem now. With the availability of 28.8 modems, personal video cameras and microphones, and live information feeds from scientific equipment or the stock market, HTML has shown its limitations. Despite these new types of information, however, developers and information sources still cling to the HTML format for a simple reason—it's practically guaranteed that the widest Internet audience possible can view the information.

This means that if you are a software developer and you want the information your program generates to be usable for the widest segment of the current Internet-using public, your program must do one of the following:

This, of course, would be the ideal solution:

The positives and negatives of the first four common options are discussed in the following section, but the fifth option, where ActiveX documents come in, is explained in the "ActiveX Documents: The Best of All Worlds" section. By reviewing the positive and negative qualities of the more conventional options first, you can more clearly see the advantages of using ActiveX documents over the Internet for your programs.

HTML for Everything

If your new program generates data you want available widely online, you could make sure your program can import and export HTML files in addition to your preferred, native format. This isn't a terrible solution if your program generates static, text-based data or generates data easily saved in a commonly embedded file format for Web pages, but there are some obvious drawbacks. The biggest one is that there must always be two files containing the same information at any given time—one for the local users of your program, and one for the online users. Since there are two files with the same data, the information might get "out of sync" because of a file-naming or other simple error, with the result that online users get one set of information and native users get another. Clearly, this is an unacceptable prospect.

Of course, if your information is completely text-based and static, you can probably minimize the potential for lack of synchronization to a comfortable level, but not all information is well suited for HTML. Complex, multipage documents don't necessarily translate well to HTML, especially if they were precisely typeset or required exact coloring.

Real-time data streams from instruments don't translate well into HTML, either. NASA's Jet Propulsion Labs (JPL) recently distributed real-time data of the Galileo space probe's Jupiter orbit insertion on the Internet by using HTML, but Web server problems prevented many people from getting the information. JPL had their programs generate a GIF file embedded in an HTML file every 60 seconds, and online users had to click their browser's Reload button every minute to get updated spacecraft readings. Unfortunately, with several thousand people clicking their Reload buttons every minute, the Web server overloaded—preventing anyone from getting data for a while.

Clearly, in some situations the wide acceptance of HTML can't offset the inherent limitation of the format. In these cases, another option is needed.

Make Your Program a Helper Application

If you've concluded that your information just can't survive a translation into HTML, then the simplest way to ensure that online users can read your data is to make sure your program can accept a call from a Web browser to display data retrieved online. This requires nothing more from a program's developer than a command-line parameter that automatically launches the program as a Helper Application and loads the specified file, something along the lines of a Web browser launching a program stored on the local hard drive with the command c:\programs\abcviewer.exe file.abc.

For example, Adobe Acrobat files can't be read directly by Web browsers, so one option for using them online is to install the Acrobat Reader standalone application, and then tell your Web browser where the application is located on the local hard drive. Once the Web browser knows about this "Helper Application," it will automatically launch it and load the file into it once the data transfer finishes. The online user can then read the data with this external program and quit the program when finished. In the case of Adobe Acrobat PDF files, a Web browser downloads the PDF file (which might contain an electronic "newspaper"), determines what file type it is, and launches the corresponding Helper Application: Adobe Acrobat Reader. Once the file transfer is through, it's sent to the Helper Application for use. This process is illustrated in Figure 5.1.


Figure 5.1. Once started, a Helper Application runs completely independently of the Web browser and might sport an entirely different user interface as well.

This is certainly simple for the programmer, but it puts an extra burden on users, who must first separately download your program and then install it themselves. If it needs to be configured, users must do this, as well. Once the program is set up, users must then tell their browser where the application is located on the hard drive and what file types it can actually use. Only then will the non-HTML file load automatically, but users must still deal with additional program windows and perhaps a different user-interface.

Also, there is never any way for the programmer or Web page writer to be certain that the online user actually has the Helper Application installed. Of course, he or she can supply a link to the Helper Application and directions for installing it, but "users can be users" and might skip past it, going directly for the information they want even though they can't view it yet.

Make Your Program a Plug-In Module

One way around the problem of forcing users to download, install, configure, and link an external Helper Application to a Web browser themselves is to rewrite your program to turn it into a Web browser plug-in module. Plug-in modules are programs specifically written to run "embedded" within a particular Web browser. Currently, Netscape plug-ins are the most popular format. Since other browsers are becoming "Netscape plug-in compatible," this format might be considered an emerging standard.

Plug-ins solve many problems for Internet users, but increase the burden on programmers tremendously. For users, plug-ins end the problems of separate program downloads, installations, and configuring, since they handle all this themselves and automatically integrate into the Web browser, too. Plug-ins eliminate the need to worry about receiving a file type that can't be read because they check files before they transfer, as shown in Figure 5.2. Since they work within the Web browser, there's no separate window for users to get confused by or separate interface to learn.


Figure 5.2. Before transferring a live video/audio format called VDO, the system performs a plug-in check to see whether the file is usable.

Unfortunately, creating a plug-in from a conventional, standalone application isn't a trivial task. The end-result is something that works only within (and looks like part of) another company's Web browsing program, which isn't the result anyone would want after working for months on a new program. Additionally, all toolbar items and pull-down menus must be removed, since they aren't supported in plug-ins, and replaced with a single pop-up menu for command access, a method many new users aren't accustomed to. You also need to change all memory allocation calls to Netscape's memory allocator, and the plug-ins aren't cross-platform—they are compiled into native code. Finally, you'll probably need to maintain different versions of essentially the same program: one for the plug-in module for online users, and one for the standalone application for non-online users. All in all, there are many serious drawbacks to making your non-HTML data files readable by plug-in modules alone.

Making Your Program a Java Applet

Java applets—like Helper Applications—are great for users, but can be quite a burden on programmers. For the user, Java applets load into a Web browser just like a Web page, then execute on-the-fly to handle the non-HTML file only as needed. When it's no longer needed, the Java applet removes itself from the system and frees up space. The applet should work on any system the user might be surfing with, as long as it's running a browser with a Java Virtual Machine: Macs, PCs, and UNIX boxes with Netscape or Internet Explorer can all use the same information in the same file with the same Java applet.

Unfortunately, if you have an existing application written in a language other than Java, converting it into an applet is definitely a chore. First, you need an entirely new development platform, the Java Development Kit (JDK); however, it's available free of charge. Even though Java code might look and feel like C++ code, it isn't a direct port, so you have to get familiar with new standard classes. Once you've created your applet, you'll notice that Java is a very slow language, and your program will suffer a tremendous performance hit. However, the emergence of just-in-time Java compilers will probably remedy this drawback somewhat. Also, Java has no way to communicate with programs outside the Java Virtual Machine or write files to the client computer, so it won't be an effective information-transfer conduit for all situations. Therefore, you'll be forced to maintain two sets of source code: one for the Java applet, and one for the standalone application.

ActiveX Documents: The Best of All Worlds

The entire ActiveX documents metaphor combines the best elements of all the preceding options, making it easy for developers to write software that works well both inside and outside Web browsers, for Webmasters to distribute information stored in non-HTML files, and for users to access it all. In a way, you can think of ActiveX documents as a logical extension of OLE because they can draw from not only the programs on a local hard drive, but across the Internet as well.

How ActiveX Documents Work

If you've ever used the OLE features of your existing programs, then you already have a glimpse of how ActiveX documents work. For example, when you use WordArt within Microsoft Word, there is a separate, small program that runs within Word's regular window whenever the WordArt object is edited. In fact, the WordArt program is a standalone program that also has the OLE in-place activation interface, which means it can run inside any OLE server–enabled program, such as Word. With OLE in-place editing, you can double-click the WordArt object in the Word file to make WordArt appear within Word automatically. (See Figure 5.3.) Clicking anywhere in the Word document closes WordArt, and Word resumes as normal.


Figure 5.3. Editing an object created by an OLE-enabled program launches it within the "containing program."

ActiveX documents work similarly—except that the OLE link isn't limited to programs already installed on a user's hard drive (although they can certainly be used)—the OLE in-place editing can occur with programs stored remotely on the Internet. This means that Webmasters can distribute non-HTML files filled with information, and the Web browser could automatically load the module (with the user's permission) to access it through a remote ActiveX document OLE link, much like the way Word loads WordArt to access WordArt objects on your hard drive.

ActiveX documents go a step further, however; they encompass the entire document metaphor in a logical piece of information. To better understand this, consider the impact of OLE on documents: The in-place editing provided by OLE applies only to parts of a document, such as an image. OLE components are limited to being document parts; they can't know anything about the document at large. What this means is that the frame application is entirely responsible for managing the viewing and printing of the document in the standard OLE environment. ActiveX documents, on the other hand, encompass the entire concept of a document, including the means by which it is viewed and printed, as well as how it is stored. Applications still supply the view frame where the document is displayed and edited, but the document manages itself, for the most part.

To convert an existing application into an ActiveX document, you must support several additional OLE interfaces (described fully in the ActiveX SDK) beyond the "conventional" ones. Although this task isn't trivial, it isn't terribly hard either, and the resulting benefits of the extra work are tremendous: You get an application that can run as a standalone program and will integrate directly with any ActiveX document container, such as Internet Explorer 3.0, Microsoft Office Binder, or the next version of Windows' shell (Nashville's), in addition to existing OLE-enabled applications. In short, you get a versatile program with full OLE and Internet abilities for a reasonable amount of extra effort.

All this is done with the programming language you are probably already using, without having to maintain two separate code bases.

ActiveX Documents in Action

If you've had enough of the theories behind ActiveX documents and want to actually see an Internet-based object call a module, look no further than the ActiveX SDK CD-ROM, where you'll find the Traveler Three-Dimensional Chat beta program. Once you install and run it, it connects you to a three-dimensional world where you can chat (with a microphone and sound card) with other users. The "world" is stored in a SDS file and is, in fact, an ActiveX document.

Figure 5.4 shows the Traveler program running as a standalone application, which happens when you double-click its icon in the Start menu. Be sure to notice how it has its own set of menus and a toolbar, and how it communicates to the Internet through a conventional http:// URL, just like a Web browser.


Figure 5.4. The Traveler Chat application running as a standalone application.

This URL also works with Internet Explorer 3.0 once Traveler is installed, since the URL of http://www.onlive.com/utopia/entrance.sds points to an ActiveX Document. Jumping to it with Explorer causes Traveler to load within Explorer, adding a new toolbar and menus to the menu bar. In fact, you can interact with the Traveler "world" accessed with Explorer exactly as though you had accessed it by using Traveler as a standalone application. That's because it's the same program running within Explorer as an OLE in-place editor, just as WordArt was to Word.

The Benefits of ActiveX Documents

To the user of this ActiveX document, the transition from Web browser to Traveler is virtually seamless because the new program loads into the container program automatically. In this case, the new program was already on the local hard drive, but it might just as well have been on a remote server. Microsoft is finalizing the specifications for this remote OLE link with the Internet community. This program has its own toolbar and required menu, yet remains in the browser's window, combining the ease of a plug-in module with the flexibility of a Helper Application. Since the non-HTML stored data is an object, it can load or retrieve, by using an OLE link, software that can view and interact with it, so users can always use information stored in any format.

Software developers can continue to use their familiar programming tools and languages, yet maintain only one code base for a program that's so versatile. Even more important, software developers can leverage the code they've already written with OLE technology and apply it to the Internet by using ActiveX. This is a crucial point, influencing how ActiveX succeeds as a technology compared to Java, for example. Unlike Java, ActiveX has the benefit of a massive code base from the outset, thanks to its being based on OLE. More specifically, when it comes to ActiveX documents, it's not hard to imagine that Microsoft is busy integrating ActiveX into all its major productivity products.

In other words, ActiveX will give you early support for such mainstream document types as Word documents, Excel spreadsheets, and PowerPoint presentations. This means you can seamlessly integrate any of these document types into the traditional Web page environment. This might not seem quite as important for the Internet at large, but consider its consequences in the emerging push for intranets, local Web-based networks within companies. The focus of internal networks has long been aimed at sharing information (documents) among workgroups of people; ActiveX delivers on this goal on a large scale.

When examining the benefits of ActiveX documents, consider, too, the inherent improvements being made to the way you interact with software. Microsoft has been gradually pushing toward a document-centric approach to computing, in which documents take center stage over applications. In other words, the goal is to let the user focus on a document, rather than the application used to work with the document. OLE itself is a significant step toward this end, but it's still lacking in some ways, not the least of which is its nonexistent support for Web-based computing. Of course, this is only logical, since the Web has gained acceptance only recently. ActiveX documents take document-centric computing to its next level, building on and surpassing OLE to accommodate the Web.

What's Next

Now that you've seen how to combine your programs with a Web browser client program, the next chapter, "ActiveX Controls," shows how your programs can interface with Web server programs in a whole new way.

Previous Page TOC Next Page