Besides the IUnknown interface, an ActiveX Control—or COM Object for that matter—expresses whatever optional functionality it supports through additional interfaces. This is to say that no other interfaces are required above IUnknown. To that end, the following table lists the interfaces that an ActiveX Control might support, and what it means to support that interface. Further details about the methods of these interfaces are given in a later section.
| Interface | Comments/What it Means to Support the Interface |
|---|---|
| IOleObject | If the control requires communication with its client site for anything other than events (see IConnectionPointContainer), then IOleObject is a necessity. When implementing this interface, the control must also support the semantics of the following methods: SetHostNames, Close, EnumVerbs, Update, IsUpToDate, GetUserClassID, GetUserType, GetMiscStatus, and the Advise, Unadvise, and EnumAdvise methods that work in conjunction with a container's IAdviseSink implementation. A control implementing IOleObject must be able to handle IAdviseSink if the container provides one; a container may not, in which case a control ensures, of course, that it does not attempt to call a non-existent sink. |
| IOleInPlaceObject | Expresses the control's ability to be in-place activated and possibly UI activated. This interface means that the control has a user interface of some kind that can be activated, and IOleInPlaceActiveObject is supported as well. Required methods are GetWindow, InPlaceActivate, UIDeactivate, SetObjectRects, and ReactivateAndUndo. Support for this interface requires support for IOleObject. |
| IOleInPlaceActiveObject | An in-place capable object that supports IOleInPlaceObject must also provide this interface as well, though the control itself doesn't necessarily implement the interface directly. |
| IOleControl | Expresses the control's ability and desire to deal with (a) mnemonics (GetControlInfo, OnMnemonic methods), (b) ambient properties (OnAmbientPropertyChange), and/or (c) events that the control requires the container to handle (FreezeEvents). Note that mnemonics are different than accelerators that are handled through IOleInPlaceActiveObject: mnemonics have associated UI and are active even when the control is not UI active. A control's support for mnemonics means that the control also knows how to use the container's IOleControlSite::OnControlInfoChanged method. Because this requires the control to know the container's site, support for mnemonics also means support for IOleObject. In addition, knowledge of mnemonics requires in-place support and thus IOleInPlaceObject. If a control uses any container-ambient properties, then it must also implement this interface to receive change notifications, as following the semantics of changes is required. Because ambient properties are only available through the container site's IDispatch, ambient property support means that the control supports IOleObject (to get the site) as well as being able to generate IDispatch::Invoke calls. The FreezeEvents method is necessary for controls that must know when a container is not going to handle an event—this is the only way for control to know this condition. If FreezeEvents is only necessary in isolation, such that other IOleControl methods are not implemented, then IOleControl can stand alone without IOleObject or IOleInPlaceObject. |
| IDataObject | Indicates that the control can supply at least (a) graphical renderings of the control (CF_METAFILEPICT is the minimum if the control has any visuals at all) and/or (b) property sets, if the control has any properties to provide. The methods GetData, QueryGetData, EnumFormatEtc, DAdvise, DUnadvise, and EnumDAdvise are required. Support for graphical formats other than CF_METAFILEPICT is optional. |
| IViewObject2 | Indicates that the control has some interesting visuals when it is not in-place active. If implemented, a control must support the methods Draw, GetAdvise, SetAdvise, and GetExtent. |
| IDispatch | Indicates that the control has either (a) custom methods, or (b) custom properties that are both available via late-binding through IDispatch::Invoke. This also requires that the control provides type information through other IDispatch methods. A control may support multiple IDispatch implementations where only one is associated with IID_IDispatch—the others must have their own unique dispinterface identifiers. A control is encouraged to supply dual interfaces for custom method and property access, but this is optional if methods and properties exist. |
| IConnectionPointContainer | Indicates that a control supports at least one outgoing interface, such as events or property change notifications. All methods of this interface must be implemented if this interface is available at all, including EnumConnectionPoints which requires a separate object with IEnumConnectionPoints. Support for IConnectionPointContainer means that the object also supports one or more related objects with IConnectionPoint that are available through IConnectionPointContainer methods. Each connection point object itself must implement the full IConnectionPoint interface, including EnumConnections, which requires another enumerator object with the IEnumConnections interface. |
| IProvideClassInfo[2] | Indicates that the object can provide its own coclass type information directly through IProvideClassInfo::GetClassInfo. If the control supports the later variation IProvideClassInfo2, then it also indicates its ability to provide its primary source IID through IProvideClassInfo2::GetGUID. All methods of this interface must be implemented. |
| ISpecifyPropertyPages | Indicates that the control has property pages that it can display such that a container can coordinate this control's property pages with other control's pages when property pages are to be shown for a multi-control selection. All methods of this interface must be implemented when support exists. |
| IPerPropertyBrowsing | Indicates the control's ability to (a) provide a display string for a property, (b) provide pre-defined strings and values for its properties and/or (c) map a property dispID to a specific property page. Support for this interface means that support for properties through IDispatch as above is provided. If (c) is supported, then it also means that the object's property pages mapped through IPerPropertyBrowsing::MapPropertyToPage themselves implement IPropertyPage2 as opposed to the basic IPropertyPage interface. |
| IPersistStream | See Persistence Interfaces section. |
| IPersistStreamInit | See Persistence Interfaces section. |
| IPersistMemory | See Persistence Interfaces section. |
| IPersistStorage | See Persistence Interfaces section. |
| IPersistMoniker | See Persistence Interfaces section. |
| IPersistPropertyBag | See Persistence Interfaces section. |
| IOleCache[2] | Indicates support for container caching of control visuals. A control generally obtains caching support itself through the OLE function CreateDataCache. Only controls with meaningful static content should choose to do this (although it is not required). If a control supports caching at all, it should simply aggregate the data cache and expose both IOleCache and IOleCache2 interfaces from the data cache. A control implementing IOleObject must be able to handle IAdviseSink if the container provides one; a container may not, in which case a control ensures, of course, that it does not attempt to call a non-existent sink. |
| IExternalConnection | Indicates that the control supports external links to itself; that is, the control is not marked with OLEMISC_CANTLINKINSIDE and supports IOleObject::SetMoniker and IOleObject::GetMoniker. A container will never query for this interface itself nor call it directly as calls are generated from inside OLE's remoting layer. |
| IRunnableObject | Indicates that the control differentiates being loaded from being running, as some in-process objects do. |