Welcome to the exciting new world of ActiveX Programming! But is ActiveX really new? Well, yes and no. In Chapter 1, "An Overview of ActiveX," you learned the ActiveX themes. In addition, you also got an overview of what ActiveX can do for you. But what are the foundations of ActiveX? Moreover, what technologies does ActiveX include? These are the same questions I found myself asking when I returned from the Software Development 96 Conference last March.
During a lecture I attended, someone suggested that ActiveX was nothing more than Internet-aware OLE Controls. I started asking questions, and someone else informed me that ActiveX is nothing more than a sly marketing attempt to sell OLE under a different name. I was left perplexed and confused because no one could give me a definitive answer about the internals and framework of ActiveX or even an explicit definition of what ActiveX is. I decided to find out for myself just what ActiveX is.
What I found is that ActiveX is composed of a group of technologies or components to develop and implement applications for the Internet. I soon understood why no one could give me a clear definition. At the core of these technologies is OLE. ActiveX is an extension of OLE technologies across the Internet. But ActiveX is more than an extension of OLEit also comprises a series of Internet and multimedia services that can be used to create rich Internet applications. However, to understand ActiveX, you must first understand OLE. So this is where this chapter's exploration of ActiveX begins.
To understand the ActiveX Control, you must first understand ActiveX and most importantly OLE. This chapter examines each component technology that makes up OLE. Next, it covers how each component that makes up OLE is extended across the Internet through ActiveX. Then you will investigate the new technologies in ActiveX. Lastly, you will examine the OLE/ActiveX technologies included in an ActiveX Control. Keep in mind during your reading that OLE, ActiveX, and Internet programming are not easily mastered. The key to the deployment of these technologies is a thorough understanding of their concepts.
In 1991, Microsoft introduced a new specification called OLE 1.0. The OLE in OLE 1.0 stood for object linking and embedding. OLE 1.0 was basically a way of doing compound documents. A compound document is a way of storing data in multiple formats, such as text, graphics, video, and sound, in a single document. Object-oriented was the new programming buzzword, and the OLE 1.0 specification was a move to a more object-oriented paradigm. Furthermore, OLE 1.0 was an effort to move toward a more document-centric approach, instead of an applications-centric approach. Unfortunately, OLE 1.0 was coldly received by software developers. Very few independent software vendors (ISVs) and corporations raced to embrace OLE 1.0 and OLE-enable their applications. This reluctance to deploy OLE 1.0 in applications was mainly because OLE 1.0 had a steep learning curve. In addition, OLE 1.0 had to be coded using a very complex C API, which embodied programming concepts new to most developers.
Fortunately, Microsoft continued to strive to improve OLE and in 1993, released the OLE 2.0 specification. This new specification encompassed more than just compound documents; it sported an entire architecture of object-based services that could be extended, customized, and enhanced. The foundation of this services architecture was the Component Object Model (COM). The services available through this architecture are
From a programmatic view, OLE 2.0 is a series of services built on top of each other. These services form an architecture of interdependent building blocks built on the COM foundation.
Figure 2.1. OLE is built on the COM.
The release of OLE 2.0 had such an impact on standard ways of computing that it received two prestigious industry awards: a Technical Excellence award from PC Magazine and the MVP award for software innovation from PC/Computing. Adding to the OLE 2.0 success was a new and improved programming interface. Developers could now move to OLE-enabled applications much more easily. The OLE 2.0 services incorporate many of the principles embodied in object-oriented programming: encapsulation, polymorphism, and an object-based architecture. Further adding to the success of OLE 2.0 was the release in February of 1993 of Visual C++ 1.0 with the Microsoft Foundation Class (MFC) Library version 2.0. MFC had wrapped the OLE API in a C++ class library, thus making it much easier for programmers to utilize the OLE services architecture.
Don't let the ease of use of the MFC Library fool you. OLE programming is very difficult to master. However, I recommend that fledgling OLE and ActiveX programmers utilize MFC. MFC provides a framework to get you up and programming very quickly. Trying to program at the API level initially can lead to frustration and discouragement. If you do not know OLE, my advice is to learn the services, concepts, and standards and then go back and understand the low-level C API. Understanding the services, their interfaces, and when to use them is the main key to OLE and ActiveX programming.
Today OLE is no longer an acronym. The term object linking and embedding is now obsolete. Microsoft refers to it as simply OLE. Notice that there is no version number attached to OLE any more. Because OLE is an extensible architecture, it can be enhanced and extended without changing its basic foundation. A testimonial to this capability is OLE Controls. OLE Controls were not part of the original release of OLE. OLE Controls were not added to the available OLE services until almost a year after the original release. In fact, objects created with OLE 1.0 still work and interact with modern OLE applications. However, their functionality is limited to the original 1.0 specification. Thus there is no need for versions. From here on out, this chapter will simply refer to OLE unless specifically outlining a feature of OLE 1.0.
Because the end user is the main reason software is developed, this section will view OLE from the user's eyes. This will help you to grasp the benefits and the available services of OLE and ActiveX. The end user's view is simple, less technical, and very understandable. I firmly believe that the user decides in the first ten minutes of using an application whether he or she likes it. This sets the stage for all further experiences utilizing that application. Therefore, an application's intuitiveness, appearance, ease of use, capability of performing work or entertaining, and performance are of paramount importance.
Always keep in mind that the "devil-spawned end user", as the cartoon character Dilbert, by Scott Adams would say, is the main reason for our existence as software engineers. The best software engineers never forget this and always tackle every programming endeavor with the end user in mind.
Microsoftand Apple before themknew this. This is why Windows and the Macintosh each have a standard interface, not only from a user's perspective, but also from a programmer's perspective. Users interact with OLE in three ways: OLE Documents, OLE Automation, and OLE Controls. As a computer professional, you have seen or worked with Microsoft Word or Excel before. Microsoft Word is the classic example of an OLE Document. This chapter is not going to outline the functionality of Word but merely point out the features of OLE. However, do not be deceived; OLE Documents are not always the classic word processor. It is easy to think so because of the word "documents."
The first feature of OLE Documents is a common user model. This simply means that the User Interface (UI) features used to access OLE Documents are similar from application to application. The common user model features document-centricity and takes advantage of OLE's integrated data capabilities.
OLE user-interface-design guidelines are well documented in The Windows Interface Guidelines for Software Design, Microsoft Press, 1995.
One of these integrated data capabilities is called Linking and Embedding. Data objects of different types, created from other applications, can be embedded or linked into an application's OLE Document. This enables the user to manipulate the object in the host application without returning to the creating application. The object is simply edited in place, hence the term "in-place editing." The user interface is modified in the host application with menus, toolbars, and context menus from the application that created the object.
In Figure 2.2, take note of the two kinds of data, text and an embedded Visio drawing. Also note the toolbars and menu.
Figure 2.2. Microsoft Word document with embedded text and graphics.
If you double-click the Visio Drawing, the Word application changes, and new user interface objects are added to Word from Visio (see Figure 2.3). Notice that the Word user interface performs a metamorphosis and now has the Visio tool bars, floating dialog boxes, and menu items, as well as the Visio drawing and rulers. The user can then edit this drawing object without switching applications. In addition, these objects can be dragged and dropped between and within applications.
Figure 2.3. Microsoft Word document with the Visio drawing activated for in-place editing.
These features are implemented in the same way from application to application. Thus, there is a smaller learning curve for users when they get new applications, because the applications function similarly and have a common user model.
The next level of visibility to the user is OLE Automation. OLE Automation enables the user to access and modify objects through properties and methods utilizing a high-level language like Visual Basic for Applications (VBA). This enables the user to customize objects, and the inter-activity between objects, to perform operations the way the user defines. Microsoft Excel spreadsheets are the classic OLE Automation objects. The user can create Excel spreadsheets that update a Microsoft Graph object or update information in a Microsoft Access or Borland Paradox database. The greatest part of OLE Automation is that you do not have to be a programmer to take advantage of it. This is done through VBA. Microsoft has made VBA easy to learn using a Macro Recorder (see Figure 2.4) that records your keystrokes in VB code and an "object browser" that you use to paste the proper code where you need it. Anyone can learn to use it.
Figure 2.4. Microsoft Excel with the Macro Recorder invoked.
OLE Controls are the last area of OLE visibility to the end user. They are self-contained, reusable components that can be embedded in applications. To the user, they are nothing more than a control that takes their input and passes it to the application that contains it. However, some OLE Controls are static in nature, such as a picture control. OLE Controls are also OLE Automation objects that can have properties set at both compile time and runtime, and OLE Controls also have methods that can perform certain operations. The difference between OLE Controls and OLE Automation objects is that they are self-contained objects. They provide two-way communication between the control and the container. In future sections, you will discover that OLE Controls have been extended to ActiveX Controls that can be utilized across the Internet. These components have a very profound impact in the area of application development (see Figure 2.5), because they are prebuilt. From the end user's perspective, they provide increased functionality and lower software costs.
Figure 2.5. Properties and methods of an OLE Control during development in the Visual C++ Microsoft Developer studio.
This section covers the OLE Services from a programmatic view. For each service, you will be given a description of the technology and a programmer's view of the interfaces to these OLE services. Pay particular attention to understanding what each service does and where it fits into the architecture. The explanations highlight the interfaces to these objects and some key properties and methods where appropriate. Some of these services will be discussed in detail in later chapters as they pertain and integrate into ActiveX. Remember that OLE consists of the following services:
Notice these are the same technologies the end user sees. However, the end user's view is a visual one, and the programmers view is a menagerie of interfaces that must be mastered to provide the slick visual representation the end user sees. As discussed earlier, these services form building blocks on which each element in the architecture builds upon, as shown in Figure 2.6.
Figure 2.6. A programmatic view of OLE.
This architecture starts with the foundation, the COM.
When Microsoft designed OLE, it was designed with object-oriented programming in mind. COM objects are much like instantiated C++ classes or an ADA Package. In fact, COM was designed with C++ programmers in mind. It supports encapsulation, polymorphism, and reusability. However, COM was also designed to be compatible at the binary level and therefore has differences from a C++ object. As a programmer, you are aware that compiled programming languages such as C, C++, PASCAL, and ADA are machine-dependent. As a binary object, a COM object concerns itself with how it interfaces with other objects. When not utilized in the environment of its creator, an interface is exposed that can be seen in the non native environment. It can be seen because it is a binary object and therefore not machine-dependent. This does not require the host environment or an interacting object to know anything about the COM object. When the object is created in the womb of its mother application, COM does not concern itself with how that object interacts within it. This interaction is between the mother application and the child object. It is when the object interacts with the rest of the world that COM is concerned about how that object can be interfaced with. It is important to note that COM is not a programming language: it is a binary standard that enables software components to interact with each other as objects. It is also a programming model to facilitate the programmability of this standard.
COM objects consist of two types of items, properties and methods. Properties are the data members, and methods are member functions. COM objects each have a common interface. No matter what they do, COM objects all have to implement the IUnknown interface. This interface is the main interface for all others. The IUnknown interface has the following member functions:
Each object implements a vtable. A vtable is nothing more than an array of pointers to member functions implemented in the object (see Figure 2.7). This vtable is shared between all the instances of the object also maintaining the private data of each object. A client application evokes an instance of the interface and gets a pointer to a pointer that points to the vtable. Each time a new interface to the object is instantiated, the reference count of objects is incremented with AddRef(). Conversely, each time a reference is destroyed, the reference counter is decremented with Release(). Once the reference count is zero, the object can be destroyed. In order to see what interfaces an object supports, you can use QueryInterface().
Figure 2.7. How an interface maps into a vtable.
This section has covered a general overview of COM. An in-depth review of COM and how COM is implemented through ActiveX, complete with examples, is presented in Chapter 3, "Creating COM Objects."
Unfortunately, most platforms today have different file systems, making sharing data a very difficult task. In addition, these file systems arose during the mainframe days when only a single application needed to access the disk at any one time. COM is built with interoperability and integration between applications on dissimilar platforms in mind. In order to accomplish this, COM needs to have multiple applications write data to the same file on the underlying file system. OLE Structured Storage addresses this need.
Structured Storage is a file system within a file. Think of it as a hierarchical tree of storages and streams. Within this tree, each node on the tree will have one and only one parent, but each node may have from zero to many children. Another way to think of it is like the Windows 95 Explorer. The folders are the storage nodes, and the files are the streams. Structured Storage provides an organization chart of data within a file as seen in Figure 2.8. In addition, this organization of data is not limited to files, but includes memory and databases.
Figure 2.8. Structured Storage is a hierarchical tree of storages and streams.
Stream objects contain data. This data can be either native data or data from other outside objects. Storage objects are compatible at the binary level; thus, in theory, they are compatible across platforms. However, you all know that there are minute differences between the various platforms. Notice in Figure 2.8 the tree of the structured storage object. The definition of the tree is dependent on how the objects creator defined the storage of the object.
Structured Storage objects are manipulated utilizing the following OLE Interfaces:
IStorage,as the name implies, manipulates storage objects. Likewise, IStream manipulates streams. Rarely would you want to manipulate stream or storage objects individually. More than likely, you would want to manipulate the persistent storage object with the IPersistStorage. By persistent storage, I mean data that will continue to exist even after an object is destroyed. For example, if you wanted and allowed the user to define the color of an object such as a text label, you would persistently store that object's foreground and background colors. The next time the object was created you could read in from persistent storage the colors previously chosen by the end user. You could then apply those attributes to the object and thus maintaining the users preferences. IPersistStorage enables you to do this by performing the following operations:
A great way to see what structured storage looks like is with a utility that comes with Visual C++ 4.X called DfView. DfView is in the \MSDEV\BIN directory of Visual C++. DfView enables you to look at a compound file also known as an OLE Document. OLE Documents implement structured storage. Figure 2.9 shows an example of DfView (this is the Word document with an embedded Visio drawing object seen earlier in Figure 2.2).
Figure 2.9. DfView shows the hierarchical tree of a structured storage object.
If you double-click a stream object, you can see its binary contents (see Figure 2.10).
Figure 2.10. The binary contents of a stream object.
Monikers are a way to reference a piece of data or object in an object-based system like OLE. When an object is linked, a moniker is stored that knows how to get to that native data. For example, if you link a sound file into a Word document, the .WAV file is not stored natively in that document. A moniker is created that can intelligently find the .WAV file object.
To utilize a moniker to locate and bind to an object, you must utilize the IMoniker interface and call IMoniker::BindToObject. By utilizing the intelligent persistent name of that object, the IMoniker interface negotiates the location of that object and returns a pointer to the interface of that object's type. The moniker itself then dies. Think of it as similar to de-referencing a pointer in C or C++ to locate a piece of data. Remember that monikers are persistent. IMoniker is derived from IPersistStream, and thus it can serialize itself into a stream, hence persistence. There are five basic types of monikers:
File monikers store a filename persistently. In binding the text filename to the file object, a pointer to the file object interface is returned so that you can manipulate that file object.
Item monikers point to a specific place inside a file, such as a paragraph or a portion of an embedded video.
Anti monikers delete the last moniker in a series or chain of monikers, as in a composite moniker.
Pointer monikers simply point to other monikers wrapping them in a chain. However, it should be noted that pointer monikers are not persistent.
A composite moniker is an ordered collection of monikers. At the root of a composite moniker is a file moniker that references the document path name. It then holds a series of item monikers. Composite monikers are used when you need to have a collection of monikers within a single object.
Through OLE, you can utilize structured storage to store your objects, and monikers to find your objects, but there has to be a mechanism to move this data from the place it is stored (linked or embedded) to where you can output it to the client for manipulation. In addition, Uniform Data Transfer (UDT) also notifies the data object and the client of changes in the data. Uniform data transfer provides this service through the IDataObject interface. UDT is used primarily in three areas:
The system clipboard is a system-level service used for interprocess communications. Because it is a system-level service, all applications have access to it. OLE can utilize the clipboard to do UDT of objects between processes. With an IDataObject pointer, you can use the function OleSetClipboard() to take a cut or copied object and expose this object to all processes through the clipboard. Likewise, when you want to paste data from the clipboard, you can use your IDataObject pointer to utilize the OleGetClipboard() function. This is a very powerful mechanism because it maintains the integrity of the object as a whole, enabling you to move complex object data types between applications.
Drag and Drop is a method by which the user can select and move objects within an application and between applications. UDT is used to perform Drag and Drop actions. On the selection of the object, the source application packages the object and uses an IDataObject pointer to call DoDragDrop(). The source uses the IDropSource interface, which yields a pointer to its implementation. This pointer is passed to DoDragDrop(). The source controls the mouse cursors and handles the object in case of a cancellation.
Once the user brings the dragged object to its new client location or target, the client application evokes the IDropTarget interface. With the pointer to the IDropTarget, the client application tracks the object in relation to itself with the functions available in the IDropTarget interface. One function called IDropTarget::Drop() is called when the object is dropped on the target. Drop() passes the IDataObject pointer of the source to the target. Now that the client has the IDataObject pointer, it is free to manipulate the object.
A linked object is an object that is not stored within an OLE Document. In the document, a moniker is stored that references the linked object. This OLE function utilizes UDT to move the data from the data object source to the container application so that the data can be rendered as appropriate. Linked objects are manipulated through the IOleLink interface. By linking an object instead of embedding it, you cut down on the size of the compound file. In addition, you expose the linked object so that multiple people can utilize it.
An embedded object is an object that is stored, through the OLE structured storage mechanism, as native data within an OLE Document. Although this increases the size of the compound file, it provides a single file object that can contain multiple data types.
OLE Documents are nothing more than compound files that utilize structured storage to hold the objects that make up the document. These objects that make up the document can be native data, or they can, through the use of monikers, link to data outside of the document. In addition, an OLE Document can contain objects created by other processes, embedded as if they were natively a part of the document. OLE Documents are handled through interfaces just like any other OLE object. As you can see, OLE Documents are a conglomeration of several OLE services. Here are some of the interfaces utilized to implement OLE Document interfaces:
OLE Documents support in-place activation or what is commonly referred to as visual editing. This enables you to edit embedded objects in a container application as if they were native. When you activate visual editing in the container, the user interface of the container morphs to support selected user-interface functions of the server application that created the object. There are a whole series of interfaces to enable you to implement and support in-place activation. These interfaces all begin with IOleInPlace. These are some of the interfaces you can utilize to implement and support in-place activation:
OLE Automation basically enables you to manipulate the properties and methods of an application from within another application through the use of high-level macro languages and scripting languages like VBScript and JavaScript. This enables you to customize objects and provide interoperability between applications.
In the world of OLE Automation, there are OLE Automation Components and OLE Automation Controllers. An OLE Automation Component is a service that is exposed by an application for use by another. Microsoft Excel is a good example of this, as it exposes services that can create and manipulate worksheets, cells, and rows.
What services are available through an OLE Automation Component are stored in a type library. A type library is stored in a binary file with a TLB extension. Object Description Language is used to define the services of an OLE Automation Component. Object Description Language instructions are stored in a file with the extension ODL. The ODL file is compiled into a type library. In Visual C++ and in the ActiveX SDK, there is a nice utility that reads type libraries and graphically displays the services provided by OLE Automation Components.
The utility in Visual C++ is called OLE 2 View 32 application. The utility in the ActiveX SDK is called OLE\COM Viewer, and it is a newer implementation than the OLE 2 View 32 application in Visual C++. Figure 2.11 shows the OLE/COM Viewer, which can be used to view OLE and COM objects graphically.
The OLE2View32 Application in Visual C++ is located in the \MSDEV\BIN\ directory, and the filename is OLE2VW32.EXE. The OLE\COM Viewer in the ActiveX SDK is in the \INETSDK\BIN\ directory and the filename is OLEVIEW.EXE.
Figure 2.11. The OLE/COM Viewer that comes with the ActiveX SDK.
Notice that the Type Library Viewer screen (see Figure 2.12) shows the disassembled type library in Object Description Language. It also displays the constants, properties, methods, and interfaces to the Automation Component.
Figure 2.12. The OLE/COM Viewer's function Type Library Viewer.
OLE Automation Controllers are applications that use the services provided by OLE Automation Controllers. OLE Automation Controllers work through an interface called IDispatch. This dispatch interface exposes the available services to the controller application.
As discussed previously, OLE Controls are self-contained reusable components that can be embedded in applications. OLE Controls are also OLE Automation objects that can have properties set at both compile time and runtime, and OLE Controls also have methods that can perform certain operations. The difference between OLE Controls and OLE Automation objects is that they are self-contained objects. They provide two-way communication between the control and the container. These components have a very profound impact in the area of application development. These reusable self-contained pockets of functionality are discussed in detail in Chapter 5, "Creating OLE Controls."
ActiveX has taken the OLE Technologies and extended them beyond the bounds of the local machine, to Enterprise Wide networks and the Internet. Specifically, OLE Technologies have aggrandized into the following ActiveX services:
This is not the total affect. Elements of OLE are also present in the new ActiveX technologies, as will be discussed in the next section, "ActiveX Technologies." For now we will concentrate our discussion on the evolution of OLE Technologies into ActiveX.
ActiveX has taken OLE Documents and extended them across the Internet. This technology is a way for existing OLE Documents such as Microsoft Word, Microsoft Project, and Microsoft PowerPoint to be activated by a Web browser and brought up through a viewer. Thus you can have compound files with various data that can contain linked and embedded objects being accessed across the World Wide Web (WWW). Utilizing the ActiveX Hyperlinks technology, you can extend OLE Documents across the Web. ActiveX Hyperlinks are discussed in the next section. In addition, ActiveX Documents are discussed in depth in Chapter 19, "OLE Document Objects."
The ability to bring ActiveX Documents across the WWW gives rise to another ActiveX technology, Asynchronous Storage. Basically this extends structured storage across the Web, allowing for the storage to happen asynchronously. Obviously, with the slow bandwidth of the Internet, if you allowed a storage operation to happen synchronously, nothing else could happen on the client or server until the transfer of data to or from persistent storage took place. Utilizing ActiveX Hyperlinks and the technology of Asynchronous Monikers, Asynchronous Storage is accomplished.
ActiveX Controls are simply OLE Controls or OCXs that have been extended to the Internet environment. Microsoft has now replaced the term OLE Control with ActiveX Control. Remember, OLE is an extendible architecture; therefore, these reusable components can not only be embedded in a Web page, but also in a non-Internet-enabled application. ActiveX Controls are covered in depth in Chapter 5, "Creating OLE Controls."
ActiveX Controls can be created in a variety of languages, including C, C++, Java, and according to Microsoft, the next release of Visual Basic. They can also be manipulated though VBScript or JavaScript, so you do not even have to be a programmer to use them.
ActiveX Controls are great components as you have a virtual plethora of little pockets of prefabricated functionality you can take advantage of. The possibilities for ActiveX Controls are endless. Currently, ActiveX Controls range from a Calendar Control to a Picture Control that enables you to display static pictures.
COM is at the base of the ActiveX Control technology. ActiveX Controls are built on a series of OLE services, with COM as the base. The following list depicts the technologies that are encompassed in the ActiveX Control:
Just like the OLE Controls previously discussed, ActiveX Controls are COM objects. They are in-process OLE Automation servers activated from the inside out. Like every other COM object, they expose the IUnknown so that container applications can access their properties and methods through the pointers returned by the interface.
ActiveX Controls support two-way communication from the control to the client application. This method of communication is called Connectable Objects. It enables the control to notify the client of events or invoke a method or event. It also enables the client to communicate directly with the control.
Controls can be dragged and dropped within their client application if that functionality is enabled in the client application.
In the beginning of this chapter, you saw how an object from another application could be embedded in a host application. In addition, that object could be in-place activated for visual editing. Likewise, OLE Controls are built on the concept of OLE Documents and can be in-place activated.
ActiveX Controls have property pages, like their predecessor OLE Controls, that expose its properties and methods to the user. From the property pages, the properties can be set.
ActiveX Controls are automation servers. Their properties and methods can be set at compile time through the use of property pages and at runtime through VBScript and JavaScript.
COM objects can utilize Persistent Storage in a variety of ways. ActiveX Controls utilize Persistent Storage to store their state. This enables the control to be initialized to the state it was when you last utilized it.
As you learned previously, COM is a binary standard for objects. Basically COM operates the way it did before ActiveX, except that COM has been extended so that you can exchange and utilize objects across the Internet. This has given rise to Distributed COM.
Distributed COM, also known as DCOM and formerly known as Network OLE, is the basic extension of binary COM objects across LANs, WANs, and the Internet. Now you can instantiate and bind objects across a network. A detailed analysis of COM is presented in Chapter 3, "Creating COM Objects."
With the advent of ActiveX and the extension of COM across the net, quite naturally monikers were also extended and incorporated into this architecture. This gave rise to two new types of monikers.
A URL is a universal resource locator, used for Web-based addressing of objects. As you learned earlier, monikers are an intelligent naming system, so that by utilizing the IMoniker interface to an moniker object and the intelligent name, you can locate the object. This capability was simply extended to include URLs because of the capability to pass objects across the net from DCOM.
Previously, monikers carried out their binding to the object synchronously. Nothing could happen until the binding was complete. On the high latency, slow-link communications network of the Internet, holding up operations while binding is accomplished is unacceptable. Thus with asynchronous monikers, the interfaces to the object negotiate the transmission of the binding process, so as to perform it asynchronously. Right now, URL monikers are the only implementation of asynchronous monikers.
ActiveX brings to the table some new technologies that are not necessarily related to OLE. However, these technologies facilitate the creation of interactive applications for the World Wide Web. These items are
ActiveX hyperlinks basically allow in-place activation from HTML files of non-HTML based documents. Utilizing an ActiveX document container, you can access Microsoft Word, Microsoft Excel, Microsoft PowerPoint, Visio, and CorelDraw! documents from a hypertext link in an HTML document.
The ActiveX conferencing services are a suite of technologies that enable real-time, multiparty, multimedia communication over the Internet. This is much like video teleconferencing except you can do it on a PC. Just think what this does for programmers; we could all work at home and telecommute. This is a programmable interface opening up endless possibilities for innovation.
ActiveX server extensions, formerly known as the ISAPI Internet Server API, are used to give functionality to Internet servers. Previously this could only be done utilizing common gateway interface (GCI) code. ActiveX server extensions provide an alternative means to achieve this functionality. Usually server extensions are implemented utilizing a dynamic link library (DLL) and provide some functionality not provided by the HTTP server, such as connecting to a database.
ActiveX scripts bring OLE Automation to the Internet. Automation Controllers can now access Automation Component Services across the Internet with DCOM and ActiveX support for scripting. You can use a variety of scripting languages such as VBScript, JavaScript, Perl, Visual Basic for Applications, Lisp, and Scheme. To explore scripting, see Chapters 8, "Microsoft Internet Explorer Object Model for Scripting," 9, "VBScript," and 10, "JavaScript."
Code signing is a new technology that enables electronic signatures for code. This provides security from tampering of interactive applications across the net. Basically, the application vendors will provide a digital signature for their code that compiles with the Code Signing specification. On the client side, when an application or component is downloaded from the net, it calls a Win32 API function called WinVerifyTrust(). This function checks the digital signature and verifies it.
HyperText mark up language (HTML) is the language for all Web-based document production. In order to support ActiveX Controls and ActiveX Scripts, extensions had to be made to the HTML language. In addition, Web browsers had to be modified to accommodate the new language extensions. Now you can add ActiveX Controls to Web pages using the HTML <OBJECT> tag. These new extensions will be covered in Appendix O, "HTML Extensions."
ActiveMovie is a new technology to replace the old Media Control Interface and Video for Windows. ActiveMovie is an audio and video steaming framework. With ActiveMovie you will be able to play back MPEG, AVI, and Apple Quicktime movies.
This chapter has discussed OLE and the component architecture that makes up OLE. Because OLE is an object-oriented architecture founded on the COM, it is an extendible services architecture. Each OLE component is a building block for the rest of the technologies. Microsoft has extended this architecture to ActiveX to facilitate the creation of Internet-enabled applications. ActiveX builds on OLE and COM and adds new technologies of its own. ActiveX Controls are Internet-aware controls that are nothing more than an extension of the OLE Control architecture and make it easy to extend the use of reusable components on the Internet.
Next, Chapter 3 explores the COM in depth and shows you how to create COM objects. You will find out why COM objects, as opposed to C++, ease the programming challenge.