The term ActiveX has become the battle cry of many developers and development organizations over the past year. On the opposite side of the coin, sales and marketing organizations have also rallied around this same nebulous term. Few people, however, can truly explain what the term means. This book is dedicated to explaining what ActiveX is and what it means to developers. We hope that you learn as much from reading this book as we did from writing it.
Microsoft first coined the term ActiveX at the Internet Professional Developers Conference (Internet PDC) in March 1996. ActiveX referred to the conference slogan "Activate the Internet" and was more a call-to-arms than a technology or architecture for developing applications.
At the time of the Internet PDC, Microsoft was going head-to-head with Netscape over control of the Internet Web browser market. The PDC demonstrated, though, that Microsoft was interested in much more than just the browser market. Microsoft demonstrated tools ranging from electronic store fronts to new OLE Controls to virtual reality chat software, and beyond.
ActiveX is the new corporate slogan of Microsoft--similar to the term OLE in the early 1990s--and in a very short time, has come to mean much more than "Activate the Internet."
ActiveX has become the all-encompassing term used to define everything from Web pages to OLE (Object Linking and Embedding) Controls. It has come to signify, on one hand, small, fast, reusable components that can get you hooked into all the latest technologies coming out of Microsoft, the Internet, and the industry. On the other hand, ActiveX represents Internet and applications integration strategies. These days, products and companies that don't have ActiveX and Internet somewhere in their nomenclature are considered, both internally and externally, as being behind the times. The reality is that trying to describe ActiveX is similar to trying to describe the color red. ActiveX is not a technology or even an architecture--it is a concept and a direction.
ActiveX and OLE have become synonymous. What people once referred to as OLE Controls (OCXs) are now refered to as ActiveX Controls. OLE DocObjects are now ActiveX Documents. In some cases, entire documents on how to implement OLE technologies have been updated to be ActiveX technologies, and the only thing changed was the term OLE, which now reads as ActiveX.
Although tremendous advances have been made and seemingly new technologies appear daily with regard to OLE and ActiveX, it is questionable whether the Internet was or is directly involved in many of these areas. The need for small, fast, reusable components (COM Objects) has been around for years. Distributed components (DCOM Objects) were first demonstrated several years ago at the OLE 2.0 PDC. The Visual Basic (VB) group played a major role in the enabling of ActiveX in its early days. The BaseCtl framework, which is included in the ActiveX SDK, was developed by the VB group to answer its need for small, lightweight Controls to improve VB application's load times. The only contribution the Internet had was in its need for a way to implement and publish Web pages. Practically every new feature labeled ActiveX can trace its roots back to a fundamental, global need for small, fast, reusable components, all of which started with OLE and COM.
ActiveX was not meant to replace OLE, but simply to broaden it to include the Internet, intranet commercial and in-house applications development, and the tools used to develop them.
Microsoft has published a number of documents regarding ActiveX development. The OC 96 specification defines how Controls should be developed to provide faster startup times and better drawing capabilities. It also describes which interfaces are required and which are optional. The "OLE Control and Control Container Guidelines" provide important information for Control and Container interaction. The Microsoft Web site has become a cornucopia of information for creating, using, and deploying ActiveX components.
In addition to the specific technologies for creating ActiveX components, Microsoft has set a standard for the use and integration of ActiveX components. Every product from VB to Microsoft Word to Java is inherently capable of using ActiveX components. Four years ago, it was almost impossible to find more than a handful of applications that were capable of integrating in such a relatively seamless fashion as is possible today.
The next section looks at the specific types of ActiveX components that can be created and-- to be even more helpful--how and when they should be used.
This book addresses the topic of ActiveX Component development. These components can be classified and broken into the following categories:
Automation Servers
Automation Controllers
Controls
COM Objects
Documents
Containers
This book covers in detail only the development of ActiveX Automation Servers, Controls, and COM Objects. Automation Controllers, ActiveX Documents, and Containers entail too many interfaces and too much technology to be addressed in a book of this size.
Automation Servers are components that can be programmatically driven by other applications. An Automation Server contains at least one, and possibly more, IDispatch-based interfaces that other applications can create or connect to. An Automation Server may or may not contain User Interface (UI), depending on the nature and function of the Server.
Automation Servers can be in-process (executing in the process space
of the Controller), local (executing in its own process space), or
remote (executing in a process space on another machine). The specific
implementation of the server will, in some cases, define how and where the
server will execute, but that is not guaranteed. A DLL can execute as either
in-process, local or remote; an EXE can execute only locally or remotely.
NOTE: The fastest execution times are from Servers that are in-process to the Controllers using them. But remember that using an in-process Automation Server does not guarantee in-process performance. If an in-process Automation Server is created in one process space and then handed to a Controller in another process space, the Server becomes local and suffers from the same performance degradation as a Local Server. See Part II of this book for more information on process spaces and their impact on Server performance.
Automation Controllers are those applications that can use and manipulate Automation Servers. A good example of an Automation Controller is VB. With the VB programming language, you are able to create, use, and destroy Automation Servers as though they are an integral part of the language.
An Automation Controller can be any type of application, DLL or EXE, and can access the Automation Server either in-process, locally, or remotely. Typically, the registry entries and the implementation of the Automation Server indicate which process space the server will execute in relation to the Controller.
ActiveX Controls are equivalent to what is referred to as OLE Controls or OCXs. A typical Control consists of a UI representation both at design-time and runtime, a single IDispatch interface defining all of the methods and properties of the Control, and a single IConnectionPoint interface for the events that the Control can fire. In addition, the Control may have support for persistence across its execution lifetimes and support for various UI features, such as cut-and-paste and drag-and-drop features. Architecturally, a Control has a large number of COM interfaces that must be supported in order to take advantage of these features.
With the release of the new OLE Control and ActiveX guidelines for Control development, a Control is no longer limited to the feature set defined in the preceding text. Rather, the developer can now choose to implement only those features that are most useful and interesting to users of the applications. The Control and Container guidelines published by Microsoft list all the interfaces and their specific requirements. You can find this information at the Microsoft Web site: http://www.microsoft.com.
ActiveX Controls always execute in-process to the Container in which they reside. The extension of a Control is typically OCX, but in terms of execution models, it is nothing more than a standard windows DLL.
COM Objects are similar in architecture to Automation Servers and
Controllers. They contain one or more COM interfaces and probably little or no
UI. These Objects, however, cannot be used by the typical Controller application
the way Automation Servers can. The Controller must have specific knowledge of
the COM interface that it "talks" to in order to use the interface, which is not
the case for Automation interfaces. The Windows 95 and NT operating systems
contain hundreds of COM Objects and Custom interfaces as extensions to the
operating systems for controlling everything from the appearance of the desktop
to the rendering of 3-D images on the screen. COM Objects are a good way to
organize a related set of functions and data, while still maintaining the needed
high-speed performance of a DLL.
NOTE: Automation Servers can also benefit from COM interfaces. These servers are known as dual-interface Servers. The IDispatch interface of the Automation Server also has a companion COM interface describing the methods and properties of the Object. Automation Controllers such as VB can take advantage of these dual interfaces to provide even greater performance when using the Server. The one drawback to dual-interface Servers is that they are limited to the set of data types supported by OLE Automation when defining methods and properties.
ActiveX Documents, or DocObjects as they were originally called, represent Objects that are more than a simple Control or Automation Server. A document can be anything from a spread- sheet to a complete invoice in an accounting application. Documents, like Controls, have UI and are hosted by a Container application. Microsoft Word and Excel are examples of ActiveX Document Servers, and the Microsoft Office Binder and Microsoft Internet Explorer are examples of ActiveX Document Containers.
The ActiveX Document architecture is an extension of the OLE Linking and Embedding model and allows the document more control over the container in which it is being hosted. The most obvious change is how the menus are presented. A standard OLE Document's menu will merge with the Container, providing a combined feature set; whereas an ActiveX Document will take over the entire menu system, thus presenting the feature set of only the document and not that of both the Document and the Container. The fact that the feature set of the Document is exposed is the premise for all the differences between ActiveX Documents and OLE Documents. The Container is just a hosting mechanism, and the Document has all of the control.
Another difference is printing and storage. An OLE Document is intended to be a part of the Containers Document that is hosting it and, thus, is printed and stored as a piece of the host Containers Document. ActiveX Documents are expected to support their native printing and storage functions and are not integrated with the Containers Document.
ActiveX Documents are used within a uniform presentation architecture, rather than within an embedded document architecture, which is the basis for OLE Documents. Microsoft Internet Explorer is a perfect example of this. The Explorer merely presents the Web pages to the user, but they are viewed, printed, and stored as a single entity. Microsoft Word and Microsoft Excel are examples of the OLE Document architecture. If an Excel spreadsheet is embedded in a Word document, the spreadsheet is actually stored with the Word document and is an integral part of it.
ActiveX Documents also have the added capability of being published as Web pages on the Internet or on a corporate intranet. Imagine an in-house tracking system for purchase orders run from the same Web browsers that are used to connect to the Internet.
ActiveX Containers are applications that can host Automation Servers, Controls, and Documents. VB and the ActiveX Control Pad are examples of Containers that can host Automation Servers and Controls. The Microsoft Office Binder and the Microsoft Internet Explorer can host Automation Servers, Controls, and Documents.
With the decreasing requirements defined by the ActiveX Control and Document specifications, a Container must be robust enough to handle the cases where a Control or Document lacks certain interfaces. Container applications may allow little or no interaction with the Document or Control they host, or they may provide significant interaction capabilities in both manipulation and presentation of the hosted component. This capability, however, is dependent upon the Container hosting the component and is not defined by any of the Container guidelines as being required.
Chapter 2 takes a slightly more detailed look at the specific ActiveX and OLE technologies available and how best to apply them to your requirements.