Реализация поставщика автоматизации пользовательского интерфейса Client-Side (прокси)

модель автоматизации пользовательского интерфейса майкрософт предоставляет набор прокси-серверов для большинства стандартных элементов управления, например используемых в приложениях Microsoft Win32, Windows Forms и Windows Presentation Foundation (WPF). Однако многие пользовательские элементы управления и сторонние элементы управления не реализуют собственные поставщики автоматизации пользовательского интерфейса. Для доступа к клиентским приложениям модели автоматизации пользовательского интерфейса эти элементы управления должны предоставляться поставщикам на стороне клиента, которые также называются поставщиками прокси-сервера или прокси.

В этом разделе описывается, как создать поставщик прокси для неподдерживаемого элемента управления и добавить его в список прокси-серверов, используемых клиентскими приложениями. Руководство состоит из таких разделов:

Примеры кода, демонстрирующие способы реализации поставщиков прокси-сервера, см. в разделах с инструкциями по поставщикам автоматизации пользовательского интерфейса.

Что такое прокси?

Поставщик на стороне клиента или прокси-сервер — это объект, реализующий интерфейс иравелементпровидерсимпле от имени элемента управления, который не имеет собственной реализации иравелементпровидерсимпле . Без прокси-сервера такой элемент управления в значительной степени непрозрачен для автоматизации пользовательского интерфейса, который может предоставлять только основные сведения, доступные из дескриптора окна (HWND), например расположения элемента управления.

Что такое фабрика прокси-серверов?

Для каждого прокси-сервера требуется соответствующая фабрика прокси-сервера, которая представляет собой объект, предоставляющий интерфейс иуиаутоматионпроксифактори . Модель автоматизации пользовательского интерфейса поддерживает внутреннюю таблицу записей фабрики прокси-серверов, каждая из которых содержит ссылку на фабрику прокси-сервера для каждого прокси-сервера и набор условий. Когда модель автоматизации пользовательского интерфейса обнаруживает элемент управления, который не имеет собственной реализации иравелементпровидерсимпле , он ищет запись фабрики прокси, условия которой указывают, что он поддерживает элемент управления. Модель автоматизации пользовательского интерфейса выполняет поиск в таблице начиная с начала, а при обнаружении соответствующей записи модель автоматизации пользовательского интерфейса вызывает метод иуиаутоматионпроксифактори:: креатепровидер фабрики. Если соответствующий прокси-сервер успешно создан, Автоматизация пользовательского интерфейса прекращает поиск и использует только что созданный прокси-объект. в противном случае автоматизация пользовательского интерфейса продолжит поиск.

Клиентское приложение создает экземпляр записи фабрики прокси с помощью метода иуиаутоматион:: креатепроксифакторентри , который возвращает указатель интерфейса иуиаутоматионпроксифакторентри . Клиенты используют методы, предоставляемые иуиаутоматионпроксифакторентри , для указания набора условий, которые фабрика прокси использует для создания учетной записи-посредника.

При вызове иуиаутоматионпроксифактори:: Креатепровидермодель автоматизации пользовательского интерфейса передает параметры, которые объект фабрики прокси может использовать для определения того, поддерживает ли прокси пользовательский элемент управления. В этом случае фабрика прокси-сервера создает экземпляр прокси-сервера и возвращает указатель на интерфейс иравелементпровидерсимпле ; в противном случае возвращается пустой указатель.

Сопоставление фабрики прокси-серверов

По умолчанию модель автоматизации пользовательского интерфейса выполняет поиск в таблице фабрики прокси в следующем порядке.

