Vue d’ensemble des instructions relatives aux conteneurs de contrôle et de contrôle
Un contrôle ActiveX est essentiellement un objet OLE simple qui prend en charge l’interface IUnknown . Il prend généralement en charge davantage d’interfaces afin d’offrir des fonctionnalités, mais toutes les interfaces supplémentaires peuvent être vues comme facultatives et, par conséquent, un conteneur de contrôle ne doit pas s’appuyer sur des interfaces supplémentaires prises en charge. En ne spécifiant pas d’interfaces supplémentaires qu’un contrôle doit prendre en charge, un contrôle peut cibler efficacement un domaine particulier de fonctionnalités sans avoir à prendre en charge des interfaces particulières pour être considéré comme un contrôle. Comme toujours avec OLE, que ce soit dans un contrôle ou un conteneur de contrôle, il ne doit jamais être supposé qu’une interface est disponible et les conventions de vérification de retour standard doivent toujours être suivies. Il est important pour un conteneur de contrôle ou de contrôle de se dégrader correctement et d’offrir d’autres fonctionnalités si une interface requise n’est pas disponible.
Un conteneur de contrôle ActiveX doit être en mesure d’héberger un contrôle ActiveX minimal ; il prend également en charge un certain nombre d’interfaces supplémentaires, comme spécifié dans Conteneurs. Un conteneur peut éventuellement prendre en charge un certain nombre d’interfaces et de méthodes, qui sont regroupées en zones fonctionnelles appelées catégories de composants. Un conteneur peut prendre en charge n’importe quelle combinaison de catégories de composants, par exemple, une catégorie de composants existe pour la liaison de données et un conteneur peut ou non prendre en charge la fonctionnalité de liaison de données, en fonction des besoins du marché du conteneur. Si un contrôle a besoin d’une prise en charge de la liaison de données à partir d’un conteneur pour fonctionner, il entre cette exigence dans le Registre. Cela permet à un conteneur de contrôles d’offrir uniquement pour l’insertion les contrôles qu’il sait qu’il peut héberger correctement. Il est important de noter que les catégories de composants sont spécifiées dans le cadre d’OLE et ne sont pas spécifiques aux contrôles ActiveX. L’architecture des contrôles utilise des catégories de composants pour identifier les zones de fonctionnalités qu’un composant OLE peut prendre en charge. Les catégories de composants n’étant pas cumulatives ou exclusives, un conteneur de contrôle peut prendre en charge une catégorie sans nécessairement en prendre en charge une autre.
Il est important que les contrôles qui nécessitent des fonctionnalités facultatives, ou des fonctionnalités spécifiques à un conteneur donné, soient clairement empaquetés et commercialisés avec ces exigences. De même, les conteneurs qui offrent certaines fonctionnalités ou catégories de composants doivent être commercialisés et empaquetés comme offrant ces niveaux de prise en charge lors de l’hébergement de contrôles ActiveX. Il est recommandé que les contrôles ciblent et testent avec autant de conteneurs que possible et se dégradent normalement pour offrir moins de fonctionnalités ou d’autres fonctionnalités si les interfaces ou les méthodes ne sont pas disponibles. Dans une situation où un contrôle ne peut pas effectuer sa fonction de travail désignée sans la prise en charge d’une catégorie de composant, cette catégorie doit être entrée comme une exigence dans le registre afin d’empêcher l’insertion du contrôle dans un conteneur inapproprié.
Ces instructions définissent les interfaces et les méthodes qu’un contrôle peut s’attendre à ce qu’un conteneur de contrôles prend en charge, bien que, comme toujours, un contrôle doit case activée les valeurs renvoyées lors de l’utilisation de QueryInterface ou d’autres méthodes pour obtenir des pointeurs vers ces interfaces. Un conteneur ne doit pas s’attendre à ce qu’un contrôle prend en charge autre chose que l’interface IUnknown , et ces instructions identifient les interfaces qu’un contrôle peut prendre en charge et ce que signifie la présence d’une interface particulière.
Pourquoi les instructions relatives aux conteneurs de contrôle et de contrôle ActiveX sont importantes
Les contrôles ActiveX sont devenus l’architecture principale pour le développement de composants logiciels programmables à utiliser dans différents conteneurs, allant des outils de développement logiciel aux outils de productivité des utilisateurs finaux. Pour qu’un contrôle fonctionne correctement dans une variété de conteneurs, le contrôle doit être en mesure d’assumer un niveau minimal de fonctionnalités sur lequel il peut s’appuyer dans tous les conteneurs.
En suivant ces instructions, les développeurs de contrôles et de conteneurs rendent leurs contrôles et conteneurs plus fiables et interopérables, et, en fin de compte, de meilleurs composants et plus utilisables pour la création de solutions basées sur des composants.
Procédure à suivre lorsqu’une interface dont vous avez besoin n’est pas disponible
Les programmes OLE doivent utiliser QueryInterface pour acquérir des pointeurs d’interface et doivent case activée la valeur de retour. Les applications OLE ne peuvent pas supposer en toute sécurité que QueryInterface réussira.
Cette exigence s’applique à toutes les applications OLE. Si l’interface demandée n’est pas disponible (c’est-à-dire que QueryInterface retourne E_NOINTERFACE), le contrôle ou le conteneur doit se dégrader correctement, même si cela signifie qu’il ne peut pas effectuer sa fonction de travail désignée.
Rubriques connexes