Prise en charge d’une interface

outre l’interface IUnknown , un contrôle ActiveX ou un objet COM pour ce cas exprime toutes les fonctionnalités facultatives qu’il prend en charge via des interfaces supplémentaires. Cela signifie qu’aucune autre interface n’est requise au-dessus de IUnknown. à cette fin, le tableau suivant répertorie les interfaces qu’un contrôle de ActiveX peut prendre en charge, et ce que cela signifie pour prendre en charge cette interface.

Interface Commentaires/ce que signifie la prise en charge de l’interface
IOleObject
Si le contrôle requiert la communication avec son site client pour tout autre chose que des événements (consultez IConnectionPointContainer), IOleObject est une nécessité. Lors de l’implémentation de cette interface, le contrôle doit également prendre en charge la sémantique des méthodes suivantes : SetHostNames, Close, EnumVerbs, Update, IsUpToDate, GetUserClassID, GetUserType, GetMiscStatuset les méthodes Advise, Unadviseet EnumAdvise qui fonctionnent conjointement avec l’implémentation IAdviseSink d’un conteneur. Un contrôle qui implémente IOleObject doit pouvoir gérer IAdviseSink si le conteneur en fournit un ; un conteneur ne peut pas, dans ce cas, un contrôle s’assure, bien sûr, qu’il n’essaie pas d’appeler un récepteur qui n’existe pas.
IOleInPlaceObject
Exprime la capacité du contrôle à être activée sur place et éventuellement activée par l’interface utilisateur. Cette interface signifie que le contrôle a une interface utilisateur d’un type qui peut être activé, et que IOleInPlaceActiveObject est également pris en charge. Les méthodes requises sont GetWindow, InPlaceDeactivate, UIDeactivate, SetObjectRectset ReactivateAndUndo. La prise en charge de cette interface requiert la prise en charge de IOleObject.
IOleInPlaceActiveObject
Un objet compatible sur place qui prend en charge IOleInPlaceObject doit également fournir cette interface, bien que le contrôle lui-même n’implémente pas nécessairement l’interface directement.
IOleControl
Exprime la capacité du contrôle et souhaite traiter les événements mnémoniques (a) (méthodes GetControlInfo, OnMnemonic ), (b) les propriétés ambiantes (OnAmbientPropertyChange) et/ou (c) que le contrôle requiert que le conteneur gère (FreezeEvents). Notez que les mnémoniques sont différents des accélérateurs qui sont gérés via IOleInPlaceActiveObject: les mnémoniques ont une interface utilisateur associée et sont actifs même lorsque le contrôle n’est pas activé par l’interface utilisateur. La prise en charge d’un contrôle pour les mnémoniques signifie que le contrôle sait également comment utiliser la méthode IOleControlSite :: OnControlInfoChanged du conteneur. Étant donné que le contrôle doit connaître le site du conteneur, la prise en charge des mnémoniques signifie également la prise en charge de IOleObject. En outre, la connaissance des mnémoniques requiert un support sur place et donc IOleInPlaceObject.
Si un contrôle utilise des propriétés ambiantes de conteneur, il doit également implémenter cette interface pour recevoir des notifications de modification, comme suit la sémantique des modifications est requise. Étant donné que les propriétés ambiantes sont uniquement disponibles par le biais du IDispatch du site conteneur, la prise en charge de la propriété ambiante signifie que le contrôle prend en charge IOleObject (pour obtenir le site) et peut générer des appels IDispatch :: Invoke .
La méthode FreezeEvents est nécessaire pour les contrôles qui doivent savoir quand un conteneur ne va pas gérer un événement. c’est le seul moyen pour le contrôle de connaître cette condition. Si FreezeEvents est uniquement nécessaire en isolation, de sorte que les autres méthodes IOleControl ne sont pas implémentées, IOleControl peut être autonome sans IOleObject ou IOleInPlaceObject.
IDataObject
Indique que le contrôle peut fournir au moins (a) des rendus graphiques du contrôle (CF _ MetaFilePict est le minimum si le contrôle a des éléments visuels) et/ou (b) jeux de propriétés, si le contrôle possède des propriétés à fournir. Les méthodes GetData, QueryGetData, EnumFormatEtc, DAdvise, DUnadviseet EnumDAdvise sont requises. La prise en charge des formats graphiques autres que CF _ MetaFilePict est facultative.
IViewObject2
Indique que le contrôle a des visuels intéressants lorsqu’il n’est pas actif sur place. Si elle est implémentée, un contrôle doit prendre en charge les méthodes Draw, GetAdvise, SetAdviseet GetExtent.
IDispatch
Indique que le contrôle a des méthodes personnalisées (a), ou (b) des propriétés personnalisées qui sont toutes les deux disponibles via une liaison tardive via IDispatch :: Invoke. Cela requiert également que le contrôle fournisse des informations de type par le biais d’autres méthodes IDispatch . Un contrôle peut prendre en charge plusieurs implémentations IDispatch où un seul est associé à IID _ IDispatch. les autres doivent avoir leurs propres identificateurs dispinterface uniques.
Un contrôle est encouragé à fournir des interfaces doubles pour l’accès aux propriétés et aux méthodes personnalisées, mais cela est facultatif si les méthodes et les propriétés existent.
Interfaces
Indique qu’un contrôle prend en charge au moins une interface sortante, telle que des événements ou des notifications de modification de propriété. Toutes les méthodes de cette interface doivent être implémentées si cette interface est disponible, y compris EnumConnectionPoints qui requiert un objet distinct avec IEnumConnectionPoints.
La prise en charge de IConnectionPointContainer signifie que l’objet prend également en charge un ou plusieurs objets connexes avec IConnectionPoint qui sont disponibles par le biais des méthodes IConnectionPointContainer . Chaque objet de point de connexion lui-même doit implémenter l’interface IConnectionPoint complète, y compris EnumConnections, qui requiert un autre objet énumérateur avec l’interface IEnumConnections .
IProvideClassInfo
IProvideClassInfo2
Indique que l’objet peut fournir ses propres informations de type coclasse directement via IProvideClassInfo :: GetClassinfo. Si le contrôle prend en charge la variation IProvideClassInfo2ultérieure, il indique également sa capacité à fournir son IID source principal via IProvideClassInfo2 :: GetGuid. Toutes les méthodes de cette interface doivent être implémentées.
ISpecifyPropertyPages
Indique que le contrôle a des pages de propriétés qu’il peut afficher afin qu’un conteneur puisse coordonner les pages de propriétés de ce contrôle avec les pages d’autres contrôles lorsque les pages de propriétés doivent être affichées pour une sélection de plusieurs contrôles. Toutes les méthodes de cette interface doivent être implémentées lorsque la prise en charge existe.
IPerPropertyBrowsing
Indique que la capacité du contrôle à (a) fournir une chaîne d’affichage pour une propriété, (b) fournir des chaînes et des valeurs prédéfinies pour ses propriétés et/ou (c) mapper un dispID de propriété à une page de propriétés spécifique. La prise en charge de cette interface signifie que la prise en charge des propriétés via IDispatch, comme indiqué ci-dessus, est fournie. Si (c) est pris en charge, cela signifie également que les pages de propriétés de l’objet mappées par le biais de IPerPropertyBrowsing :: MapPropertyToPage implémentent elles-mêmes IPropertyPage2 , contrairement à l’interface de base IPropertyPage .
IPersistStream
IPersist
IPersistMemory
IPersistStorage
IPersistMoniker
IPersistPropertyBag
Consultez interfaces de persistance.
IOleCache
IOleCache2
Indique la prise en charge de la mise en cache des conteneurs des visuels de contrôle. Un contrôle obtient généralement la prise en charge de la mise en cache par le biais de la fonction OLE CreateDataCache. Seuls les contrôles avec un contenu statique significatif doivent choisir de le faire (même si ce n’est pas obligatoire). Si un contrôle prend en charge la mise en cache, il doit simplement agréger le cache de données et exposer à la fois les interfaces IOleCache et IOleCache2 à partir du cache de données. Un contrôle qui implémente IOleObject doit pouvoir gérer IAdviseSink si le conteneur en fournit un ; un conteneur ne peut pas, dans ce cas, un contrôle s’assure, bien sûr, qu’il n’essaie pas d’appeler un récepteur qui n’existe pas.
IExternalConnection
Indique que le contrôle prend en charge les liens externes vers lui-même ; autrement dit, le contrôle n’est pas marqué avec OLEMISC _ CANTLINKINSIDE et prend en charge IOleObject :: SetMoniker et IOleObject :: GetMoniker. Un conteneur n’interrogera jamais cette interface et ne l’appellera pas directement à mesure que des appels sont générés à partir de la couche d’accès distant OLE.
IRunnableObject
Indique que le contrôle ne fait pas l’objet d’un chargement, comme le font certains objets in-process.

Contrôles