Порядок Proxy (Прокси) Описание
1 Майкрософт: не управляющий прокси-сервер Для Windows с точным именем класса или именем базового класса "ComboBoxEx32".
2 Майкрософт: не управляющий прокси-сервер Для Windows с точным именем класса или именем базового класса "Воркерв".
3 Майкрософт: не управляющий прокси-сервер Для Windows с точным именем класса или именем базового класса "ШЕЛЛДЛЛ _ дефвиев".
4 Microsoft: прокси-контейнер Для Windows с точным именем класса или именем базового класса " # 32770".
5 Microsoft: прокси-контейнер Для Windows с именем класса или именем базового класса, содержащим "Афксконтролбар".
6 Microsoft: прокси-сервер TreeView Для Windows с именем класса или именем базового класса, содержащим "SysTreeView32".
7 Microsoft: прокси-сервер ListView Для Windows с именем класса или именем базового класса, содержащим "SysListView32" (1).
8 Microsoft: прокси-сервер ListView Для Windows с именем класса или именем базового класса, содержащим "SysListView32" (2).
9 Microsoft: прокси MSAA Для любого окна.

Прокси 7 и 8 являются повторяющимися записями для элемента управления SysListView32. Без изменения прокси-сервер 7 всегда используется для элемента управления SysListView32, а прокси 8 никогда не используется. Прокси 8 используется только для видимых элементов списка и обычно используется клиентскими приложениями, работающими только с видимыми элементами или имеющими требования к производительности. Эти клиенты могут удалить прокси 7.

Прокси 9, Active Accessibility Майкрософт к прокси-серверу автоматизации пользовательского интерфейса, всегда должен быть последним элементом в таблице. Это обеспечивает возможность использования Microsoft Active Accessibility для элементов управления, реализующих Microsoft Active Accessibility, но не для автоматизации пользовательского интерфейса.

При изменении записей в таблице фабрики прокси следует тщательно оценить новое расположение записей. Рекомендуется размещать записи для настраиваемых прокси-серверов после учетных записей-посредников, не относящихся к элементам управления и контейнеров, но до того, как Microsoft Active Accessibilityся в прокси модели автоматизации пользовательского интерфейса. Кроме того, хотя код в вызове креатепровидер определяет, должен ли он поддерживать данный дескриптор окна (HWND), более эффективным является выбор прокси-сервера на основе имени класса и сохранение условного кода в методе креатепровидер до минимума.

Модель автоматизации пользовательского интерфейса поддерживает отдельную таблицу фабрики прокси для каждого клиента. Когда клиент изменяет свою таблицу прокси, изменения затрагивают только сам клиент; на другие клиенты это не влияет.

Управление прокси-серверами по умолчанию

Когда клиентское приложение создает объект куиаутоматион , в таблице фабрики прокси-сервера изначально содержатся только записи для поставщиков прокси-серверов по умолчанию для стандартных элементов управления. С помощью интерфейса иуиаутоматионпроксифакторимаппинг клиенты могут добавлять новые записи, удалять ненужные записи, изменять порядок записей и т. д. Клиент может получить указатель интерфейса иуиаутоматионпроксифакторимаппинг , вызвав метод Иуиаутоматион::P роксифакторимаппинг .

Таблица доступных прокси содержит интерфейс иуиаутоматионпроксифакторентри для каждого прокси-сервера. Каждый иуиаутоматионпроксифакторентри указывает иуиаутоматионпроксифактори и класс элемента управления, который обслуживает прокси-сервер, и определяет способ обработки событий.

Таблица прокси-серверов представлена интерфейсом иуиаутоматионпроксифакторимаппинг , который можно получить из свойства Иуиаутоматион::P роксифакторимаппинг . Приложение может использовать методы иуиаутоматионпроксифакторимаппинг для добавления и удаления прокси-серверов. Чтобы создать новую запись для добавления в эту таблицу, используйте иуиаутоматион:: креатепроксифакторентри , чтобы получить интерфейс, а затем используйте методы иуиаутоматионпроксифакторентри для определения соответствующего класса элемента управления и поведения прокси-сервера.

Создание поставщика автоматизации пользовательского интерфейса Client-Side (прокси)

Рекомендации программиста поставщика модели автоматизации пользовательского интерфейса