Implémentation de fournisseur UI Automation côté client

Notes

Cette documentation s’adresse aux développeurs .NET Framework qui souhaitent utiliser les classes UI Automation managées définies dans l’espace de noms System.Windows.Automation. Pour obtenir les dernières informations sur UI Automation, consultez API Windows Automation : UI Automation.

Plusieurs frameworks d’interface utilisateur différents sont utilisés dans les systèmes d’exploitation Microsoft, notamment Win32, Windows Forms et Windows Presentation Foundation (WPF). Microsoft UI Automation expose aux clients des informations sur les éléments d’interface utilisateur. Toutefois, UI Automation n’a pas connaissance des différents types de contrôle qui existent dans ces frameworks, ni des techniques nécessaires pour en extraire les informations. En revanche, cette tâche est affectée aux objets appelés fournisseurs. Un fournisseur extrait des informations d’un contrôle spécifique et les transmet à UI Automation, qui les présente ensuite au client de façon cohérente.

Les fournisseurs peuvent exister côté serveur ou côté client. Un fournisseur côté serveur est implémenté par le contrôle lui-même. Les éléments WPF implémentent des fournisseurs, comme tout contrôle tiers écrit en tenant compte d’UI Automation.

Toutefois, les contrôles plus anciens tels que ceux de Win32 et Windows Forms ne prennent pas directement en charge UI Automation. En effet, ces contrôles sont traités par des fournisseurs qui existent dans le processus client et obtiennent des informations sur les contrôles à l’aide de la communication entre processus. C’est le cas, par exemple, avec le monitoring des messages Windows à destination et en provenance des contrôles. Ces fournisseurs côté client sont parfois appelés des proxies.

Windows Vista fournit des fournisseurs pour les contrôles Win32 et Windows Forms standard. En outre, un fournisseur de secours assure une prise en charge UI Automation partielle pour les contrôles non traités par un autre fournisseur côté serveur ou un proxy, mais disposant d’une implémentation Microsoft Active Accessibility. Tous ces fournisseurs sont automatiquement chargés et disponibles pour les applications clientes.

Pour plus d’informations sur la prise en charge des contrôles Win32 et Windows Forms, consultez Prise en charge UI Automation des contrôles standard.

Les applications peuvent également inscrire d’autres fournisseurs côté client.

Distribution des fournisseurs côté client

UI Automation s’attend à trouver des fournisseurs côté client dans un assembly de code managé. L’espace de noms de cet assembly doit avoir le même nom que l’assembly. Par exemple, un assembly appelé ContosoProxies.dll doit contenir l’espace de noms ContosoProxies. Dans l’espace de noms, créez une classe UIAutomationClientSideProviders . Dans l’implémentation du champ ClientSideProviderDescriptionTable statique, créez un tableau de structures ClientSideProviderDescription décrivant les fournisseurs.

Inscription et configuration des fournisseurs côté client

Les fournisseurs côté client dans une bibliothèque de liens dynamiques (DLL) sont chargés en appelant RegisterClientSideProviderAssembly. Aucune action supplémentaire n’est nécessaire de la part de l’application cliente pour utiliser les fournisseurs.

Les fournisseurs implémentés dans le propre code du client sont inscrits à l’aide de RegisterClientSideProviders. Cette méthode utilise comme argument un tableau de structures ClientSideProviderDescription , qui spécifient chacune les propriétés suivantes :

  • une fonction de rappel qui crée l’objet fournisseur ;

  • le nom de la classe des contrôles que le fournisseur doit traiter ;

  • le nom d’image de l’application (généralement le nom complet du fichier exécutable) que le fournisseur doit traiter ;

  • les indicateurs qui déterminent la comparaison du nom de la classe aux classes de fenêtres trouvées dans l’application cible.

Les deux derniers paramètres sont facultatifs. Le client peut spécifier le nom d’image de l’application cible quand il souhaite utiliser différents fournisseurs pour différentes applications. Par exemple, le client peut utiliser un fournisseur pour un contrôle ListView Win32 dans une application connue prenant en charge le modèle MultipleView, et un autre fournisseur pour un contrôle similaire dans une autre application connue n’assurant pas cette prise en charge.

Voir aussi