Implémentation d’un fournisseur de UI Automation Client-Side (proxy)
Microsoft UI Automation fournit un ensemble de proxys pour la plupart des contrôles standard, tels que ceux utilisés dans les applications Microsoft Win32, Windows Forms et Windows Presentation Foundation (WPF). Toutefois, de nombreux contrôles personnalisés et contrôles tiers n’implémentent pas de fournisseurs de UI Automation natifs. Pour être accessibles aux applications clientes UI Automation, ces contrôles doivent être fournis avec des fournisseurs côté client, également appelés fournisseurs proxy, ou proxys.
Cette rubrique explique comment écrire un fournisseur de proxy pour un contrôle non pris en charge et l’ajouter à la liste des proxys utilisés par les applications clientes. Il contient les rubriques suivantes :
- Qu’est-ce qu’un proxy ?
- Qu’est-ce qu’une fabrique de proxys ?
- Mappage de fabrique de proxy
- Gestion des proxys par défaut
- Rubriques connexes
Pour obtenir des exemples de code qui montrent comment implémenter des fournisseurs de proxy, consultez Rubriques de procédure pour UI Automation fournisseurs.
Qu’est-ce qu’un proxy ?
Un fournisseur côté client, ou proxy, est un objet qui implémente l’interface IRawElementProviderSimple pour le compte d’un contrôle qui n’a pas de propre implémentation IRawElementProviderSimple . Sans proxy, un tel contrôle est en grande partie opaque pour UI Automation, ce qui ne peut fournir que des informations de base disponibles à partir du handle de fenêtre (HWND), comme l’emplacement du contrôle.
Qu’est-ce qu’une fabrique de proxys ?
Chaque proxy nécessite une fabrique de proxy correspondante, qui est un objet qui expose l’interface IUIAutomationProxyFactory . UI Automation gère une table interne d’entrées de fabrique de proxy, chacune contenant une référence à la fabrique de proxy pour chaque proxy, et un ensemble de conditions. Quand UI Automation rencontre un contrôle qui n’a pas d’implémentation IRawElementProviderSimple native, il recherche une entrée de fabrique de proxy dont les conditions indiquent qu’il prend en charge le contrôle. UI Automation recherche dans la table à partir du début et lorsqu’il trouve une entrée correspondante, UI Automation appelle la méthode IUIAutomationProxyFactory::CreateProvider de la fabrique. Si le proxy correspondant est correctement créé, le UI Automation arrête la recherche et utilise l’objet proxy nouvellement créé ; sinon, UI Automation poursuit la recherche.
Une application cliente crée une instance d’une entrée de fabrique de proxy à l’aide de la méthode IUIAutomation::CreateProxyFactoryEntry, qui retourne un pointeur d’interface IUIAutomationProxyFactoryEntry. Les clients utilisent des méthodes exposées par IUIAutomationProxyFactoryEntry pour spécifier l’ensemble de conditions que la fabrique de proxy utilise pour créer le proxy.
Lorsqu’il appelle IUIAutomationProxyFactory::CreateProvider, UI Automation transmet les paramètres que l’objet de fabrique de proxy peut utiliser pour déterminer si le proxy prend correctement en charge le contrôle personnalisé. Si c’est le cas, la fabrique de proxy crée une instance du proxy et retourne le pointeur d’interface IRawElementProviderSimple ; sinon, elle retourne un pointeur NULL.
Mappage de fabrique de proxy
Par défaut, UI Automation recherche dans la table de fabrique du proxy dans l’ordre suivant.
| JSON | Proxy | Description |
|---|---|---|
| 1 | Microsoft : Proxy non-contrôle | Pour les fenêtres avec le nom de classe exact ou le nom de classe de base « ComboBoxEx32 ». |
| 2 | Microsoft : Proxy non-contrôle | Pour les fenêtres avec le nom de classe exact ou le nom de classe de base « WorkerW ». |
| 3 | Microsoft : Proxy non-contrôle | Pour les fenêtres avec le nom de classe exact ou le nom de classe de base « SHELLDLL_DefView ». |
| 4 | Microsoft : Proxy de conteneur | Pour les fenêtres avec le nom de classe exact ou le nom de classe de base « #32770 ». |
| 5 | Microsoft : Proxy de conteneur | Pour les fenêtres avec un nom de classe ou un nom de classe de base contenant « AfxControlBar ». |
| 6 | Microsoft : Proxy TreeView | Pour les fenêtres avec un nom de classe ou un nom de classe de base contenant « SysTreeView32 ». |
| 7 | Microsoft : Proxy ListView | Pour les fenêtres avec un nom de classe ou un nom de classe de base contenant « SysListView32 » (1). |
| 8 | Microsoft : Proxy ListView | Pour les fenêtres avec un nom de classe ou un nom de classe de base contenant « SysListView32 » (2). |
| 9 | Microsoft : Proxy MSAA | Pour n’importe quelle fenêtre. |
Les proxys 7 et 8 sont des entrées en double pour le contrôle SysListView32. Sans modification, le proxy 7 est toujours utilisé pour le contrôle SysListView32, et le proxy 8 n’est jamais utilisé. Le proxy 8 est utilisé uniquement pour les éléments de liste visibles et est généralement utilisé par les applications clientes qui fonctionnent uniquement avec des éléments visibles ou qui ont des exigences de performances strictes. Ces clients peuvent supprimer le proxy 7.
Le proxy 9, l’accessibilité active microsoft à UI Automation proxy, doit toujours être la dernière entrée de la table. Cela active la fonctionnalité de secours Microsoft Active Accessibility pour les contrôles qui implémentent Microsoft Active Accessibility, mais pas UI Automation.
Lorsque vous modifiez des entrées dans la table de fabrique de proxy, vous devez évaluer soigneusement la nouvelle position des entrées. Nous vous recommandons de placer les entrées pour les proxys personnalisés après les proxys de non-contrôle et de conteneur, mais avant le proxy Microsoft Active Accessibility to UI Automation. En outre, bien qu’il soit possible d’avoir du code dans l’appel à CreateProvider pour déterminer s’il doit prendre en charge un handle de fenêtre donné (HWND), il est plus efficace de laisser UI Automation sélectionner le proxy en fonction du nom de classe et de limiter au minimum le code conditionnel dans la méthode CreateProvider.
UI Automation gère une table de fabrique de proxy distincte pour chaque client. Lorsqu’un client modifie sa table proxy, les modifications affectent uniquement le client lui-même ; les autres clients ne sont pas affectés.
Gestion des proxys par défaut
Lorsqu’une application cliente crée l’objet CUIAutomation , la table de fabrique de proxy contient initialement des entrées uniquement pour les fournisseurs de proxy par défaut pour les contrôles standard. À l’aide de l’interface IUIAutomationProxyFactoryMapping , les clients peuvent ajouter de nouvelles entrées, supprimer des entrées indésirables, modifier l’ordre des entrées, etc. Un client peut récupérer un pointeur d’interface IUIAutomationProxyFactoryMapping en appelant la méthode IUIAutomation::P roxyFactoryMapping .
La table des proxys disponibles contient une interface IUIAutomationProxyFactoryEntry pour chaque proxy. Chaque IUIAutomationProxyFactoryEntry spécifie L’IUIAutomationProxyFactory et la classe de contrôle que le proxy sert, et définit la façon dont les événements doivent être gérés.
La table des proxys est représentée par une interface IUIAutomationProxyFactoryMapping , qui peut être obtenue à partir de la propriété IUIAutomation::P roxyFactoryMapping . Une application peut utiliser les méthodes IUIAutomationProxyFactoryMapping pour ajouter et supprimer des proxys. Pour créer une entrée à ajouter à cette table, utilisez IUIAutomation::CreateProxyFactoryEntry pour obtenir l’interface, puis utilisez les méthodes IUIAutomationProxyFactoryEntry pour définir la classe de contrôle applicable et le comportement du proxy.
Rubriques connexes