This chapter covers the ActiveX technology from a design abstraction point of view. You will get a firsthand glimpse at the framework and infrastructure leading to the ActiveX controls. The underlying foundations, including OLE, are very involved and complex topics with a dozen books and volumes of information available on CD-ROM. Hopefully, you will explore further to get more insight into the various components of the ActiveX infrastructure.
ActiveX technology is a component-based architecture that enables a developer to leverage the hundreds of available components and build upon them rather than starting from scratch. The ActiveX components can interoperate across networks with clients and servers and communicate over the intranet/Internet.
ActiveX technology can be used to create, integrate, and reuse software components or "controls" over the Internet or intranets. ActiveX software components, can be integrated into Web pages or any host that supports ActiveX controls. The ActiveX controls are, technologically, in-process COM objects. As they are COM objects, the controls can be integrated together with scripting to dynamically interact with users-at the client side and at the server side.
If the above definition looks like a marketing brochure, don't
worry. It is easy to define ActiveX by its capabilities and technology
and, as you read on, you will see glimpses of the actual inner
workings.
| NOTE |
ActiveX controls have the file name extension .ocx. Almost all the ActiveX controls are 32-bit implementations. The 16-bit controls are obsolete and, unless there is a compelling reason, you should refrain from using them. |
Before you dive into the ActiveX Controls, take a look at the Active platform. The Active platform consists of three core technologies: Active Desktop, Active Server, and ActiveX Components. Figure 4.1 shows a diagram of the Active platform.
The Active Platform is based on three core technologies:
COM is the acronym for Component Object Model. It is a binary
specification that describes an infrastructure for component-based
system interactions. Because the COM is binary, it is platform
and programming language independent. COM is the foundation for
the ActiveX technologies and OLE automation that are the foundations
of the ActiveX Platform. One of the advantages of the COM specification
is that it uses the same model for interobject-process communication-whether
the objects are in the same execution space, in the same computer
system, or in different systems across a network. It allows for
dynamic loading and unloading of components as well as shared
memory management between components/objects.
| ON THE WEB |
http://www.microsoft.com/oledev/olecom/com_modl.htm A good overview of the COM technology. http://www.microsoft.com/oledev/olecom/title.htm The COM reference and related documentation. |
It might be drastic to say that all the ActiveX technologies are based on the COM and OLE technologies since the COM is the basis for the ActiveX technology. It is the COM basics that make the ActiveX controls scalable and capable of being distributed on systems across a network.
The COM objects can exist anywhere in the network, in the namespace of a program, or in a separate server. From a client program perspective, the COM objects reference as a pointer to a virtual table in the memory called vtables. These vtables contain interface or function pointers to various registered COM objects. Figure 4.2 is a representation of this double indirection.
The advantage of the vtable double indirection is that COM objects can be shared between various programs and processes. The COM object is capable of handling the data belonging to each process. Thus, you do not need a separate COM object instance to share the objects, minimizing resource requirements while maintaining data independence.
The COM objects interact with the outside world through interfaces. COM interfaces are accesses from the outside world through the interface pointers. Interfaces are a group of functions that can act as properties, methods, or events in the traditional sense. You cannot call a method directly; you can only invoke a method using the interface pointer to that method. All these double indirection and function pointers are handled by the ActiveX code transparently. The program code required to handle all the COM interactions is already built into the developer tools and DLLs. Figure 4.3 shows how a COM object can be represented in a diagram.
Now that you know there are COM objects registered in local or
remote systems, how do you identify them? Even though names would
be a good choice, duplicate names will occur frequently so you
may be unable to uniquely identify a COM object. COM objects are
identified by a 128-bit integer called GUID (Globally Unique Identifier)
or UUID (Universally Unique Identifier). The GUIDs are created
using the OSF DCE algorithm, which guarantees universal uniqueness
(hopefully, aliens on Mars are not using the same algorithm).
The GUIDs, which are guaranteed to be unique in space and time,
are generated by an algorithm that takes the 48-bit network adapter
ID and the current date and time.
| NOTE |
GUIDs are written in hexadecimal digits as [12345678-1234-1234-1234-123456789ABC]. |
A CLSID is the GUID for the class in a COM object. You use the CLSID in the Web pages to refer to a COM object. There are also IIDs (Interface Identifiers) to refer to the interfaces for a given COM object.
IUnknown actually is the only known COM interface. Conceptually, it is the handle to all the functionalities of the COM object. When an external program or object wants to create a vtable for a COM object, the program invokes the QueryInterface function of the IUnknown handle. The QueryInterface procedure of the IUnknown interface takes the name of a function and returns information about whether it supports the function or not. If the COM object supports the requested function, the QueryInterface will return the function pointer. Your program will then use this function pointer to call that function. One point to be mentioned is that using the IUnknown handle, you can dynamically query the capabilities of a COM object.
The IUnknown also contains the AddRef and Release
procedures. These control the lifetime of the COM object. AddRef
adds the user counter by one and you will use the AddRef
procedure to inform the object that you are using the object.
When you are done with the object, you should call the Release
procedure that will decrement the usage counter in the COM object.
When the counter is zero, the object can be safely unloaded from
the system, if required. This reference counting technique is
called life-cycle encapsulation in the COM specification.
| NOTE |
For those technically minded folks, the UUID or GUID for the IUnknown interface is [00000000-0000-0000-C000-000000000046]. |
COM objects can live anywhere in the network and they can be activated with proper registration and security. The buzzword for this concept is location transparency. There are three scenarios:
Data marshalling is the name given to pass the data between the client and the COM object. The marshalling functions build the required data structures and data packets to COM objects as they unpack the data packets received from objects. The data packets contain the information necessary to interact with the COM object. In-process data marshalling is simple and is usually memory mapped. There is no need to resort to any special data marshalling schemes other than the vtable, interface pointers, and so on.
Out-of-process data marshalling is done using lightweight RPC; remote marshalling requires true RPC communication. In both cases, the client will access the local object proxy or the remote object proxy. The proxy will interact with the COM stub using the RPC method.
Proxy and Stub
The proxy for a COM object resides in the local program namespace. When an interface is called, the proxy packages the required information and sends it to the stub that resides in the system where the COM object is. The stub receives the data packet, unpacks it, and calls the COM object with the unpacked data.
When the COM object wants to send some information or data to the client, it sends the data to the stub, which packs the data and ships the packet to the proxy. The proxy unpacks the packet and gives the data to the client.
Conceptually, the proxy provides the virtual COM interface pointers and the real COM interface implementations are with the stub. But, to the client and the object, the proxy-stub mechanisms are transparent.
The proxy-stub mechanism enables the COM objects to reside anywhere. On local machines, the proxy-stub communication is through LRPC and on the network through DCE RPC.
Now you'll concentrate on the ActiveX objects and tools. Figure 4.4 shows the ActiveX framework in the Windows environment.
The ActiveX containers, like the HTML Viewer, embed the ActiveX controls. The COM services and finally the Windows OS kernel support the framework with the required facilities. The three main pieces of the ActiveX architecture are ActiveX documents, ActiveX controls, and ActiveX scripting.
Figure 4.5 shows the interaction between these pieces hierarchically and also as COM objects with interfaces.
Figure 4.5 : The ActiveX architecture hierarchy is a set of interacting COM objects.
| NOTE |
To put COM and ActiveX in perspective, ActiveX controls are lightweight COM Objects that are reusable and programmable at the HTML level. |
An ActiveX container is the controlling application, usually the Internet Explorer. It can also be a Web browser object in your Visual Basic application.
From a COM implementation point of view, the container must support the IOleContainer, IOleDocumentSite, and the IHLinkFrame interfaces. The IOleDocumentSite interface will interact with the embedded document or objects.
The ActiveX container can also be viewed as an ActiveX document server because it acts as a container for multiple documents and objects. The ActiveX container offers full-fledged support to the application that creates and manipulates the object. For example an embedded object with the .doc extension, when activated, will launch the WORD.exe application and give control to the application. Objects with .VBD extension (Visual Basic Document) will involve the vb5_xxx.dll or vb5_xxx.exe application.
ActiveX documents are actually objects that can be browsed and edited in-place by the applications. ActiveX documents can also be a collection inside another document, like the Microsoft Binder.
From a COM implemetation point of view, the ActiveX documents should support the IUnknown, IOleObject, IOleDocument, and IHLinkSite interfaces. The IOleContainer interface will connect with the IOleContainer interface of the document container and the IOleScript interface will connect with the IOleScript of the scripting engine.
An ActiveX control is an object that can be embedded in an ActiveX container. It is activated by the container and is not a freestanding object. It requires the context of the container to function. ActiveX controls are not limited to Web applications. They can be embedded in traditional applications developed by the C, BASIC, or Pascal languages.
An ActiveX control is COM object with the IUnknown interface
and should export the DLLRegisterServer and DLLUnRegisterServer
procedures. The properties, methods, and events it supports will
be exposed via the IUnknown interface. The parent ActiveX
document can control the ActiveX control via scripting.
| NOTE |
ActiveX controls are the updated versions of the OLE controls. For those who are familiar with older OLE controls, the main differences are |
ActiveX controls expose their properties, events, and methods to the container. Dynamic manipulation of these is done by ActiveX scripting. The scripting languages can be VBScript or JavaScript.
Scripts are added to the HTML page using the <SCRIPT> tag. The general usage of the <SCRIPT> tag is as follows:
<SCRIPT language="VBScript/JavaScript"> ...Script Statements ... </SCRIPT>
The scripting language can be VBScript or JavaScript-you cannot mix the languages. The scripts can be part of the <OBJECT> tag also. A full example of a script is as shown in Listing 4.1.
Listing 4.1 Script Example
<HTML>
<HEAD>
<TITLE>New Page</TITLE>
</HEAD>
<BODY>
<OBJECT ID="ComboBox1" WIDTH=120 HEIGHT=30
CLASSID="CLSID:8BD21D30-EC42-11CE-9E0D-00AA006002f3">
<PARAM NAME="VariousPropertyBits" VALUE="746604571">
<PARAM NAME="DisplayStyle" VALUE="3">
<PARAM NAME="Size" VALUE="2540;635">
<PARAM NAME="MatchEntry" VALUE="1">
<PARAM NAME="ShowDropButtonWhen" VALUE="2">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
</OBJECT>
<SCRIPT LANGUAGE="VBScript">
<!--
Sub cmdAddComboBoxItem_Click()
ComboBox1.AddItem("Another Item ")
end sub
-->
</SCRIPT>
<OBJECT ID="cmdAddComboBoxItem" WIDTH=120 HEIGHT=40
CLASSID="CLSID:D7053240-CE69-11CD-A777-00DD01143C57">
<PARAM NAME="Caption" VALUE="Add Item">
<PARAM NAME="Size" VALUE="2540;847">
<PARAM NAME="FontCharSet" VALUE="0">
<PARAM NAME="FontPitchAndFamily" VALUE="2">
<PARAM NAME="ParagraphAlign" VALUE="3">
</OBJECT>
</BODY>
</HTML>
The built-in objects accessible through the ActiveX script are Anchor, Document, Element, Frame, Form, History, Link, Location, Navigator, Script, and Window. The Window is the top- level object that contains Frame, History, Navigator, Location, Script, and Document objects. The next level is the Document object that contains Links, Anchors, and Form objects. The Form object is the most elemental built-in object in the hierarchy. The Form object contains the Element object. Actually, the Element objects are the ActiveX controls in the form.
You can develop ActiveX control using the Microsoft Foundation
Classes (MFC) using C++ and distributing the DLLs. To create an
ActiveX using the MFC/C++, you will first use the AppWizard to
create an ActiveX control project. Then you will proceed to add
properties, methods, and events to your control using the visual
wizards and adding C++ code as required. The end user will need
the MFC4x.DLL, as well as your control DLL, to run your ActiveX
control.
| NOTE |
Because the MFC developed controls require the MFC4x.DLL to run, you should think about distributing the MFC runtime DLLs. They are approximately 1M in size. Internet Explorer 3.0 and Windows NT 4.0 ship with the MFC Version 4.2 DLLs. If you develop your controls with VC++ 4.2, your users need not download the DLLs. If you do need other versions or even the 4.2 DLLs, use the cab file at http://www.microsoft.com/visualc/download/mfc42cam.htm. It takes about five minutes to download this compressed file with a 28.8Kbps modem. |
A second method for creating ActiveX controls is to use the ActiveX Template Library (ATL) that will generate an .ocx file the end user can download. On a technical level, the ActiveX Template Library is a set of C++ template classes for COM object development. The current version is ATL 2.0. More information is available at the URL http://www.microsoft.com/visualc/prodinfo/atlhowto.htm.
The third method for creating ActiveX controls is to create, customize, or assemble an ActiveX control using the Visual Basic Control Creation Edition.
The new ActiveX controls are optimized for code size and downloading
time. The older OLE controls were implemented with all the mandatory
interfaces and possibly contain things, like property pages, which
are not required. They will work fine in the ActiveX environment
but will be bulkier. Actually, with respect to OLE and older controls,
there are three types of ActiveX controls-the older OLE controls
that can be used across the intranets and Internets, the true
ActiveX controls that function similar to the older desktop OLE
controls, and the Internet-specific ActiveX controls which have
new functionality as the Stock Ticker Control, News Reader, and
so on.
| Internet-Abling Currently Available OLE Controls |
To make the existing controls Internet-friendly, Microsoft suggests the following tips: |
Even though we are deeply into ActiveX and related technologies, we should not forget that there are other competing equal or more powerful object-oriented technologies available. CORBA and IIOP are two of the main technologies which parallel the ActiveX capabilities.
Another recent development is JavaBeans from Sun. The good news is that JavaBeans includes an ActiveX bridge that will act as an ActiveX component with Javabeans events and properties mapped as COM interfaces, as shown in Figure 4.6.
Using JavaBeans you could interact with other object systems from your ActiveX world.