Added Standard Properties, Methods, Events, and Interfaces

The following table summarizes the added standard dispIDs described in this article.

The following table summarizes the new interfaces and other GUID values described in this article, as well as those that are described here—with the exception of category IDs described in a later section.

IPersistMoniker and its IID is documented in URL Monikers.

Requirements for Internet-Aware Controls and Objects

If a control does not use any data paths for BLOB data, working well within Internet-aware containers mostly means that a control supports as many IPersist interfaces as is reasonable for it, giving the container and asynchronous monikers a great deal of flexibility in how they initialize the control in both persistent embedding and persistent linking cases.

Controls that support only one persistence interface must mark themselves as mandatory users of the appropriate category.

Controls with one or more data paths have these requirements:

• Must support either IOleObject or IObjectWithSite as a siting mechanism.
• Must mark data path properties in type information with the [bindable] attribute as well as the appropriate custom attribute using GUID_PathProperty.
• Must mark the coclass entry in the control's type information with the custom attribute using GUID_HasPathProperties.
• Must follow the rules of moniker creation and persistence, using the container's IBindHost interface as necessary and as it is available.
• Must understand how to bind with an asynchronous moniker using a container-provided bind context from IBindHost if available and how to receive data through IBindStatusCallback.
• Must prioritize initialization sequences and data retrieval to render and interact as soon as possible, returning E_PENDING from member functions as appropriate for the control's initialization state.
• Should supply a ReadyState property, if applicable, and fire onreadystatechange events as needed.
• Should support IPersistPropertyBag for supporting HTML PARAM

Requirements for Internet-Aware Containers/Clients/Controllers

Whereas much of a control's functionality is optional, with the exception of necessary support for data paths, a container generally wants to support as many features as possible. As guidelines, a container that wants to host Internet-aware controls at run time should meet these requirements:

• Must expect and handle E_PENDING, especially from IViewObject2::Draw.
• Must provide a site to a control through either IOleObject or IObjectWithSite mechanisms.
• Must supply initialized bind contexts and name parsing through IBindHost.
• Must support at least IPersistStreamInit as a control persistence mechanism.
• Must support the HTML Extensions for COM Objects if the client is HTML-oriented.
• Should manage relative creation/initialization priorities for each control in the document.
• Should supply browsers for common data types required by data paths (authoring tools).
• Should support as many IPersist interfaces as possible to allow maximum control flexibility.

This article also recommends that controls be OLE accessibility-aware for the benefit of users requiring accessibility services.