Qu’est-ce que la prise en charge d’une interface signifie

Outre l’interface IUnknown , un contrôle ActiveX ou un objet COM exprime toutes les fonctionnalités facultatives qu’il prend en charge par le biais d’interfaces supplémentaires. Cela veut dire qu’aucune autre interface n’est requise au-dessus de IUnknown. À cette fin, le tableau suivant répertorie les interfaces qu’un contrôle ActiveX peut prendre en charge et ce que signifie prendre en charge cette interface.

Interface	Commentaires/signification de la prise en charge de l’interface
IOleObject	Si le contrôle nécessite une communication avec son site client pour autre chose que des événements (voir 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, GetMiscStatus et les méthodes Advise, Unadvise et EnumAdvise qui fonctionnent conjointement avec l’implémentation IAdviseSink d’un conteneur. Un contrôle implémentant IOleObject doit être en mesure de gérer IAdviseSink si le conteneur en fournit un ; un conteneur ne peut pas, auquel cas un contrôle garantit, bien sûr, qu’il ne tente pas d’appeler un récepteur inexistant.
IOleInPlaceObject	Exprime la capacité du contrôle à être activé sur place et éventuellement activé par l’interface utilisateur. Cette interface signifie que le contrôle dispose d’une interface utilisateur d’un type quelconque qui peut être activée, et IOleInPlaceActiveObject est également pris en charge. Les méthodes requises sont GetWindow, InPlaceDeactivate, UIDeactivate, SetObjectRects et ReactivateAndUndo. La prise en charge de cette interface nécessite la prise en charge d’IOleObject.
IOleInPlaceActiveObject	Un objet sur place compatible 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é et le désir du contrôle de traiter (a) les mnémoniques (méthodes GetControlInfo, OnMnemonic ), (b) les propriétés ambiantes (OnAmbientPropertyChange) et/ou (c) les événements que le contrôle exige que le conteneur gère (FreezeEvents). Notez que les mnémoniques sont différents des accélérateurs 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 actif. 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 cela nécessite le contrôle pour connaître le site du conteneur, la prise en charge des mnémoniques signifie également la prise en charge d’IOleObject. En outre, la connaissance de la mnémonique nécessite une prise en charge 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, car la sémantique des modifications est requise. Étant donné que les propriétés ambiantes sont uniquement disponibles via IDispatch du site conteneur, la prise en charge des propriétés ambiantes signifie que le contrôle prend en charge IOleObject (pour obtenir le site) et qu’il 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 la seule façon pour le contrôle de connaître cette condition. Si FreezeEvents est nécessaire uniquement en isolation, de sorte que d’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 visuels du tout) et/ou (b) des jeux de propriétés, si le contrôle a des propriétés à fournir. Les méthodes GetData, QueryGetData, EnumFormatEtc, DAdvise, DUnadvise et 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. S’il est implémenté, un contrôle doit prendre en charge les méthodes Draw, GetAdvise, SetAdvise et GetExtent.
IDispatch	Indique que le contrôle a (a) des méthodes personnalisées ou (b) des propriétés personnalisées qui sont toutes deux disponibles via une liaison tardive via IDispatch::Invoke. Cela nécessite également que le contrôle fournisse des informations de type via d’autres méthodes IDispatch . Un contrôle peut prendre en charge plusieurs implémentations IDispatch où une seule est associée à IID_IDispatch les autres doivent avoir leurs propres identificateurs de 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 des méthodes et des propriétés existent.
IConnectionPointContainer	Indique qu’un contrôle prend en charge au moins une interface sortante, comme les événements ou les 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 nécessite un objet distinct avec IEnumConnectionPoints. La prise en charge d’IConnectionPointContainer signifie que l’objet prend également en charge un ou plusieurs objets associés avec IConnectionPoint qui sont disponibles via les méthodes IConnectionPointContainer . Chaque objet de point de connexion lui-même doit implémenter l’interface IConnectionPoint complète, y compris EnumConnections, qui nécessite un autre objet énumérateur avec l’interface IEnumConnections .
IProvideClassInfo IProvideClassInfo2	Indique que l’objet peut fournir ses propres informations de type de coclasse directement via IProvideClassInfo::GetClassInfo. Si le contrôle prend en charge la variante ultérieure IProvideClassInfo2, il indique également sa capacité à fournir son IID source principale 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 des pages de propriétés doivent être affichées pour une sélection multicontre. Toutes les méthodes de cette interface doivent être implémentées lorsque la prise en charge existe.
Navigation IPerProperty	Indique 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 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 via IPerPropertyBrowsing::MapPropertyToPage implémentent elles-mêmes IPropertyPage2 par opposition à l’interface IPropertyPage de base.
IPersistStream IPersistStreamInit IPersistMemory IPersistStorage IPersistMoniker IPersistPropertyBag	Consultez Interfaces de persistance.
IOleCache IOleCache2	Indique la prise en charge de la mise en cache de conteneur des visuels de contrôle. Un contrôle obtient généralement lui-même la prise en charge de la mise en cache via la fonction OLE CreateDataCache. Seuls les contrôles avec un contenu statique significatif doivent choisir de le faire (bien que cela ne soit 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 les interfaces IOleCache et IOleCache2 à partir du cache de données. Un contrôle implémentant IOleObject doit être en mesure de gérer IAdviseSink si le conteneur en fournit un ; un conteneur ne peut pas, auquel cas un contrôle garantit, bien sûr, qu’il ne tente pas d’appeler un récepteur inexistant.
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 ni ne l’appellera directement, car les appels sont générés à partir de la couche de communication à distance d’OLE.
IRunnableObject	Indique que le contrôle différencie le chargement de l’exécution, comme le font certains objets in-process.

Rubriques connexes

Contrôles