 | ||||||
| ||||||
There is no question that OLE Controls, or COM objects in general, are useful as part of a document or page on an Internet site. However, some problems exist with regard to how a control is specified within a document, and how a control can behave well in a "slow-link" environment such as the Internet (including how the control retrieves its data in an incremental or progressive fashion, working well with other controls that might also be retrieving their data in the same manner).
Many controls, such as small buttons and label controls, which do not have significant amounts of persistent data, are already suitable for use in the Internet environment. Such controls, even those that already exist, need virtually no changes to work well inside browsers. This article focuses primarily on those controls that have significant amounts of persistent data.
The topics under consideration are listed here:
Other topics include miscellaneous subjects, including component categories; "Internet-awareness" requirements and options, including new dispIDs and GUIDs; standard Internet-aware picture, sound, and video objects; and reference material for interfaces described in this article.
In addressing the problems above, one must recognize that there are three different points in the lifetime of a Web document when these concerns arise:
It is also a requirement of this article to preserve as much of the existing Microsoft® Windows®, COM, and OLE programming model as possible—that is, to avoid creating new technology whenever possible, especially to avoid adding additional properties or interfaces that all controls would have to support regardless of their feature set. This ensures that this article does not significantly raise the amount of baseline technology for controls, meaning that only controls that need Internet features implement support for those features. It also leverages a great deal of work that has already been done on OLE Controls, both in design and implementation.
Note Everything in this article applies to generic COM objects as well as controls, although the term "control" is used most often. In fact, the distinction between controls and generic COM objects is gradually becoming non-existent. Controls are, at the time of writing, now considered to be nothing more than a COM object with support of the IUnknown interface at the minimum. Numerous optional interfaces provide the specific features that the control requires (such controls no longer use the "Control" registry key for identity, but use instead a new component category). This allows a control vendor to implement only as much code as is absolutely necessary for the control's functionality, placing the small added burden on the container to degenerate gracefully when a certain interface or feature is not available.
"Controls," as the term is used in this article, refers to any generic usage of OLE technologies in creating component software. The solutions presented here are extensions to the totality of OLE (not just extensions for a complete OLE Control that implements all possible control features). It should also be noted that this article describes only minimal extensions to the OLE model that has succeeded in the marketplace for several years now. As such, this article does not contain a substantial amount of "new" technology, merely extensions to make the existing technology work well in a new environment.
The extensions in this article also apply identically, without modification, to the new additions to the OLE Controls model to support windowless controls.
Note For more information on this view of controls, see the Control Guidelines document listed in the references.
In any situation where the source and consumer of any data are physically separate, there is the possibility for "broken links," where the consumer loses track of the source. This is a problem when it comes to standard OLE compound documents where a user might move a source or consumer document independent of the other, possibly breaking any links between the two. This problem exists because file systems are read/write as far as the user is concerned.
There is ongoing work to solve the link-tracking problem for OLE compound documents where monikers are involved. As solutions become available in that context, they will also become available to any other architecture that employs monikers. As moniker usage is part of this article, some degree of link tracking automatically comes into play without any extra work on the part of controls.
Furthermore, for Internet browsing purposes, link tracking is generally not required because it is assumed that only authors/designers of Web pages and Web sites will have the capability to rearrange the relative positions between source and consumer documents. In other words, the user sees the Web as a read-only file system. Because of that, it is the author's/designer's responsibility—with the help of an authoring tool built on the system-level link tracking services—to ensure that a document with external links contains accurate specifications of those external links. The same issues apply to hyperlinks, but no solutions are readily available given the widely distributed and heterogeneous nature of the Web. This article simply doesn't attempt to address link tracking.
This article does offer some assistance to authoring tools for managing external references made within controls. At the present time, however, it doesn't offer any solutions for nested controls where external references can exist at any level. This article handles a large majority of cases, but does not provide a complete solution.
It is also an author's/designer's responsibility to manage data stored in external locations so that the data can be removed when no document container links to those sources. For example, someone could author a document with a picture control whose data comes from a source specified with a URL moniker. However, at a later time, someone (the author or another person) could delete that picture control from the document. The author would then be responsible to determine whether the data source itself should be deleted if there are no controls referencing that data any longer.
This article does not offer any solutions to this resource management/reference counting issue. Solutions are the domain of content-management and authoring tools.
Did you find this topic useful? Suggestions for other topics? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top