Clients COM

De RAD Studio
Aller à : navigation, rechercher

Remonter à Composantes d'une application COM


Les clients peuvent toujours interroger les interfaces d'un objet COM pour déterminer ce qu'il est capable de faire. Tous les objets COM permettent aux clients de demander les interfaces connues. De plus, si le serveur gère l'interface IDispatch, les clients peuvent demander au serveur des informations sur les méthodes gérées par le serveur. Les objets serveurs n'ont pas d'attentes concernant l'utilisation de ses objets par le client. De même, les clients n'ont pas besoin de savoir comment (ou même si) un objet fournit les services ; ils s'en remettent simplement sur les objets serveurs pour fournir les services qu'ils annoncent via leurs interfaces.

Il y a deux types de clients COM : les contrôleurs et les conteneurs. Un contrôleur lance le serveur et interagit avec lui via son interface. Il demande des services de l'objet COM ou il le pilote comme processus distinct. Les conteneurs accueillent des contrôles visuels ou des objets qui apparaissent dans l'interface utilisateur du conteneur. Ils utilisent des interfaces prédéfinies pour négocier les problèmes d'affichage avec les objets serveur. Il est impossible d'avoir une relation conteneur sur DCOM ; par exemple, les contrôles visuels qui apparaissent dans l'interface utilisateur du conteneur doivent être localisés localement. En effet, les contrôles sont supposés se dessiner eux-mêmes, ce qui nécessite qu'ils puissent accéder aux ressources GDI locales.

Delphi facilite le développement d'un contrôleur Automation en permettant d'importer la bibliothèque de types ou un contrôle ActiveX dans un composant enveloppe de telle manière que les objets serveur apparaissent comme les autres composants VCL. Pour des détails sur ce processus, voir Création de clients COM.

Voir aussi