by Bryan Morgan
Microsoft's ActiveX technologies give developers the ability to build Internet applications using an existing base of programming objects and Application Programming Interfaces (APIs). In Chapter 20, "Calling COM Objects from Java," you learned how to use ActiveX controls to develop powerful Java applications or applets. Later chapters will discuss an entire suite of server technologies from Microsoft, some of which are based on ActiveX/COM, as well as how objects can be distributed across a network using DCOM. These objects can be called by other objects without the need to download anything to a local machine. All these technologies use the component object model (COM) as their basis. The Microsoft Internet Explorer browser supports another ActiveX technology known as ActiveX documents. This chapter explains what ActiveX documents are and how they can be used to enhance existing Web-based information.
ActiveX documents is the name for one of the newest ActiveX technologies from Microsoft. For readers who have had experience working with OLE2, ActiveX documents are the next logical extension of a subset of OLE 2.0 known as visual editing. Under OLE 2.0, visual editing allows a client object embedded in a server object to take over that server's menus and frame when the client object is clicked ActiveX documents take that idea a step further by allowing the client object to completely take over the server's frame window. The result is that the client application appears to have been called up in its own window. In actuality, however, the server application is still running; it is simply acting as a temporary container. Before delving into ActiveX documents and how they apply to the Java/Web developer, the first part of this chapter focuses on the parent of ActiveX documents: OLE 2.0 visual editing.
The purpose of OLE 1.0 was to allow objects to be linked and embedded within other objects (thus the name object linking and embedding, or OLE). When one of these objects is double-clicked under OLE 1.0, an entirely separate application is brought up to handle this object activation. Figure 22.1 shows an example of this procedure. In this figure, an OLE 1.0 object (Sound Recorder, in this case) is embedded in an OLE 2.0 document (Microsoft Word).
Figure 22.1 : An OLE 1.0 object embedded in an OLE 2.0 document.
Although a lot of work is done behind the scenes in OLE 1.0 to allow objects to be linked and embedded within other objects, the user does not receive that much added value. However, OLE 2.0 expands greatly on this idea. OLE 2.0 has a host of new capabilities, including structured file storage, in-place activation, and visual editing. ActiveX documents are an outgrowth of visual editing. Figure 22.2 shows visual editing in action; two OLE 2.0 applications (Microsoft Word and Excel) are working together to form an OLE compound document.
Figure 22.2 : OLE 2.0 in-place activation.
In this figure, a Microsoft Excel spreadsheet is embedded within a Microsoft Word document. Clicking on the Excel spreadsheet automatically changes the Microsoft Word menus and toolbars to the Microsoft Excel menus and toolbars (see Figure 22.3).
Figure 22.3 : Editing an Excel spreadsheet within Microsoft Word.
All this activity takes place through OLE 2.0 (using COM as the underlying foundation for object intercommunication) without requiring you to switch applications. Although OLE 2.0 was demonstrated earlier in the book, you now know enough about COM and interfaces to go beneath the surface and examine the process.
What is essentially happening is a large amount of handshaking between the client application (Microsoft Excel, in this case) and the server application (Microsoft Word). Saying that both applications are "OLE 2.0 compliant" means that they both have implemented a set of interfaces that allow objects to be edited while contained in other objects (known as container objects). In this case, Microsoft Excel implements a set of interfaces so that it can be drawn and controlled within another application's window. In addition, Microsoft Word has a set of interfaces that enable it to query the Microsoft Excel objects and determine if the required interfaces have been implemented. If they have, the document will be shown to the user.
OLE 2.0 has given users of desktop software (such as spreadsheets, word processors, and presentation builders) added functionality and power. Many users like working with applications that support the OLE 2.0 components because they can focus on the document at hand without being forced to switch manually from application to application. From a presentation viewpoint, documents have a much richer appearance both when displayed on the screen and when printed out. The ability to mingle presentations, multimedia, and spreadsheets within a single document gives the appearance of a sophisticated desktop publishing effort when, in fact, standard software was used to lay out the objects.
However, the OLE 2.0 visual editing paradigm does not apply exactly
to the World Wide Web. On the desktop, the container application
(Microsoft Word in Figures 22.2 and 22.3) is always the "main"
application that the user starts. This application contains the
parent document that the user of the application physically opens.
In the case of documents displayed on the World Wide Web, the
container application is the Web browser. In addition, all information
on the Web is generally for display only.
| NOTE |
Of course, some pages allow the user to update fields in order to post information back to the server. However, the primary purpose of the Web in its current form is to disseminate information to viewers in the form of HTML documents |
These documents are always displayed in a read-only fashion by the browser; therefore, the user doesn't have to dynamically insert objects into the document.
Missing from the Web, however, is the ability of Web browsers to automatically display documents of types other than HTML. HTML provides an excellent way to lay out static content such as text and graphics, as well as interactive content in the form of Java applets or ActiveX controls.
The problem is that not all information available in the world today exists in the form of HTML. An ideal solution would be for the Web browser to support all standards dealing with the display of HTML documents. In addition, however, the Web browser should be able to load other document types (such as the compound document displayed in Figures 22.2 and 22.3). Currently the two major browser developers, Microsoft and Netscape, have introduced competing ways of achieving this result.
Relatively early in its life cycle, the Netscape Navigator introduced the idea of Netscape "plug-ins" to allow file types to be displayed within the Netscape browser. Currently, plug-ins are available for Progressive Network's RealAudio, Macromedia Shockwave, VRML, and many other uses. Once the RealAudio plug-in is installed, clicking on a hyperlink to a RealAudio file causes that audio file to be played on your hard drive, using the installed RealAudio application. A Shockwave file can be displayed directly within the HTML page itself, using the Shockwave plug-in (similar to a Java applet being embedded within a Web page). By writing a Netscape plug-in and conforming to the Netscape APIs, developers of software products can be sure that their application's output will be displayed within the Netscape browser (assuming that the appropriate plug-in is installed on the user's computer).
The problem with this approach, according to Microsoft, is that it is a browser-only solution. In other words, although the downloaded file may be displayed correctly within the browser, no other applications on the local system can access that plug-in for their own uses.
ActiveX documents are similar in some respects to Netscape plug-ins. Files can be downloaded from remote servers and will be displayed automatically within Microsoft's Internet Explorer browser. However, instead of being simple add-ons to a Web browser, ActiveX documents use applications that currently exist on the user's local system to display the file within the browser. Because COM provides the basis for how the ActiveX document container (the browser) and the ActiveX document server (the application associated with the downloaded file) interface, any application can be written to become an ActiveX document container or server. The next version of Windows (currently code-named "Nashville" and probably slated to be named Windows 97) will support ActiveX documents extensively. In fact, the Explorer itself will be an ActiveX document container with the capability to display views of the current system, as well as the local network and Internet at large, to the user. Clicking on any document that supports these extensions will allow the user to view the document within the Explorer. In short, the Web browser and the local file-system browser will become one integrated tool.
Believe it or not, ActiveX documents actually grew out of a little-used tool included with Microsoft Office for Windows 95 named the Office Binder (see Figure 22.4). Before the advent of "doc objects," as they were called when Microsoft introduced them, OLE 2.0 visual editing was the closest users could come to mixing different types of data within a single application. The Office Binder application modified this paradigm slightly by providing a generic container application that could display multiple types of documents, all of which were stored in separate files.
Figure 22.4 : The Microsoft Office Binder application.
Shortly after the introduction of this product, Microsoft extended the idea to include content served over the Internet. Thus ActiveX documents were born. The release of the Internet Explorer 3.0 Web browser marked the first actual implementation of an ActiveX document container application. Using Internet Explorer, clicking on a hyperlink to a file will result in a request for one of two possible actions:
The HTML file in Listing 22.1 displays some text on the screen.
Clicking on the hyperlink at the bottom of the page will display
a Microsoft Word file within the browser (if Microsoft Word is
installed on your local system).
Listing 22.1. An HTML listing containing a hyperlink to a Microsoft Word document.
<html> <head> <title>Visual J++ Unleashed</title> </head> <body> <center> <h1>Visual J++</h1><br> <h2>Unleashed</h2><br> <br> <br> <h3>Chapter 22</h3> <h4>ActiveX Documents</h4> </center> <hr> <a href="Example1.doc"> Click here to view this as a Word file.</a> </body> </html>
Loading the Example1.html file into the Microsoft Internet Explorer 3.0 (or later) Web browser should result in a display that resembles Figure 22.5.
Figure 22.5 : The contents of Listing 22.1 in Internet Explorer 3.0.
Clicking on the hyperlink at the bottom of the page displayed in Figure 22.6 will load the ActiveX document, Example1.doc, using its associated application, Microsoft Word 7.0.
Figure 22.6 : An ActiveX document in Internet Explorer 3.0.
To see something else cool, grab a folder (either from the desktop or from within the Windows Explorer) and drag it over the Internet Explorer client area. Dropping the folder into the client area will result in that folder itself being displayed as an ActiveX document (see Figure 22.7).
Figure 22.7 : Windows folders displayed as documents.
Like all other ActiveX client-side extensions, at the time of this writing, ActiveX documents can be viewed only within an application that can act as an ActiveX document container. The only Web browser that supports this functionality is Microsoft's Internet Explorer.
Although you will probably not be creating an ActiveX document container such as Internet Explorer or the Office Binder application, chances are that you may have an application that could be improved by its integration with ActiveX. The following examples illustrate the type of applications that could be improved by adding the ActiveX document interfaces:
To make an application an ActiveX document server, a set of 10
interfaces needs to be implemented. Table 22.1 briefly describes
these interfaces.
| Interface Name | Description |
| IPersistStorage | Enables the use of OLE structured storage. |
| IPersistFile | Enables the use of OLE compound files for file storage. |
| IOleObject | Must be implemented by all OLE objects. |
| IDataObject | Must be implemented to define data-transfer capabilities. |
| IOleInPlaceObject | Must be implemented by all in-place servers. |
| IOleInPlaceActiveObject | Must be implemented by all in-place activation servers. |
| IOleDocument | Used to verify that the application can be an ActiveX document. |
| IOleDocumentView | Implements an ActiveX document view. |
| IOleCommandTarget | (Optional) Used for container/server interactions. |
| Iprint | (Optional) Enables support of print automation. |
Once the application implements these interfaces, file types associated with that application can be viewed within Internet Explorer or any other ActiveX document container.
This chapter provides a glimpse at the capabilities that currently exist within Microsoft's ActiveX client-side technologies. The purpose here is to define the term ActiveX documents and explain how developers can use this technology to complement existing Web-based solutions.
Despite some of the problems with ActiveX (security, platform-dependence, and daunting learning curve), many of its components are available today and are designed to fully integrate the Web with the Windows desktop. In situations where most, if not all, systems are running 32-bit Windows operating systems, ActiveX must be considered as a development option. However, until ActiveX is commercially available on other popular operating systems, such as the Apple Macintosh and UNIX, it cannot be considered to be a perfect solution for the Internet as a whole. This is because a large number (if not a majority) of the computers currently being used to access information on the Internet are non-Windows machines.
ActiveX documents allow Web-site designers and application builders to become suppliers of Web-based content without having to learn the complexities of HTML. Because applications written to implement the required ActiveX document interfaces can be viewed within the Internet Explorer browser, developers can distribute Microsoft Office data, for instance, without attempting to format it in HTML. Future versions of Windows promise to use ActiveX documents extensively throughout the system.