КЛАССЫ СТРУКТУР АВТОМАТИЗАЦИИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА И ИНТЕРФЕЙСЫ Российский патент 2008 года по МПК G06F9/40 

Область техники

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

Предшествующий уровень техники

Продукты технологии поддержки существуют для оказания помощи пользователям компьютеров, которым требуется поддержка в сферах обучения, коммуникаций и доступа к информации, содержащейся в компьютерном программном обеспечении и представляемой посредством этого программного обеспечения. Аналогичным образом, существующие продукты автоматизированного тестирования и управляющие обслуживающие программы пользовательских интерфейсов также нуждаются в информации о пользовательском интерфейсе. В настоящее время эти продукты не имеют существенного источника информации о пользовательском интерфейсе (ПИ). От этих трех типов продуктов (клиентов) требуется, чтобы они откуда-либо имели необходимую поддержку для обеспечения выполнения ими следующих функций: (1) сбор информации о пользовательском интерфейсе приложения; (2) программным образом обнаружение и опрос элементов ПИ независимо от технологии, используемой для построения ПИ; (3) генерация ввода посредством клавиатуры и указателя (курсора) и (4) понимание того, какой тип поведения или функциональности доступен в текущий момент. В настоящее время отсутствует единая технология, которая обеспечивала бы продукту технологии поддержки (ТП) всех этих возможностей. Кроме того, современные продукты ТП не всегда совместимы со всеми технологиями графических операционных систем (ОС) и не имеют возможности отфильтровывать и координировать избыточные или вводящие в заблуждение уведомления централизованным способом. Дополнительным недостатком является то, что современные инфраструктуры автоматизации и обеспечения доступности не являются расширяемыми и поэтому требуют изменений на уровне ОС для добавления новых функциональных возможностей.

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

Современные системы позволяют продуктам ТП запрашивать уведомления о событиях на трех уровнях степени детализации: (1) для каждого элемента на рабочем столе; (2) в конкретном процессе (например, открытие текстового процессора); (3) для подпроцесса в конкретном процессе (множество объектов, выполняющих задачу в процессе). В современных условиях, когда клиент получает событие, он получает описатель (дескриптор, абстрактный идентификатор) окна для конкретного окна, в котором возникло событие, и другие биты информации для указания того, где возникло событие. Клиент может сделать перекрестный вызов из процесса для извлечения объекта ПИ, связанного с событием. При наличии этого объекта клиент может сделать дополнительные перекрестные вызовы из процесса для запроса информации об этом объекте. Если клиенту нужно пять частей информации, то клиент должен будет сделать пять перекрестных вызовов из процесса. Перекрестные вызовы из процесса чрезвычайно медленные, результатом чего являются высокие затраты на сбор информации ПИ с использованием доступной в настоящее время инфраструктуры. Этот тип известного сценария показан на фиг.8. Серверное приложение 12 запускает событие 6. Ядро 14 определяет, какие клиенты должны быть уведомлены и посылает уведомление 18 о событии к заинтересованному клиенту 10. Клиент 10 направляет запрос 16 из серверного приложения 12 через границу 2 процесса об объекте, относящемся к уведомлению 18 о событии. Серверное приложение 12 возвращает объект 20, и затем клиент может начать посылать запросы 16 на получение информации об управлении ПИ, который запустил событие. Серверное приложение 12 возвращает запрошенную информацию 20 через границу 2 процесса клиенту 10.

Другой имеющийся в настоящее время вариант позволяет загружать клиентский код как динамически подсоединяемую библиотеку (DLL) в рамках процесса. Этот вариант имеет ряд недостатков. Во-первых, он требует координации из системы для загрузки клиентского кода в процесс. Во-вторых, он обуславливает возникновение вопросов защиты, поскольку как только клиентский код загружен в процесс приложения, трудно ограничить собираемую им информацию. В-третьих, чтобы быть эффективным методом для клиента, он должен загружаться в каждый процесс в системе. Оптимальным образом, только доверительные клиенты должны загружаться в процесс другого приложения.

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

В настоящее время при поиске информации о пользовательском интерфейсе требуется продукт ТП для доступа к деревьям (древовидным схемам), присущим структуре конкретного ПИ. Соответственно, требуется множество деревьев для передачи информации о пользовательском интерфейсе для множества структур ПИ. Эти различные деревья могут содержать информацию, которая не представляет интереса или не видима для пользователя, такую как скрытые контейнерные объекты, которые управляют видимыми средствами управления ПИ, которыми манипулирует конечный пользователь. Поэтому существует потребность в едином объединенном дереве, имеющем только те узлы, которые представляют интерес для пользователя.

Требуется решение, которое учитывает потребности продуктов ТП, инструментальных средств автоматизированного тестирования и управляющих обслуживающих программ. Решение должно быть применимым для всех технологий графических ОС и должно обеспечить возможность доступа ко всем формам ПИ и компонентов ПИ.

Сущность изобретения

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

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

Еще в одном аспекте инструментальные средства провайдера включают в себя класс автоматизации стороны провайдера для обеспечения уведомлений о событиях клиенту и интерфейс автоматизации стороны провайдера для представления свойств пользовательского интерфейса. Инструментальные средства провайдера дополнительно включают в себя интерфейс исходных (необработанных) элементов для возврата информации, относящейся к конкретному релятивному элементу и контекстному интерфейсу исходных элементов для управления событиями и функциональными средствами, не относящимися к конкретному элементу.

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

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

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

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

Краткое описание чертежей

Настоящее изобретение подробно описано ниже со ссылками на иллюстрирующие чертежи, на которых представлено следующее:

Фиг.1 - блок-схема вычислительной системной среды, подходящей для использования настоящего изобретения;

Фиг.2 - блок-схема взаимодействия между системой обеспечения доступности, клиентской средой и серверной средой;

Фиг.3 - блок-схема, иллюстрирующая компоненты ядра системы обеспечения доступности;

Фиг.4(А)-4(D)- иллюстрации создания логического дерева из собственных элементов;

Фиг.5 - блок-схема, иллюстрирующая последовательность процедур построения логического дерева;

Фиг.6 - диалоговое окно и его компоненты, образующие логические элементы;

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

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

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

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

Фиг.11 - известная система для уведомления о событиях.

Детальное описание изобретения

Примерная операционная среда

На фиг.1 представлен пример среды 100 вычислительной системы, на которой может быть реализовано настоящее изобретение. Среда 100 вычислительной системы является лишь примером подходящей вычислительной среды и не предполагает никаких ограничений объема использования или функциональных возможностей изобретения. Вычислительная среда 100 не должна интерпретироваться как имеющая какую-либо зависимость или требование связи с каким-либо одним компонентом или комбинацией компонентов, показанных в составе приведенной для примера операционной среды 100.

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

Как показано на фиг.1, приведенная для примера система 100 для реализации изобретения, включает в себя универсальное вычислительное устройство в форме компьютера 110, включающего в себя блок 120 обработки, системную память 130 и системную шину 121, которая связывает различные системные компоненты, включая системную память, с блоком 120 обработки.

Компьютер 110 в типовом случае включает в себя множество считываемых компьютером сред (носителей). К примеру, но не в качестве ограничения, считываемые компьютером носители могут содержать компьютерные носители записи и коммуникационную среду. Системная память 130 включает в себя компьютерные носители записи в форме энергозависимых и энергонезависимых носителей, таких как постоянная память (ROM, ПЗУ) 131, оперативная память (RAM, ОЗУ) 132. Базовая система ввода/вывода (BIOS) 133, содержащая базовые подпрограммы, которые способствуют переносу информации между элементами в компьютере 110, например, при запуске, в типовом случае сохранена в ПЗУ 131. ОЗУ 132 в типовом случае содержит данные и/или программные модули, которые непосредственно доступны и/или обрабатываются блоком 120 обработки. В качестве примера, но не ограничения, на фиг.1 показаны операционная система 134, прикладные программы 135, другие программные модули 136 и программные данные 137.

Компьютер 110 может также включать в себя другие съемные/ несъемные, энергозависимые/энергонезависимые компьютерные носители записи. Например, на фиг.1 показан дисковод 141 жестких дисков для считывания с несъемного, энергонезависимого магнитного носителя и записи на него, дисковод 151 магнитных дисков для считывания со съемного энергонезависимого магнитного диска 152 и записи на него, и дисковод 155 оптических дисков для считывания со съемного энергонезависимого оптического диска 156 или записи на оптический диск, такой как, например, ПЗУ на компакт-диске (CD-ROM) или иные оптические носители записи. Другие съемные и несъемные, энергозависимые и энергонезависимые компьютерные носители записи, которые могут быть использованы в приведенной для примера операционной среде, включают в себя, не ограничиваясь указанным, кассеты на магнитных лентах, карты флэш-памяти, DVD, цифровые видео магнитные ленты, твердотельные ОЗУ, твердотельные ПЗУ и т.п. Дисковод 141 жестких дисков в типовом случае соединен с системной шиной 121 посредством интерфейса несъемной памяти, такого как интерфейс 140, и дисковод 151 магнитных дисков и дисковод 155 оптических дисков соединены с системной шиной 121 в типовом случае посредством интерфейса съемной памяти, такого как интерфейс 150.

Дисководы и связанные с ними считываемые компьютером носители, описанные выше и показанные на фиг.1, обеспечивают хранение считываемых компьютером команд, структур данных, программных модулей и других данных для компьютера 110. На фиг.1, например, показано, что дисковод 141 жесткого диска хранит операционную систему 144, прикладные программы (приложения) 145, другие программные модули 146 и программные данные 147. Заметим, что эти компоненты могут быть теми же самыми или отличающимися от операционной системы 134, прикладных программ 135, других программных модулей 136 и программных данных 137. Операционная система 144, прикладные программы 145, другие программные модули 146 и программные данные 147 обозначены отличающимися ссылочными позициями для иллюстрации того, что они, как минимум, являются другими копиями. Пользователь может вводить команды и информацию в компьютер 110 посредством устройств ввода, например, клавиатуры 162 или указательного устройства 161, обычно называемого мышью, трекболом или сенсорной панелью. Другие устройства ввода (не показаны) могут включать в себя джойстик, игровую панель, спутниковую параболическую антенну, сканер и т.п. Эти и другие устройства ввода часто соединяются с блоком 120 обработки через интерфейс 160 пользовательского ввода, связанный с системной шиной, но могут быть соединены и посредством других интерфейсов и структур шин, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB) и т.д. Монитор 191 или иное устройство отображения также соединено с системной шиной 121 через интерфейс, например, такой как видео интерфейс 190. Кроме монитора компьютеры также могут включать в себя другие периферийные устройства вывода, например, громкоговорители 197 и принтер 196, которые могут быть соединены через интерфейс 195 устройств вывода.

Компьютер 110 согласно настоящему изобретению может работать в сетевой среде с использованием логических соединений с одним или более удаленными компьютерами, такими как удаленный компьютер 180. Удаленный компьютер 180 может представлять собой персональный компьютер (ПК) и в типовом случае включает в себя многие или все из элементов, описанных выше применительно к компьютеру 110, хотя на фиг.1 показано только устройство 181 памяти. Логические соединения, показанные на фиг.1, включают в себя локальную сеть (LAN) 171 и глобальную сеть (сеть широкого охвата - WAN) 173, но могут включать в себя и другие сети.

При использовании в сетевой среде локальной сети (LAN) компьютер 110 соединяется с локальной сетью 171 через сетевой интерфейс или адаптер 170. При использовании в сетевой среде глобальной сети (WAN) компьютер 110 в типовом случае включает в себя модем 172 или иное средство для установления связи в глобальной сети 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, соединен с системной шиной 121 через интерфейс 160 пользовательского ввода или иной подходящий механизм. В сетевой среде программные модули, изображенные по отношению к компьютеру 110, или их части могут быть сохранены в удаленном устройстве памяти. В качестве примера, но не ограничения, фиг.1 иллюстрирует удаленные прикладные программы 185 как хранящиеся в устройстве памяти 181. Следует иметь в виду, что показанные сетевые соединения приведены для примера, и что могут быть использованы и другие средства установления канала связи между компьютерами.

Хотя многие другие внутренние компоненты компьютера 110 не показаны, специалистам в данной области техники должно быть понятно, что такие компоненты и взаимные соединения хорошо известны. Соответственно, дополнительные детали, относящиеся к внутренней конструкции компьютера 110, не требуют раскрытия во взаимосвязи с настоящим изобретением.

Структура системы обеспечения доступности

Как показано на фиг.2, система 200 обеспечения доступности взаимодействует с клиентской средой 300 и серверной средой 400. Система 200 обеспечения доступности может быть реализована в компьютерной среде 100, описанной выше со ссылкой на фиг.1. Система 200 обеспечения доступности включает в себя интерфейс 220 обеспечения доступности клиентской стороны для обеспечения взаимодействия с клиентом 300, интерфейс 230 обеспечения доступности серверной стороны для обеспечения взаимодействия с серверной стороной 400 и ядро 201 системы обеспечения доступности. Система 200 обеспечения доступности согласно изобретению обеспечивает новые интерфейсы прикладных программ (ИПП), включающие в себя ИПП 305 клиентской стороны и ИПП 440 стороны провайдера для программного доступа к пользовательскому интерфейсу (ПИ). Система 200 обеспечения доступности позволяет приложениям обеспечивать доступность к ним самим и любым компонентам, которые они используют.

Клиентская среда 300 предпочтительно включает в себя продукт технологии поддержки (ТП) или инструментальное средство тестирования автоматизированного ПИ. Серверная сторона 400 может реализовывать множество различных технологий, как показано на фиг.2. Серверная система 410 включает в себя адаптер 412 и ядро 414, которые могут быть найдены в первом типе ПИ. Серверная система 420 включает в себя компонент-посредник 422 и средства управления 424, которые могут быть найдены во втором типе ПИ, таком как ПИ Win32, доступный в продуктах операционной системы Microsoft компании Microsoft Corporation (Redmond, Washington). Серверная система 430 включает в себя адаптер 432 и внутренние операционные модули 434, которые могут быть найдены в альтернативном третьем типе ПИ.

Как показано на фиг.3, механизм 210 событий, который включен в состав системы 200 обеспечения доступности, основывается на клиенте 202 автоматизации ПИ и сервере 204 автоматизации ПИ для обеспечения взаимодействия с клиентской средой 300 и серверной средой 400. Клиент 202 автоматизации ПИ и сервер 204 автоматизации ПИ описаны более детально ниже со ссылками на механизм 210 событий согласно изобретению. Система 200 обеспечения доступности, соответствующая изобретению, обеспечивает клиенту (продукту ТП) 300 следующие возможности: (1) сбор информации о пользовательском интерфейсе приложения; (2) программным образом обнаружение и опрос элементов ПИ независимо от технологии, используемой для построения ПИ; (3) генерация ввода посредством клавиатуры и указателя (курсора) и (4) понимание того, какой тип поведения или функциональности доступен в текущий момент. Система 200 обеспечения доступности позволяет приложениям обеспечивать доступность к ним самим и любым компонентам, которые они используют. Структура, показанная на фиг.2 и 3, обеспечивает реализацию различных основных аспектов системы 200 обеспечения доступности, включая следующее: (1) логическое дерево ПИ; (2) шаблоны управления; (3) механизм событий; (4) свойства и (5) ИПП клиентской и серверной стороны. Все эти аспекты описаны ниже более подробно.

Логическое дерево 222 доступа ПИ

Интегральным компонентом системы 200 обеспечения доступности является логическое дерево 222, пример которого приведен на фиг.4(D). Дерево 222 включено в интерфейс 220 обеспечения доступности клиентской стороны.

Логическое дерево 222 является отфильтрованным представлением базовой структурной иерархии элементов ПИ, а не отдельным деревом, которое должно быть реализовано разработчиком средств управления или приложения. Вместо этого, оно вычленяет ряд хорошо определенных свойств, представляющих интерес и не представляющих интереса, которые показывают, должен ли структурный элемент быть представлен в логическом дереве 222. Ядро 201 системы обеспечения доступности потребляет эту информацию для выработки отфильтрованного логического дерева 222 ПИ, которое, в свою очередь, представляется в продукты ТП или в скрипт (сценарий) тестирования.

Логическое дерево 222 является деревом элементов, каждый из которых представляет управление, элемент в управлении, структуру группирования, которая может быть диалогом, панелью, фреймом. Структура логического дерева 222 должна представлять ПИ приложения, как это воспринимается пользователем (даже если средства управления в действительности реализованы с использованием другой базовой структуры). Дерево должно быть стабильным во времени. Пока приложение представляется одинаковым для пользователя, логическое дерево 222, представляющее это приложение, должно оставаться тем же самым, даже если детали реализации приложения «за сценой» изменились. Собственные элементы, которые существуют по структурным причинам или по причинам реализации, такие как окно "ShDocView" в продуктах ОС Microsoft, не должны появляться в этом дереве, поскольку пользователь не воспринимает их.

Логическое дерево 222 является единым деревом, построенным из множества фрагментов, которое может унифицировать множество различных процессов таким образом, что они являются одинаковыми для клиента. Логическое дерево 222 обеспечивает групповой поиск и способно получать значение для списка свойств. За время, в которое пользователь обычно должен был осуществлять перекрестный вызов из процесса для запроса значений, система 200 обеспечения доступности уже осуществит их выборку за счет использования логического дерева 222.

Вместо формирования на одном этапе, как в известных системах, логическое дерево 222 формируется из фрагментов, которые используются для формирования исходного дерева. Как показано на фиг.5, три главные процедуры формируют логическое дерево 222. В процедуре 72, система обеспечения доступности 200 обнаруживает собственные элементы базовых технологий и получает собственные деревья, показанные на фиг.4(А). В процедуре 74 система обеспечения доступности объединяет собственные элементы для формирования исходного дерева 20, как показано на фиг.4(В). И, наконец, в процедуре 76 логическое дерево 222 получается путем скрытия не представляющих интерес компонентов исходного дерева 20, как показано на фиг.4(D).

Фиг.4(А) иллюстрирует два собственных дерева 10 и 14, которые формируются из собственных элементов базовых технологий, таких как ПИ Win32 или другие доступные ПИ. Собственное дерево 10 включает в себя родительский узел 11 и множество узлов-потомков 12, имеющих различные соотношения друг с другом. Аналогичным образом, собственное дерево 14 включает в себя родительский узел 15, имеющий множество дочерних узлов 16. Дочерние узлы 16 могут быть описаны как узлы-братья (объекты, имеющие общий родительский узел).

Как показано на фиг.4(В), собственные деревья 10 и 14 могут быть объединены для формирования исходного дерева 20. Исходное дерево 20 включает в себя родительский узел 21, имеющий два дочерних узла 22 и 30. Дочерний узел 22 имеет узлы-потомки 23-29, а дочерний узел 30 имеет узлы-потомки 31-33. Это исходное дерево 20 является комбинацией собственных деревьев 10 и 14, причем узлы собственного дерева 10 формирует узлы 22-29, а узлы собственного дерева 14 формируют узлы 30-33.

Посредством способа, в общем виде показанного на фиг.4(С) и 4(D), исходное дерево 20 преобразуется в логическое дерево 222. Для перехода от исходного дерева 20 к логическому дереву 222, разработчик может ввести подсказки в исходное дерево. Разработчик может маркировать узлы в исходном дереве 20 как «скрыть себя», или «скрыть себя и дочерние узлы», или «скрыть узлы-потомки узла» и т.д. Разработчик также может сдвинуть узлы в стороны или поместить узлы перед дочерними узлами. Такие подсказки и модификации в исходном дереве 20 используются для формирования логического дерева 222. Например, на фиг.4(С), разработчик пометил узлы 24-26 и 33 исходного дерева 20 как не представляющие интереса, как указано блоками 40 и 41. В типовом случае, узлы, которые содержат элементы, которые не будут видимы для пользователя, маркируются как неинтересные. Узлы, связанные с видимым ПИ, в типовом случае рассматриваются как представляющие интерес и будут включены в логическое дерево 222 для использования клиентом 300 ТП. Как показано на фиг.4(D), узлы, маркированные как не представляющие интереса, не включаются в логическое дерево 222.

Система 200 обеспечения доступности использует логическое дерево 222 для нахождения информации об элементах управления. Известные системы не имели возможности действовать в пределах их деревьев. Навигация по логическому дереву 222 может осуществляться на основе предпочтений клиента 300, и оно может обеспечивать информацию относительно используемого приложения серверной стороны.

Логическое дерево 222 является единым объединенным деревом, которое является логическим представлением ПИ и сформировано в форме, которая включает в себя только элементы, представляющие интерес для клиента 300. Соответственно, вместо того чтобы вынуждать продукты ТП фильтровать структурную иерархию элементов ПИ и делать приблизительные оценки на модели, представляемой конечному пользователю, логическое дерево 222 представляет иерархию, которая близко отображает структуру, представляемую конечному пользователю. Это в значительной степени упрощает задачу продукта ТП описания ПИ для пользователя и помогает пользователю взаимодействовать с приложением.

Поскольку это логическое дерево 222 ПИ является фундаментальной частью системы 200 обеспечения доступности, все другие компоненты системы 200 обеспечения доступности предназначены для работы исходя из логического дерева 222. Например, фиг.6 показывает простое диалоговое окно 60, которое представляется имеющим очень простую структуру. Однако при рассмотрении с учетом существующей технологии обеспечения доступности структура этого дерева является очень сложной. Оно содержит 264 объекта, которые должны быть отфильтрованы продуктом ТП, чтобы обнаружить те, которые имеют смысл для конечного пользователя. С использованием системы 200 обеспечения доступности и ее поддержки для логического дерева 222 ПИ, разработчик, имеющий это диалоговое окно 60, может установить новые свойства для представления следующей структуры, показанной на фиг.6, продуктам 300 ТП.

Как показано на фиг.6, для диалога «выполнить», разработчик может указать в качестве интересующих элементов графику 62 плавающих окон и текст «Введите имя программы, папки, документа или интернет-ресурса, и окна будут открыты для вас» в 63. Разработчик может также указать в качестве интересующего комбинированное окно 64, включающее в себя блокнот, слово, калькулятор и т.д. и кнопки «ОК» 65, «отменить» 66 и «просмотреть» 67. Это обеспечивает разработчику дешевый механизм маркировки своей иерархии элементов и тем самым формирования логического представления своего ПИ приложения посредством системы 200 обеспечения доступа ПИ. Каждый из показанных признаков может быть представлен узлом, который имеет определенное взаимоотношение с каждым другим узлом в логическом дереве 222. Это логическое представление предоставляет непосредственную выгоду для подразделения тестирования и для продуктов ТП или клиентов 300.

Хотя логическое дерево 222 представляет в конечном счете интерес для пользователя, дерево 20 логических элементов также выполняет некоторые важные функции. В то время как логическое дерево 222 содержит только элементы, к которым может иметь отношение пользователь, дерево 20 исходных элементов содержит узлы, такие как 22, которые представляют структуру реализации базовой структуры. Для фрагмента ПИ Win32, например, это дерево должно содержать узлы, которые представляют HWND (узлы аппаратных средств). В некоторых аспектах дерево 22 исходных элементов является «домом на полпути» между деревом 222 логических элементов и деревьями собственных элементов базовой структуры. Дерево 22 исходных элементов используется как основа для построения дерева 222 логических элементов, и именно в нем собственные элементы впервые встраиваются в систему.

Дерево 20 исходных элементов может также использоваться для отладки и тестирования. Это полезно для точной локализации неисправностей или описания, где находится конкретный узел, вызывающий проблемы. Функциональные возможности на базовом узле исходных элементов включают следующее: способы навигации по дереву исходных элементов, способ перехода к конкретному логическому элементу (если он существует); определяющая свойство «строка отладки» для этого элемента, например, "HWND 0x483FE" для узлов HWND и другие способы «скрытой инфраструктуры». Эти другие способы обеспечивают возможность тестирования и локализации совпадений, событий и представления свойств, которые базовая структура может легко обеспечить (например, сфокусировано (приведено в активное состояние), разрешено).

Дерево 22 исходных элементов содержит узлы 22-33, которые представляют элементы различных механизмов визуализации. Дерево исходных элементов используется в качестве начального пункта для механизмов визуализации, чтобы встраиваться в систему 200 обеспечения доступности, и формируется из мелких объектов адаптера, которые адаптируют собственные элементы такие, как HWND из Win32, для объединенного логического дерева 222. Оно дополнительно используется для обработки переходов в ведущую систему, где одна технология использует другую. Поскольку дерево 20 исходных элементов является основой, на которой строится логическое дерево 222, оно может быть использовано для проверки того, что логическое дерево 222 завершено и соединено и может быть использовано для проверки на неучтенные элементы. Дерево 20 исходных элементов может также быть использовано для других инфраструктурно-подобных задач, таких как обеспечение идентификаторов некоторых базовых элементов и обеспечение свойств некоторых обеспечиваемых базовой структурой элементов, таких как «сфокусировано», «разрешено», «локализация».

Дерево 20 исходных элементов не является основным источником информации для продуктов ТП или клиентов 300, не используется для логической навигации и не предоставляется конечным пользователям. Дерево 20 исходных элементов также не может быть использовано для определения положения элемента в дереве, чтобы оно могло быть возвращено в некоторый будущий момент времени в будущем. Все эти функции выполняет дерево 222 логических элементов.

Дерево 20 исходных элементов может в типовом случае строиться механически из исходных элементов базовой технологии визуализации (HWND, Элементы) без знания представляемых логических элементов. Поэтому оно может быть использовано для поиска исходных элементов, которые не были учтены в логическом дереве 222. Дерево 20 исходных элементов является полезным инструментальным средством отладки и диагностики, так как обеспечивает возможность описания через «стек дампа» местоположения определяемого узла. Кроме того, известные системы основывают свои деревья на специфических для программного кода критериях и вызывают трудности в реализации с различными технологиями. Предложенный подход использует обобщенный абстрактный тип «исходного элемента», который может быть реализован посредством или исходя из любой базовой технологии визуализации.

Для получения дерева исходных элементов вызов корня исходного элемента приводит к получению элемента рабочего стола, проверенного, чтобы убедиться в том, что его предшественником является NULL, и что все другие узлы содержат его как своего конечного предшественника. Для получения других элементов вызов метода получения исходного элемента из конкретной точки возвращает элемент с использованием действительных координат окна. После получения дерева исходных элементов оно может быть проверено и верифицировано путем проверки элементов (родительские узлы, одноранговые узлы, дочерние узлы).

В процессе работы клиент 300 может перемещаться по дереву 20 исходных элементов с использованием соотношений таких, как родительский узел, следующий одноранговый узел, предыдущий одноранговый узел, первый дочерний узел, последний дочерний узел и т.д. Клиент 300 затем может осуществить переход от исходного элемента к соответствующему логическому элементу в логическом дереве 222.

Механизм событий

Если клиенту желательно получать информацию о событиях, клиент 300 может зарегистрироваться посредством клиента 202 автоматизации ПИ, как показано на фиг.3, для получения информации. Клиент 300 определяет информацию объекта, которую ему желательно получать, где ему желательно получать информацию, а также список свойств, которые он хочет получать. Клиентский запрос поступает клиенту 202 автоматизации ПИ. Клиент 202 автоматизации ПИ может контролировать любой процесс на рабочем столе. Сервер 204 автоматизации сервера отслеживает то, что требуется клиентам 300, и знает, как перейти назад к клиенту 202 автоматизации ПИ. Клиент 202 автоматизации ПИ сообщает механизму 206 ПИ об интересах клиента, так что механизму 206 ПИ известно, когда сообщать серверу 204 автоматизации ПИ о событии. Механизм ПИ не должен использовать подсказки клиента, но может вместо этого выбирать вариант всегда уведомлять сервер ПИ автоматизации ПИ о событиях или уведомлять сервер автоматизации ПИ только тогда, когда клиент ожидает какие-либо события. Подсказка полезна, если механизм ПИ желает включить уведомление сервера автоматизации ПИ, только если имеется клиент, ожидающий событие. Механизм ПИ должен делать это во избежание снижения быстродействия ПИ и во избежание загрузки модулей программного кода, которые ему в ином случае не требуются.

Механизм 206 ПИ затем информирует сервер 204 автоматизации ПИ о событии ПИ. Сервер 204 автоматизации ПИ возвращает запрошенный логический элемент клиенту 300 и посылает информацию клиенту 300, включая свойства события, который запросил клиент 300. Сервер 204 автоматизации ПИ принимает решение, что информация находится в рамках запроса клиента или только формирует логический элемент, если информация представляет интерес. Формирование логического элемента включает в себя предварительную выборку на стороне сервера автоматизации ПИ, набор свойств, которые клиент указал как желательные ему для использования при обработке события. Например, сервер 204 автоматизации ПИ может обнаружить логический элемент для комбинированного окна. Соответствующий объем поиска (контекст) может соответствовать комбинированному окну или его дочерним элементам. Клиент 300 может запросить зависимости от дочерних/родительских элементов, чтобы определить контекст на этапе регистрации.

После того как сервер 204 автоматизации ПИ определяет, находится ли информация в пределах запрошенного контекста, он строит логический элемент. Клиент 202 автоматизации ПИ обслуживает клиента 300 путем опроса целевых приложений, принимающих запрошенную информацию от сервера 204 автоматизации ПИ и маршрутизирующих объекты в надлежащую область у клиента 300.

Сервер 204 автоматизации ПИ создается, когда клиент 300 регистрируется для приема уведомлений о событиях. В качестве примера, механизм 206 ПИ выполняет приложение текстовой обработки Microsoft Word. Клиент 300 зарегистрировался на получение уведомлений при изменении свойства имени. Регистрация клиента вызывает создание сервера 204 автоматизации и клиента. Регистрация клиента также выдает подсказку механизму 206 запустить уведомление сервера 204 автоматизации ПИ для свойства имени. Механизм 206 ПИ не получает информации контекста. Механизм 206 ПИ вызывает один из ИПП серверной стороны. Механизм 206 ПИ определяет следующее: (1) какое свойство изменилось; (2) новое значение свойства; и (3) возможно, старое значение. Сервер 204 автоматизации ПИ создается на основе событий, представляющих интерес для клиента 300, и поэтому знает события, свойства, клиентов, объем интересов, так что он знает, заинтересован ли клиент 300 в созданном логическом элементе. Если более одного клиента 300 зарегистрировалось для получения информации о событиях у конкретного сервера 204 автоматизации ПИ, и клиенты 300 зарегистрировались в отношении одного и того же события и запросили о массовой выборке для свойств при возвращении логического элемента, то, когда сервер 204 автоматизации ПИ посылает событие назад к клиенту 300, каждый клиент 300 будет получать массив запрошенной массовой выборки свойств, возвращаемой с логическим элементом.

Для каждого ожидающего клиента 300 сервер 204 автоматизации ПИ уведомляет клиента 300, посылая клиенту логический элемент, связанный с событием. Сервер 204 автоматизации ПИ создает только один логический элемент. Это является усовершенствованием по сравнению с современной технологией, согласно которой от каждого клиента 300 требовалось бы запросить его собственную копию объекта, который является источником события.

Если механизм 206 ПИ не использует подсказку клиента автоматизации ПИ, когда клиенты регистрируются для получения информации о событиях, механизм 206 ПИ может запросить сервер автоматизации ПИ, имеются ли какие-либо ожидающие клиенты 300 системы обеспечения доступности, и если ни один не находится в состоянии ожидания информации событий, то можно избежать выполнения задачи создания информации и посылки ее серверу 206 автоматизации ПИ. Например, модуль считывания экрана является клиентом 300 и определяет, где ему желательно получать информацию, объект изменения фокуса (активности) получаемых событий, и конкретный список свойств, представляющих интерес. Механизм 206 ПИ получает подсказку и знает, что ему следует посылать информацию о событиях в сервер 204 автоматизации ПИ. После обнаружения изменения фокуса механизм 206 ПИ уведомляет сервер 204 автоматизации ПИ. Сервер 204 автоматизации ПИ осуществляет преобразование в хорошо известный интерфейс и посылает информацию о событии и объект клиенту 202 автоматизации ПИ. Клиент 202 автоматизации ПИ маршрутизирует объект в соответствующую область у клиента 300.

Вышеописанные компоненты обеспечивают усовершенствование по сравнению с известными системами за счет исключения центрального хранилища в ядре для событий. Вместо этого, сервер 204 автоматизации ПИ знает всех клиентов, заинтересованных в получении информации о контексте, в котором он выполняется. Исключение хранилища ядра также создает более равноправное (одноранговое) взаимодействие, поскольку сервер 204 автоматизации ПИ выполняет функцию, ранее выполнявшуюся в ядре. Система 200 обеспечения доступности согласно изобретению дает клиенту 300 возможность определить, что ему желательно видеть, так что фильтрация выполняется на серверной стороне с использованием сервера 204 автоматизации ПИ.

На фиг.7 показана блок-схема, иллюстрирующая процедуру, связанную с регистрацией для получения информации о событиях и способом уведомления. На этапе 80 клиент 300 запрашивает уведомление о событиях. На этапе 82 клиент 202 автоматизации ПИ посылает запрос серверу 204 автоматизации ПИ. На этапе 84 клиент автоматизации ПИ сообщает механизму 206 ПИ, что ему желательно уведомление. На этапе 86 сервер 204 автоматизации ПИ получает уведомление от механизма 206 ПИ. На этапе 88 сервер 204 автоматизации ПИ фильтрует полученную информацию. Если на этапе 90 обнаружено, что полученная информация не представляет интереса, то сервер 204 автоматизации ПИ отклоняет эту информацию и продолжает ожидать уведомления на этапе 92. Альтернативно, если на этапе 90 обнаружено, что информация представляет интерес, то сервер 204 автоматизации ПИ создает логический элемент и посылает его на этапе 94 клиенту 202 автоматизации ПИ. На этапе 96 клиент 202 автоматизации ПИ помещает полученную информацию в надлежащую позицию у клиента 300.

Механизм 210 событий системы 200 обеспечения доступности позволяет клиенту 300 регистрироваться для получения уведомлений о событиях относительно изменений свойств в ПИ, изменений дерева в структуре управления, о мультимедийных событиях и связанной с этим информации. Без этих возможностей клиенты 300 должны непрерывно опрашивать все элементы ПИ в системе, чтобы отслеживать, изменилась ли какая-либо информация, структура или состояние. Механизм 210 событий системы 200 обеспечения доступности также позволяет клиенту 300 получать уведомления о событиях с прерыванием основного процесса, запрашивать возвращения набора свойств с уведомлением о событии, регистрироваться для получения уведомления о событиях по множеству элементов.

Механизм 210 событий предоставляет: интерфейсы, которые продукт ТП или тестовое приложение использует для регистрации относительно событий; интерфейсы, которые продукт ТП реализует на объектах, используемых для приема уведомлений о событиях; и интерфейсы, которые средство реализации элемента управления использует для уведомления механизма событий о событиях ПИ. Механизм 210 событий используется для обеспечения возможности продуктам ТП и тестовым приложениям получать события независимо от механизмов ПИ, используемых для визуализации ПИ, и позволяет продуктам ТП и тестовым приложениям отслеживать окна приложений высокого уровня и фокусировать (активизировать) без учета базовой технологии.

Если применимо, события связываются с логическими элементами из дерева 222 логических элементов приложения. Если логические элементы не применимы, события связываются со считываемой оператором (человеком) строкой или другим хорошо известным объектом, который представляет источник события. Механизм 210 событий обеспечивает фильтрацию на основе вводимых пользователем предпочтений в процессе регистрации на уведомление о событиях. С использованием фильтруемых клиентом предпочтений в сервере, перед созданием связанных с событием данных и посылки их через процесс клиенту, механизм 210 событий внутренним присущим ему образом улучшает внепроцессные характеристики за счет сокращения числа вызовов из процесса. Механизм 210 событий обеспечивает способ определения свойств логического элемента, которые представляют интерес для события в процессе регистрации на уведомления о событиях. Это дополнительно снижает количество вызовов из процесса. Механизм 210 событий может наращиваться, не требуя значительных изменений операционной системы (ОС). Хотя механизм 210 событий может быть реализован с использованием управляемого программного кода, неуправляемые приложения могут получать доступ к нему посредством возможности взаимодействия на основе COM (модель компонентных объектов Microsoft).

Механизм 210 событий может поддерживать информируемость клиента о большом количестве типов событий. Одним типом события является событие окна высокого уровня. События окна высокого уровня относятся к меню, ниспадающим окнам комбинированного окна и любому признаку, имеющему рабочий стол в качестве предшественника (порождающего элемента). Другим типом события является событие фокусировки (активизации). Клиенты 300 часто требуют способа для отслеживания фокусировки. Дополнительные типы событий включают в себя события изменения свойств и события изменения логической структуры. События изменения свойств запускаются, когда изменяются свойства логических элементов. События изменения логической структуры запускаются, когда изменяется структура дерева логических элементов.

События также могут запускаться из шаблонов управления. События, запускаемые из шаблонов управления, должны быть наращиваемыми, и поэтому эти события идентифицируются посредством GUID (глобально уникального идентификатора). Любое значение GUID принимается при регистрации. Для любого нового шаблона управления события, которые он документирует, должны быть уникальными GUID. Может потребоваться модифицировать продукты ТП, чтобы отслеживать новые события шаблонов управления. Слушатель (процесс, обеспечивающий контроль) также должен имеет возможность определять контекст этих событий. Например, для направленного тестирования может оказаться желательным ограничивать эти события конкретным приложение или управлением в пределах приложения. Шаблоны управления определяют, каким является источник, а потребителю события может оказаться необходимым ссылаться на ту часть документации, чтобы знать, как использовать элемент источника и объект аргумента события.

Другим типом события является мультимедийное событие. Мультимедиа может включать в себя звук, видео и анимацию. Методы должны поддерживать мультимедийные события и уведомлять клиента о действиях, включающих «остановка», «пауза», «быстрая перемотка вперед», «перемотка», «приглушение звука». Простые звуковые события могут обрабатываться отдельно от мультимедийных событий. Простые звуковые события представляют простые, имеющие короткую длительность звука, которые предназначаются для сообщения пользователю о некотором событии, ином, чем собственно звук. Простые звуковые события могут включать в себя следующее: звук, проигрываемый при поступлении новой электронной почты, звук, генерируемый, когда батарея в портативном компьютере разряжена, звук, воспроизводимый, когда окно сообщения отображается с пиктограммой типа восклицания.

Другим типом события является программируемое событие фокусировки. Программируемые события фокусировки появляются на рабочем столе, но остаются фоновыми (низкоприоритетными). Некоторыми примерами программируемых событий фокусировки являются следующие: окно справочной надписи (всплывающего пояснения), указывающее «Имеются новые обновления данных» в области уведомлений; мерцающая пиктограмма в панели задач для фонового приложения, для которого желательна фокусировка; пиктограмма принтера, появляющаяся и исчезающая в панели уведомлений, когда принтер запускается и завершает работу. Эти события могут наблюдаться в перекрытии с некоторыми другими категориями событий (мультимедиа может использовать события анимации, как это имеет место при программируемой фокусировке). Однако события будут разделяться на категории на основе того, что они переносят пользователю, а не на основе того, каким образом они это переносят.

ИПП 310 клиентской стороны и ИПП 440 стороны провайдера обеспечивают способы для уведомления о событиях, поддерживающего перечисленные выше типы событий. Эти способы описаны ниже со ссылками на фиг.8-10.

Шаблоны управления

Модель обеспечения доступности предоставляет уникальный подход к категоризации и предоставлению функциональных возможностей, поддерживаемых конкретным элементом ПИ или элементом управления. Вместо связывания функциональных средств с конкретным типом элементов управления (например, кнопка, окно редактирования или окно списка) как в предшествующем уровне техники, модель обеспечения доступности определяет набор общих шаблонов управления, каждый из которых определяет один аспект режима ПИ. Поскольку эти шаблоны не зависят друг от друга, они могут объединяться для описания полного набора функциональных возможностей, поддерживаемых конкретным элементом ПИ.

Например, вместо описания элемента в терминах его имени класса, такого как Кнопка, система 200 обеспечения доступности описывает его как поддерживающего вызываемый шаблон управления. Шаблон управления определяет структуру, свойства, события и методы, поддерживаемые элементом. Поэтому эти шаблоны не только позволяют клиентам запрашивать поведение средства управления, они также позволяют программным образом манипулировать со средством управления с использованием интерфейсов, предназначенных для конкретного шаблона. Например, шаблон КонтейнерВыбора обеспечивает методы для запроса о выбранных элементах, выбора или отмены выбора конкретного элемента или определения, поддерживает ли средство управления режимы одиночного или множественного выбора.

Шаблоны управления, определенные в настоящее время для системы 300 обеспечения доступности, включают в себя следующее: (1) Контейнер выбора, (2) Иерархия, (3) Возможность вызова, (4) Простая сетка, (5) Текст, (6) Значение, (7) Представление объекта, (8) Возможность прокрутки, (9) Возможность сортировки, (10) Рисование, (11) Иной контейнер.

Этот метод позволяет разработчикам средств управления реализовывать новый тип средства управления с использованием по-прежнему хорошо определенного подхода для представления его поведения продуктам ТП и тестовым сценариям. Если вводится новый тип поведения, то может быть определен новый шаблон управления для отображения требуемой функциональной возможности.

Продукты технологии поддержки и тестовые сценарии могут теперь записываться таким образом, чтобы понимать, как работать с каждым шаблоном, вместо каждого средства управления ПИ. Поскольку имеется намного меньше шаблонов управления, чем классов управления, этот метод минимизирует необходимый программный код. Этот метод также способствует получению более гибкой архитектуры, которая может эффективно опрашивать и манипулировать новыми средствами управления (если они поддерживают известные шаблоны управления). Следующая таблица обеспечивает некоторые примеры общих средств управления и шаблонов, которые они будут поддерживать.

Таблица 1Средство управленияРелевантные шаблоны управленияКнопкаВозможность вызоваФлаговая кнопка, переключательЗначениеОкно спискаКонтейнер Выбора, Возможность прокруткиКомбинированное окноКонтейнер Выбора, Возможность прокрутки, ЗначениеДревовидное представлениеКонтейнер Выбора, Возможность прокрутки, ИерархияПредставление спискомКонтейнер Выбора, Возможность прокрутки, Возможность сортировкиТекстовое окно, правкаЗначение, Текст, Возможность прокрутки

Более специальные интерфейсы должны использоваться для предоставления функциональных возможностей, связанных с общими шаблонами управления. Примерами этих шаблонов могут служить следующие: (1) контейнеры выбора управления; (2) контейнеры топологии сетки; (3) элементы ПИ, которые содержат значения; (4) пиктограммы, которые представляют объекты (файлы, электронная почта и т.п.) и (5) элементы ПИ, которые могут быть вызваны. В принципе эти шаблоны не связаны тесно с конкретными средствами управления, и различные средства управления могут реализовывать те же самые шаблоны. Например, окна списков, комбинированные окна и древовидное представление все реализуют шаблон «контейнер управления выбором». Некоторые средства управления могут реализовывать множество шаблонов, если это уместно: сетка выбора может реализовывать как шаблон «контейнер топологии сетки», так и шаблон «контейнер управления выбором».

Отсутствует одно свойство «роли», как в предшествующих приложениях. Вместо этого используются два отдельных механизма. Шаблоны управления определяют имеющиеся функциональные возможности средства управления, а локализуемое свойство считывания человеком обеспечивает имя типа средства управления, которое понятно для человека, например, «кнопка», «окно списка» и т.д.

Системные интерфейсы прикладных программ (ИПП)

На фиг.8 представлены детальные особенности ИПП 305 клиентской стороны в возможном варианте осуществления изобретения. ИПП 305 клиентской стороны могут включать в себя набор базовых классов 310. Базовые классы 310 могут включать в себя один или более классов 312 автоматизации, класс 312 логических элементов, класс 316 исходных элементов. ИПП 305 клиентской стороны дополнительно могут включать в себя один или несколько классов 320 шаблонов управления, класс 340 ввода и вспомогательный класс 350. Каждый из этих типов классов описан ниже.

Класс 312 автоматизации клиента обеспечивает методы автоматизации ИП для клиентов 300. Класс 312 автоматизации клиента содержит методы, которые не являются специфическими для любого элемента ПИ. Класс 312 автоматизации клиента может обеспечить метод для получения логического или исходного элемента из точки, дескриптора окна, или корневого элемента рабочего стола. Класс 312 автоматизации клиента дополнительно может обеспечить методы для нахождения логического элемента на основе критериев ввода. Класс 312 автоматизации клиента предпочтительно также включает в себя методы для регистрации и отмены регистрации для уведомления о событиях. Класс 312 автоматизации клиента предпочтительно также обеспечивает функции помощи для загрузки DLL посредников, извлечения локализованных имен свойств и шаблонов управления и выполнения сравнения элементов. Класс 312 автоматизации клиента также включает в себя методы для клиентов 300, обеспечивающие отслеживание событий. Некоторые методы, обеспечиваемые классом 312 автоматизации клиента, приведены в таблице ниже.

Таблица 2

В процессе работы, если клиенту 300 необходимо получить информацию для пользователя о приложении, клиент 300 отыскивает кнопку для нажатия и наблюдает текст на кнопке. Клиент 300 может вызвать метод, такой как метод нахождения логического элемента (FindLogicalElement), как показано в таблице 2. ИПП 305 клиентской стороны возвратит значение, которое ссылается на позицию в логическом дереве 222 интерфейса 220 клиентской стороны. Посредством логического дерева 222 система 200 обеспечения доступности предоставляет клиенту 300 абстрактное представление ИП независимо от используемого приложения. Абстрактная модель включает в себя структуры, свойства, события и функциональные возможности, которые, как можно ожидать, будут общими элементами окна списка, кнопки или иного компонента ПИ.

ИПП 305 клиентской стороны может дополнительно включать в себя класс 314 логических элементов. Класс 314 логических элементов может обеспечивать поля, методы и свойства для получения общих свойств элементов. Как изложено выше, логический элемент представляет элемент ПИ в логическом дереве 222, такой как ограничивающий прямоугольник, фокус (активное состояние элемента), разрешенный, выбираемая с помощью графического интерфейса точка, идентификатор на время исполнения и постоянный идентификатор и имя. Класс 314 логических элементов может также обеспечивать средства для навигации по элементам, таким как первый дочерний, последний дочерний, следующий одноранговый и родительский. Классы 314 логических элементов могут, таким образом, обеспечивать инструментальные средства для получения конкретного шаблона для элемента или получения всех шаблонов, которые поддерживаются элементом. Класс 314 логических элементов содержит поля, свойства и методы, используемые для данного элемента в дереве 222 логических элементов.

Таблица 3

ИПП 305 клиентской стороны дополнительно может включать в себя класс 316 исходных элементов. Класс 316 исходных элементов обеспечивает сходные методы для прохождения по дереву исходных элементов. Класс 316 исходных элементов содержит поля, свойства и методы, используемые для доступа к элементам исходного дерева.

Таблица 4

ИПП 305 клиентской стороны дополнительно включают в себя класс 340 вводов. Класс 340 вводов может быть использован для имитации ввода посредством мыши, клавиатуры и других типов вводов. Класс 340 вводов обеспечивает возможность программного ввода посредством методов ввода с помощью клавиатуры, пера, мыши. Примерный класс вводов показан в таблице ниже.

Таблица 5

ИПП 305 клиентской стоны дополнительно включают в себя классы 320 шаблонов управления автоматизации ПИ. Классы 320 шаблонов управления автоматизации ПИ могут представлять поля, свойства и методы для программного доступа к конкретным функциональным возможностям, открываемым логическим элементом. Классы 320 шаблонов управления автоматизации ПИ помогают пользователю взаимодействовать с шаблонами управления, определенными в система 200 обеспечения доступности ПИ. Например, метод шаблона окна приложения открывает функциональные возможности для работы программируемым образом с приложением. Функциональные возможности могут позволить упорядочить дочерние окна или определить местоположение логических элементов, которые представляют панели инструментов, меню, полосы прокрутки и системное меню в приложении.

Классы 320 шаблонов управления включают в себя класс шаблона окна приложения (ApplicationWindowPattern). Класс ApplicationWindowPattern открывает линию поведения и информацию, связанные в типовом случае с окном приложения верхнего уровня. Клиенты 300 могут использовать этот класс для мозаичного или каскадного упорядочения дочерних объектов многодокументного интерфейса (MDI) приложения, отыскать его кнопки на панели задач и обнаружить хорошо известные части его пользовательского интерфейса, такие как панели инструментов и меню. Приведенная ниже таблица иллюстрирует класс шаблона окна приложения ApplicationWindowPattern.

Таблица 6

Классы 320 шаблонов управления могут также включать в себя класс для расширения и сворачивания элементов, которые обеспечивают механизм, позволяющий показать и скрыть их содержание (Шаблон Растягивания Сворачивания - ExpandCollapsePattern). Класс ExpandCollapsePattern функционирует как класс упаковщика для шаблона Растягивания Сворачивания (ExpandCollapse). Класс ExpandCollapsePattern содержит поля, свойства и методы, используемые клиентом 300, для манипулирования содержанием, которое может быть расширено (отображено) и свернуто (скрыто). Приведенная ниже таблица иллюстрирует возможный вариант осуществления класса ExpandCollapsePattern.

Таблица 7

Классы 320 шаблонов управления могут также включать в себя класс шаблона элемента сетки (GridItemPattern), который позволяет клиентам 300 быстро определять, является ли обнаруженный элемент частью сетки. Если этот элемент является частью сетки, то класс GridItemPattern помогает определить, где в сетке находится этот элемент через координаты строки/столбца и его интервал. Класс GridItemPattern предпочтительно включает в себя поля, свойства и методы, используемые клиентом 300, для манипулирования элементом управления, который открывает функциональные возможности ячейки в сетке. Следующая таблица иллюстрирует класс GridItemPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 8

Классы 320 шаблонов управления могут также включать в себя шаблон элемента иерархии (HierarchyItemPattern), который представляет элементы, которые имеют иерархическое соотношение друг с другом, как элементы в средстве управления древовидным представлением. Класс HierarchyItemPattern содержит поля, свойства и методы, используемые клиентом 300 автоматизации для манипулирования средством управления, которое показывает иерархическое соотношение между элементами ПИ независимо от их взаимоотношения в логическом дереве 222. Следующая таблица иллюстрирует класс HierarchyItemPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 9

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

Таблица 10

Классы 320 шаблонов управления могут также включать в себя шаблон множества представлений (MultipleViewPattern), который служит в качестве класса упаковщика для элемента шаблона множества представлений MultipleViewPattern. Элемент шаблона множества представлений является элементом, который может переключаться между множеством представлений в одном наборе информации. Класс MultipleViewPattern содержит поля, свойства и методы, используемые клиентом 300 автоматизации для манипулирования элементом, который имеет функциональную возможность переключения между множеством представлений в одном и том же наборе информации. Приведенная ниже таблица иллюстрирует класс MultipleViewPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 11

Классы 320 шаблонов управления могут дополнительно включать в себя шаблон значения диапазона (RangeValuePattern), который открывает связанный набор свойств, которые отражают возможности средства управления управлять значением в конечном диапазоне. Класс RangeValuePattern переносит действительные для средства управления минимальное и максимальное значения и его текущее значение. Класс RangeValuePattern содержит поля, свойства и методы, используемые клиентом 300 автоматизации для получения текущего значения и диапазона значений для элемента. Приведенная ниже таблица иллюстрирует класс RangeValuePattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 12

Классы 320 шаблонов управления могут также включать в себя класс шаблона прокрутки (ScrollPattern), который представляет элементы ПИ, которые могут изменять свою просматриваемую область. Класс ScrollPattern содержит поля, свойства и методы, используемые клиентом 300 автоматизации для манипулирования элементом, который может изменять часть его видимой области путем прокрутки. Приведенная ниже таблица иллюстрирует класс ScrollPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 13

Классы 320 шаблонов управления могут также включать в себя шаблон выбора (SelectionPattern), который представляет контейнеры, которые управляют выбором. Связанный класс шаблона элемента выбора (SelectionItemPattern) содержит поля, свойства и методы, используемые клиентом 300, для манипуляции элементом, который может быть выбран или выбор которого может быть отменен. Следующие таблицы иллюстрируют примерный класс SelectionPattern и класс SelectionItemPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 14

Таблица 15

Классы 320 шаблонов управления могут также включать в себя класс шаблона сортировки (SortPattern). Класс SortPattern содержит поля, свойства и методы, используемые клиентом автоматизации для манипулирования элементом контейнера, который может сортировать свои подэлементы. Приведенная ниже таблица иллюстрирует класс SortPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 16

Классы 320 шаблонов управления могут также включать в себя класс шаблона значения (ValuePattern) для представления элементов ПИ, которые выражают значение. Класс ValuePattern содержит поля, свойства и методы, используемые клиентом 300 для манипулирования элементом, который имеет значение, связанное с ним. Приведенная ниже таблица иллюстрирует класс ValuePattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 17

Классы 320 шаблонов управления могут также включать в себя класс шаблона визуальной информации (VisualInformationPattern), который может быть использован для выражения информации об изображении или анимации, которые несут информацию для пользователя. Класс VisualInformationPattern содержит поля, свойства и методы, используемые клиентом 300 автоматизации для манипулирования элементом, который имеет изображение или анимацию, которые несут информацию для пользователя. Приведенная ниже таблица иллюстрирует класс VisualInformationPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 18

Классы 320 шаблонов управления могут также включать в себя класс шаблона окна (WindowPattern), который функционирует как класс упаковщика для шаблона окна. Класс WindowPattern содержит поля, свойства и методы, используемые клиентом 300 автоматизации для манипулирования окном на рабочем столе пользователя. Приведенная ниже таблица иллюстрирует класс WindowPattern в соответствии с возможным вариантом осуществления изобретения.

Таблица 19

ИПП 300 клиентской стороны могут также включать в себя вспомогательные классы 350. Вспомогательные классы могут включать в себя множество классов, которые представляют свойство, событие, и идентификаторы шаблонов, а также классы помощников для использования механизма событий и признаков вводов.

Вспомогательные классы 350 могут включать в себя класс идентификатора автоматизации (AutiomationIdentifier). Класс AutiomationIdentifier является базовым классом для основанных на идентичности идентификаторов объектов. Этот класс является эффективно абстрактным, так как создаются экземпляры только производных классов. Вспомогательные классы 350 могут дополнительно включать в себя класс события автоматизации (AutomationEvent), который представляет тип, используемый для идентификации событий в системе 200 обеспечения доступности. Вспомогательные классы 350 могут дополнительно включать в себя класс шаблона автоматизации (AutomationPattern), который представляет тип, используемый для идентификации шаблонов управления в системе 200 обеспечения доступности. Вспомогательные классы 350 могут дополнительно включать в себя класс свойства автоматизации (AutomationProperty), который представляет тип, используемый для идентификации свойств в системе 200 обеспечения доступности.

Вспомогательные классы 350 могут дополнительно включать в себя класс аргумента событий автоматизации (AutomationEventArgs), который представляет аргументы шаблона управления или настроенного события, используемые с событиями. Клиенты 300 получают экземпляр этого класса с настроенными событиями. AutomationEventArgs используется для доставки информации о событии автоматизации клиенту 300.

Вспомогательные классы 350 могут дополнительно включать в себя класс аргументов события изменения свойства автоматизации (AutomationPropertyChangedEventArgs), используемый с событиями ПИ. Клиенты 300 получают экземпляр этого класса с событиями изменения свойства. AutomationPropertyChangedEventArgs используется для доставки информации о событии изменения свойства клиенту 300.

Вспомогательные классы 350 могут также включать в себя класс аргументов события изменения логической структуры. Класс LogicalSrtuctureChangedEventArgs может использоваться с событиями ПИ для предоставления клиентам 300 экземпляра этого класса вместе с событиями изменений логического дерева. LogicalSrtuctureChangedEventArgs используется для доставки информации о событии изменения логической структуры клиенту 300.

Вспомогательные классы 350 могут также включать в себя класс аргументов события окна верхнего уровня (TopLevelWindowEventArgs), который может использоваться с событиями ПИ для предоставления клиентам 300 экземпляра этого класса вместе с настроенными событиями. TopLevelWindowEventArgs используется для доставки информации о событии окна верхнего уровня клиенту 300. Окно верхнего уровня является окном, порождающим окном которого является рабочий стол. Использование термина «открыто» указывает, что новое окно верхнего уровня предоставлено пользователю. Использование термина «закрыто» указывает, что окно верхнего уровня аннулировано.

Вспомогательные классы 350 могут также включать в себя класс аргументов событий загрузки дерева (TreeLoadEventArgs). Класс TreeLoadEventArgs является классом аргументов настроенного события, используемым с событиями ПИ. Клиенты 300 могут получать экземпляр этого класса вместе с событием загрузки дерева. TreeLoadEventArgs может быть использован для доставки информации о событии загрузки клиенту 300.

Вспомогательные классы 350 могут дополнительно включать в себя класс VKeys, который обеспечивает константы для методов, связанных с вводом. Вспомогательные классы 350 также могут включать в себя исключение NoClickablePointException (исключение невыбираемой с помощью графического интерфейса точки). Это исключение выводится, когда происходит ошибка в логическом элементе в выбираемой с помощью графического интерфейса точке. Ошибка может возникнуть, когда ограничивающий прямоугольник пуст, не имеет ширины или высоты, или логический элемент в этой точке изменился.

Вспомогательные классы 350 могут также включать в себя классы различной реализации для получения уведомлений о событиях. Класс аргументов события изменения фокуса (FocusChangedEventArgs) используется для доставки информации о событии изменения фокуса клиенту.

Как показано на фиг.9, ИПП 440 стороны провайдера включают в себя классы 442 автоматизации провайдера, интерфейсы 448 автоматизации провайдера и интерфейсы 450 исходных элементов провайдера. ИПП 440 стороны провайдера также могут включать в себя интерфейсы 460 управляющих элементов провайдера и вспомогательные классы 480. Вспомогательные классы 480 и 350 могут совместно использовать типы, предназначенные для использования и посылки информации, такие как идентификаторы свойств, идентификаторы событий, идентификаторы шаблонов и базовые типы, такие как класс, представляющий прямоугольник или точку. Другие свойства могут быть уникальными для вспомогательных классов 480 провайдера или для вспомогательных классов 350 клиента. Например, класс Vkeys может быть зарезервирован только как вспомогательный класс 350 клиента.

Классы 442 автоматизации провайдера предпочтительно включают в себя класс 502 способности к взаимодействию автоматизации провайдера (AutomationInteropProvider), как показано на фиг.10. Класс 502 AutomationInteropProvider может содержать методы, используемые системой 200 обеспечения доступности с реализациями автоматизации Win32 или третьей стороны. Класс 502 AutomationInteropProvider содержит свойства и методы, используемые реализациями автоматизации ПИ стороны провайдера Win32 или третьей стороны. Следующая таблица иллюстрирует класс 502 AutomationInteropProvider в соответствии с возможным вариантом осуществления изобретения.

Таблица 20

Класс 500 автоматизации провайдера является сходным классом, который содержит способы, которые могут быть использованы системой 200 обеспечения доступности с Клиентской Платформой Windows.

ИПП 440 стороны провайдера также включают в себя интерфейсы 448 автоматизации провайдера. Интерфейсы 448 автоматизации провайдера могут включать в себя интерфейс 447 обеспечения взаимодействия свойств автоматизации провайдера (IAutomationPropertyInteropProvider), который реализован провайдерами Win32 или третьей стороны для предоставления дополнительных свойств помимо свойств, которые система 200 обеспечения доступности предоставляет по умолчанию. Интерфейсы 448 автоматизации провайдера могут дополнительно включать в себя интерфейс 449 свойств автоматизации провайдера (IAutomationPropertyProvider). Этот интерфейс 449 подобен интерфейсу 447, но может быть реализован собственной Клиентской Платформой Windows для предоставления свойств помимо тех, которые обеспечиваются системой 200 обеспечения доступности по умолчанию.

Интерфейсы 450 исходных элементов провайдера могут включать в себя интерфейс 456 исходных элементов провайдера (IRawElementProvider). Интерфейс 456 IRawElementProvider определяет методы, которые реализованы Собственной Клиентской Платформой Windows, провайдером Win32 или третьей стороны и вызываются системой 200 обеспечения доступности для возврата относительных элементов, таких как первый дочерний элемент, последний дочерний элемент, следующий одноранговый элемент, и для возврата конкретных или всех собственных свойств и свойств автоматизации ПИ. Интерфейс 456 IRawElementProvider дополнительно возвращает объекты провайдера для управляющих элементов. Интерфейс 456 IRawElementProvider реализован системой 200 обеспечения доступности и взаимодействует с провайдером для получения функциональных возможностей, связанных с конкретным элементом. Пример варианта осуществления интерфейса 456 IRawElementProvider приведен в таблице ниже.

Таблица 21

Дополнительный интерфейс 450 исходных элементов провайдера может включать в себя интерфейс 452 взаимодействия контекста исходных элементов провайдера (IRawElementContexInteropProvider). Интерфейс 452 может быть реализован провайдером Win32 или третьей стороны. Интерфейс 452 может быть использован для управления событиями и другими функциональными возможностями, не связанными с конкретным элементом. Еще один дополнительный интерфейс 450 исходных элементов провайдера может включать в себя интерфейс 458 контекста исходных элементов провайдера (IRawElementContexProvider). Интерфейс 458 может быть реализован собственным провайдером Клиентской Платформы Windows и используется для управления событиями и другими функциональными возможностями, не связанными с конкретным элементом. Пример варианта осуществления интерфейса 458 IRawElementContextProvider приведен в таблице ниже.

Таблица 22

ИПП 440 стороны провайдера могут также включать в себя интерфейсы 460 шаблонов управления провайдера. Каждый шаблон управления имеет интерфейс 460 провайдера, то есть реализован объектом, предоставляющим шаблон управления системе 200 обеспечения доступности. Например, интерфейс окна приложения провайдера (IApplicatioWindowProvider) предоставляет поведение (режим) и информацию, связанные с окном приложения верхнего уровня. Интерфейсы 460 шаблонов управления провайдера, описанные ниже, включают в себя интерфейсы обеспечения взаимодействия провайдера (InteropProvider), которые могут быть реализованы на основе HWND и провайдерами третьей стороны. Интерфейсы 460 шаблонов управления провайдера могут также включать в себя интерфейсы провайдера, которые могут быть реализованы собственными провайдерами Клиентской Платформы Windows.

Интерфейсы 460 шаблонов управления провайдера могут дополнительно включать в себя интерфейс окна приложения провайдера (IApplicationWindowProvider). Интерфейс IApplicationWindowProvider или IApplicationWindowInteropProvider может предоставить поведение и информацию, связанную в типовом случае с окном приложения верхнего уровня. Этот интерфейс в типовом случае реализуется провайдерами для предоставления функциональных возможностей для манипулирования основным окном приложения.

Интерфейсы 460 шаблонов управления провайдера могут дополнительно включать в себя интерфейс расширения и сворачивания (IExpandCollapseProvider) или интерфейс IExpandCollapseInteropProvider. Этот интерфейс может предоставлять элементы управления для реализации функции расширения, чтобы отобразить больше содержимого, или функции сворачивания для скрытия содержимого. Интерфейс IExpandCollapseProvider может поддерживаться во взаимосвязи с шаблоном HierarchyItem (описан ниже) для обеспечения деревообразного режима, а также релевантен для индивидуальных операций управления, реализующих функцию открытия и закрытия. Элементы ПИ, такие как панели инструментов, комбинированные окна и меню, могут включать в себя релевантные реализации.

Интерфейсы 460 шаблонов управления провайдера могут дополнительно включать в себя интерфейс сетки (объекта-контейнера для отображения данных по строкам и столбцам) провайдера (IGridProvider) или интерфейс IGridInteropProvider. Интерфейсы IGridProvider отображают базовые функциональные возможности сетки, включая размеры сетки и перемещение информации в конкретные ячейки.

Интерфейс элементов сетки провайдера (IGridItemProvider) или IGridItemInteropProvider может обеспечивать дополнительный интерфейс 460 шаблонов управления провайдера. Интерфейс IGridItemProvider представляет элемент, который находится в сетке. Этот интерфейс может включать в себя только свойства без методов. Интерфейс IGridItemProvider или IGridItemInteropProvider реализуется провайдерами для предоставления функциональных возможностей манипулирования элементом управления, который открывает функцию элемента в сетке.

Интерфейсы 460 шаблонов управления провайдера могут дополнительно включать в себя интерфейс элемента иерархии провайдера (IHierarchyItemProvider) или интерфейс IHierarchyItemInteropProvider. Интерфейсы IHierarchyItemProvider или IHierarchyItemInteropProvider предоставляют возможность клиентам 300 перемещаться по иерархическим взаимосвязям между элементами ПИ независимо от их соотношения в логическом дереве 222. Иерархические взаимосвязи по определению являются некруговыми. Элементы ПИ, которые могут реализовывать этот интерфейс, включают в себя элементы управления представлениями меню и списков.

Интерфейсы 460 шаблонов управления провайдера могут дополнительно включать в себя интерфейс вызова (активизации) провайдера (IInvokeProvider) или интерфейс IInvokeInteropProvider. Интерфейс вызова провайдера может быть реализован объектами, которые имеют единственное, однозначно определенное действие, связанное с ними. Эти объекты обычно не изменяют своего состояния, и их вызов не изменяет их собственного состояния, но обуславливает изменения в большом контексте приложения. Элементы ПИ, которые могут реализовать интерфейс IInvokeProvider, включают в себя кнопки и элементы меню гиперсвязей.

Интерфейс множества представлений провайдера (IMultipleViewProvider) или IMultipleViewInteropProvider может обеспечивать дополнительный интерфейс 460 шаблона управления провайдера. Интерфейс множества представлений провайдера может предоставить возможность переключения между множеством представлений одного и того же набора информации, данных или дочерних элементов. Этот шаблон должен быть реализован в контейнере, который управляет текущим представлением содержимого.

Интерфейсы 460 шаблонов управления провайдера могут дополнительно включать в себя интерфейс значения диапазона провайдера (IRangeValueProvider) или интерфейс IRangeValueInteropProvider. Интерфейс значения диапазона провайдера может предоставить связанный набор свойств, которые отражают возможности элементов управления по управлению значением в конечном диапазоне значений. Этот интерфейс может предоставлять действительные минимальное и максимальное значения элемента управления и его текущее значение. Элементы ПИ, которые реализуют этот интерфейс, включают в себя числовые изменяемые поля (кольцевые счетчики) на индикаторе выполнения или полосах прокрутки.

Интерфейс прокрутки провайдера (IScrollProvider) или IScrollInteropProvider может быть обеспечен как дополнительный интерфейс 460 шаблона управления провайдера. Этот интерфейс показывает возможность элементов управления изменять часть видимой области, которая предоставляется для наблюдения пользователю путем прокрутки ее содержимого. Возможный вариант осуществления интерфейс IScrollInteropProvider представлен в таблице ниже.

Таблица 23

Дополнительный интерфейс 460 элемента управления провайдера включает в себя интерфейс выбора по идентификации провайдера (ISelectionByIDProvider) или ISelectionByIDInteropProvider. Этот интерфейс представляет элемент контейнера, предоставляющий выбор из элементов, которые он вмещает. Интерфейс выбора по идентификации провайдера является интерфейсом стороны провайдера для элементов управления, которые не имеют дочерних логических элементов. Клиенты будут наблюдать те же методы, как если бы элемент управления имел логические элементы в качестве дочерних. Этот интерфейс реализован для содействия провайдеру в предоставлении функциональных возможностей для манипулирования элементами в контейнере, которые могут быть выбраны и выбор которых может быть отменен. Возможный вариант осуществления интерфейса представлен в таблице ниже.

Таблица 24

Интерфейсы 460 элемента управления провайдера могут также включать в себя интерфейс выбора провайдера (ISelectionProvider) или ISelectionInteropProvider. Интерфейс выбора провайдера может представлять контейнеры, которые управляют выбором, и реализуется провайдерами для предоставления функциональных возможностей для манипулирования элементом, который содержит элементы, которые могут быть выбраны. Возможный вариант осуществления интерфейса представлен в таблице ниже.

Таблица 25

Интерфейсы 460 элемента управления провайдера могут дополнительно включать в себя интерфейс выбора элемента провайдера (ISelectionItemProvider или ISelectionItemInteropProvider). Эти интерфейсы могут определять выбираемый элемент и открывать его функциональные возможности, чтобы он мог быть выбран, или чтобы его выбор был отменен.

Интерфейсы 460 элемента управления провайдера могут также включать в себя интерфейс сортировки провайдера (ISortProvider или ISortInteropProvider). Эти интерфейсы могут предоставлять текущий порядок сортировки контейнера и позволять клиенту программным образом пересортировывать его элементы.

Интерфейс значения провайдера (IValueProvider или IValueInteropProvider) может быть реализован интерфейсами 460 элементов управления провайдера для представления и манипулирования элементами, которые имеют связанное значение.

Интерфейс визуальной информации провайдера (IVisualInformationProvider или IVisualInformationInteropProvider) может быть включен в интерфейсы 460 элементов управления провайдера для выражения информации об изображении или анимации, которая переносит информацию для пользователя.

Интерфейс окна провайдера (IWindowProvider или IWindowInteropProvider) также может быть включен в интерфейсы 460 элементов управления провайдера. Этот интерфейс может открыть возможности элемента по изменению своего размера или позиции на экране, а также по изменению визуального состояния и закрытия его. Пример этого интерфейса приведен в таблице ниже.

Таблица 26

ИПП 440 стороны провайдера могут также включать в себя вспомогательные классы 480. Вспомогательные классы 480 могут быть по существу идентичными тем, которые используются в ИПП 305 клиентской стороны. Как описано выше, клиент и провайдер могут совместно использовать вспомогательные классы. Эта особенность ниже описана со ссылкой на фиг.10.

На фиг.10 показано взаимодействие между ИПП 305 клиентской стороны, ядром 200 системы обеспечения доступности и ИПП 440 серверной стороны. Клиентское приложение 300 реализует класс 312 автоматизации, класс 314 логического элемента, класс 316 исходного элемента или класс 320 элементов управления для получения информации в ядре 201 системы обеспечения доступности. Клиентское приложение 300 может также реализовывать вспомогательные классы 350 клиента и класс 340 ввода.

Фиг.10 иллюстрирует ИПП 440 стороны провайдера во взаимосвязи с реализацией А (10), использующей Win32 Run 12, и реализацией В (20), использующей WCP Run. Реализация А использует интерфейс 502 способности к взаимодействию автоматизации провайдера, интерфейс 456 исходного элемента провайдера, интерфейс 452 взаимодействия контекста исходных элементов провайдера и интерфейсы 460 шаблонов управления, как это требуется. Реализация В использует класс 500 автоматизации провайдера, интерфейс 456 исходного элемента провайдера, интерфейс 448 свойства автоматизации, интерфейс 458 контекста исходного элемента провайдера и интерфейсы 460 шаблонов управления, как это требуется. Обе реализации 10 и 20 могут использовать вспомогательные классы 480 провайдера. Как указано выше, вспомогательные классы провайдера могут быть по существу теми же самыми, что и клиентские вспомогательные классы 350 или могут совместно использоваться с клиентскими вспомогательными классами 350, как показано совместно используемым вспомогательными классами 510. Как указано выше, совместно используемые вспомогательные классы 510 могут включать в себя типы, которые клиент и провайдер используют совместно для обмена информацией, такой как идентификаторы свойств, идентификаторы шаблонов и идентификаторы событий.

В процессе работы ИПП 305 клиентской стороны позволяет клиенту 300 получить логическое дерево. Функциональные возможности включают в себя следующее: (1) логический элемент от точки к точке, (2) логический элемент из события, (3) активизированный в текущий момент логический элемент. Как указано выше, логический элемент представляет компонент ПИ, возможно, элемент управления, часть элемента управления, контейнер или логическую группу (например, диалог, панель, кадр). Элементы управления могут изменяться существенным образом в понятиях их функциональности. Соответственно используются различные типы интерфейсов для представления функциональных возможностей, связанных с конкретными типами элементов управления. Однако эти специфические для управления интерфейсы выводятся из общего базового интерфейса, который представляет функциональные возможности общие для всех элементов управления. Этот общий базовый интерфейс содержит классы 310 ядра, которые включают в себя следующее: (1) методы навигации по логическому дереву 222; (2) общий метод получения значения свойства и (3) методы для оценки поддерживаемых специфических для управления интерфейсов. При навигации по логическому дереву 222 каждая базовая технология ПИ приложения будет обеспечивать свой собственный метод для навигации.

Для запуска использования событий системы обеспечения доступности в приложении клиент 300 может осуществить одно из следующего: (1) использовать метод «Добавить Обработчик Событий Окна Верхнего Уровня» из класса 312 автоматизации для открытия нового ПИ, появляющегося на рабочем столе и в обработчике для данного события, зарегистрироваться для других событий и с помощью этого средства получить события из любого процесса; (2) использовать методы «Найти» из класса 312 автоматизации для нахождения интересующего ПИ и нацеливания на конкретный участок ПИ; (3) использовать некоторый другой метод из класса 312 автоматизации для нахождения интересующего ПИ, такой как нахождение описателя окна или точки на экран и, с использованием описателя или точки, обнаружить логический элемент для использования в качестве ссылки для отслеживания событий; или (4) использовать метод «Добавить Обработчик События Изменения Активизации» класса 312 автоматизации для отслеживания фокусировки (активизации) ввода и регистрации для событий на ПИ, который в текущий момент активизирован.

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

События окна верхнего уровня включают в себя события, связанные с меню и комбинированными окнами с "выпадающими" списками, или любые особенности, имеющие рабочий стол в качестве родительского объекта. В одном варианте осуществления изобретения метод «Добавить Обработчик Событий Окна Верхнего Уровня» используется для получения уведомления об открытых и закрытых окнах верхнего уровня. Вызов метода «Добавить Обработчик Событий Окна Верхнего Уровня» позволяет получить уведомления об открытии новых окон верхнего уровня или закрытии окон верхнего уровня на текущем рабочем столе. Метод «Удалить Обработчик Событий Окна Верхнего Уровня» обеспечивает механизм прекращения приема уведомлений об открытии или закрытии окон верхнего уровня на рабочем столе. Этот метод использует объект обратного вызова для идентификации этого приемника информации («слушателя»). Поэтому объект, прошедший в процедуру метода «Удалить Обработчик Событий Окна Верхнего Уровня» тот же самый, что и прошедший в процедуру метода «Добавить Обработчик Событий Окна Верхнего Уровня». Метод вызывается из ИПП 440 стороны провайдера для каждого нового открываемого окна верхнего уровня. Аналогичным образом, метод может вызываться системой 200 обеспечения доступности всякий раз, когда окно верхнего уровня закрывается. Для приема этих уведомлений клиент 300 вызывает метод «Добавить Обработчик Событий Окна Верхнего Уровня».

Другим типом события является событие фокусировки (активизации). Клиентам 300 часто требуется метод для отслеживания фокусировки. Осуществление этого в ОС Microsoft Windows является затруднительным. Например, когда меню раскрывается (например, меню «файл» в Microsoft Word), элементы меню активизируются по мере того как пользователь перемещает курсор. Когда меню закрывается (например, пользователь нажимает кнопку ESC), в настоящее время нет посылаемого при этом события фокусировки. Вместо этого, клиент, заинтересованный в изменении фокусировки, должен отслеживать ряд событий и рассчитывать, какое из них логически представляет изменение фокусировки. В одном варианте осуществления изобретения метод «Добавить Обработчик События Изменения Фокусировки» из класса 312 автоматизации может быть использован для уведомления приемника информации (слушателя) о событиях изменения фокусировки. Клиент 300 может определить набор свойств, которые должны возвращаться в этом и другом методах регистрации для уведомления о событиях. Клиент 300 может вызвать метод «Удалить Обработчик События Изменения Фокусировки» для прекращения приема уведомлений об изменении фокусировки. Этот метод может использовать объект обратного вызова для идентификации приемника информации, и в этом случае объекты, проходящие в процедуру метода «Удалить Обработчик События Изменения Фокусировки» будут теми же самыми, что и проходящие в процедуру метода «Добавить Обработчик События Изменения Фокусировки». Система 200 обеспечения доступности может вызвать метод, такой как «Переместить Событие Изменения Фокусировки» из класса 422 автоматизации стороны провайдера при изменении фокусировки, чтобы уведомить клиента 300.

События изменения свойств запускаются, когда изменяются свойства логических элементов. В одном варианте осуществления изобретения клиент 300 вызывает метод «Добавить Обработчик События Изменения Свойства» из класса 312 автоматизации для приема уведомлений об изменениях свойств. Система 200 обеспечения доступности вызывает метод стороны провайдера из ИПП 440 стороны провайдера, когда значение свойства изменилось для логического элемента в составе дерева логических элементов, определенного в методе «Добавить Обработчик События Изменения Свойства». Параметр области действия указывает, для каких элементов следует запустить событие. Например, прохождение корневого логического элемента окна и запрос потомков ограничивает обратные вызовы изменения свойства этим окном. Если параметр области действия установлен на все элементы в дереве, то область действия игнорируется и посылается любое изменение определенных свойств, которое возникает на рабочем столе. Клиент 300 может вызвать метод «Добавить Обработчик События Изменения Свойства» много раз с различными наборами свойств и/или различным объектом обратного вызова. Уведомление, обеспечиваемое системой 200 обеспечения доступности, указывает следующее: свойство изменилось; новое значение свойства; старое значение свойства, если доступно. Клиент 300 может вызвать метод «Удалить Обработчик События Изменения Свойства» для прекращения приема уведомлений об изменениях свойств. Этот метод может использовать элемент области действия и объект обратного вызова для идентификации приемника информации (слушателя), и в этом случае объекты, прошедшие в процедуру метода, должны быть теми же самыми, что и прошедшие в процедуру метода «Добавить Обработчик События Изменения Свойства». Класс 422 автоматизации провайдера включает в себя метод «Переместить Событие Изменения Свойства Автоматизации» для информирования клиента 300 об изменениях свойства автоматизации.

Метод «Добавить Обработчик События Автоматизации» из клиентского класса 312 автоматизации позволит клиенту 300 получать события для элементов управления. Параметр области действия может быть использован для указания того, для каких элементов следует запускать события. Например, прохождение корневого логического элемента окна и запрос потомков ограничит события данным окном. Если желательны все элементы дерева, то будут посылаться все события на рабочем столе. Метод «Удалить Обработчик События Изменения Свойства» может быть использован для прекращения приема события для элементов управления. Этот метод может использовать элемент области действия, объект обратного вызова и идентификатор события для идентификации приемника информации. В этом случае прошедшие объекты должны быть теми же самыми, что и прошедшие в процедуру метода «Добавить Обработчик События Изменения Свойства». Класс 442 автоматизации провайдера включает в себя метод «Переместить Событие Автоматизации» для информирования клиента 300 о событиях.

Когда клиентское приложение вызвало метод «Добавить Обработчик События Автоматизации», система 200 обеспечения доступности вызывает метод из ИПП 440 стороны провайдера, когда запускается специфическое для управления событие, и источником события является логический элемент в дереве логических элементов, определенном в методе «Добавить Обработчик События Автоматизации». Когда запускаются события для элементов управления, то часто имеется доступная специфическая для события информация. Метод «Удалить Обработчик События Автоматизации» может быть вызван для прекращения приема каких-либо событий. Это является быстрым способом очистки перед выключением клиентского приложения. Метод удаления может быть оптимальным образом использован при завершении приложения.

События изменения логической структуры запускаются при изменениях структуры дерева логических элементов. Метод «Добавить Обработчик События Изменения Логической Структуры» может быть реализован для получения уведомлений о структурных изменениях в дереве логических элементов. Когда логические элементы добавляются, удаляются или делаются недействительными, вызываются методы для определенного объекта обратного вызова. Метод «Удалить Обработчик События Изменения Логической Структуры» может быть вызван для прекращения приема событий изменения дерева логических элементов. Этот метод может использовать объект обратной связи и элемент области действия для идентификации данного приемника информации, и в этом случае объекты, пропускаемые в процедуру метода, будут теми же, что и пропускаемые в процедуру метода «Добавить Обработчик События Автоматизации».7 Класс 442 автоматизации провайдера включает в себя метод «Переместить События Изменения Логической Структуры» для информирования клиента 300 об изменениях логической структуры.

ИПП 440 серверной стороны или стороны провайдера автоматизации ПИ включают в себя методы, которые сервер или базовый механизм ПИ может вызвать для выполнения уведомлений об изменении свойств. Сервер 400 может вызвать эти методы уведомлений для генерации соответствующих параметров при изменениях ПИ.

Настоящее изобретение описано выше по отношению к конкретным вариантам осуществления, которые во всех отношениях интерпретируются как иллюстративные, но ограничительные. Альтернативные варианты осуществления должны быть очевидны для специалистов в области техники, к которой относится настоящее изобретение, без отклонения от его объема.

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

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

1. Система инструментальных средств для использования в системе обеспечения доступности, которая обеспечивает клиента информацией пользовательского интерфейса, причем система обеспечения доступности включает в себя клиентскую сторону и сторону провайдера, при этом система инструментальных средств содержит инструментальные средства автоматизации клиентской стороны, включающие в себя класс автоматизации клиента для поиска информации пользовательского интерфейса, при этом класс автоматизации клиента включает в себя инструментальные средства обнаружения логического элемента и инструментальные средства регистрации события, причем инструментальные средства регистрации события позволяют клиенту регистрироваться для приема одного или более уведомлений о событиях; и инструментальные средства автоматизации стороны провайдера для обеспечения клиента информацией пользовательского интерфейса, при этом инструментальные средства автоматизации стороны провайдера включают в себя класс автоматизации провайдера, имеющий инструментальные средства для обеспечения клиента информацией события.2. Система по п.1, отличающаяся тем, что дополнительно содержит инструментальные средства логического элемента клиентской стороны для представления элемента пользовательского интерфейса.3. Система по п.2, отличающаяся тем, что дополнительно содержит инструментальные средства исходного элемента клиентской стороны для представления элемента в дереве исходных элементов.4. Система по п.1, отличающаяся тем, что дополнительно содержит класс ввода клиентской стороны для обеспечения методов для имитации ввода.5. Система по п.4, отличающаяся тем, что дополнительно содержит инструментальные средства для имитации ввода посредством мыши и ввода с клавиатуры.6. Система по п.2, отличающаяся тем, что дополнительно содержит классы шаблонов управления клиентской стороны для обеспечения возможности клиенту взаимодействовать с шаблонами управления системы обеспечения доступности.7. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона окна приложения для предоставления информации, связанной с основным окном приложения.8. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона расширения и свертывания для манипулирования содержимым, которое может быть отображено и может быть скрыто.9. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс элемента сетки, предназначенный для обнаружения, является ли элемент частью сетки.10. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона элемента иерархии для представления элементов пользовательского интерфейса (ПИ), которые показывают иерархическое соотношение между элементами ПИ независимо от их соотношения в логическом дереве.11. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона вызова для представления объектов, имеющих одно ассоциированное действие.12. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона множества представлений для манипулирования элементом, который может переключаться между множеством представлений.13. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона значения диапазона для указания минимального и максимального значений элемента управления.14. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона прокрутки для манипулирования элементом, который может изменить наблюдаемое представление посредством прокрутки.15. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона выбора для манипулирования элементами в контейнере, которые могут быть выбраны, и выбор которых может быть отменен.16. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона сортировки для манипулирования элементом контейнера, который может сортировать подэлементы.17. Система по п.6, отличающаяся тем, что классы шаблонов управления клиентской стороны включают в себя класс шаблона значения для представления элементов пользовательского интерфейса, которые выражают значение.18. Система по п.6, отличающаяся тем, что дополнительно содержит класс шаблона окна для манипулирования окном на пользовательском рабочем столе.19. Система по п.1, отличающаяся тем, что дополнительно содержит вспомогательные инструментальные средства для выполнения дополнительных функций.20. Система по п.1, отличающаяся тем, что дополнительно содержит интерфейс автоматизации стороны провайдера для предоставления дополнительных свойств.21. Система по п.1, отличающаяся тем, что дополнительно содержит интерфейс исходных элементов провайдера для возвращения относительных элементов из дерева исходных элементов.22. Система по п.1, отличающаяся тем, что дополнительно содержит интерфейсы шаблонов управления провайдера для предоставления поведения и информации, ассоциированных с определенными шаблонами управления.23. Система инструментальных средств клиентской стороны, реализованных в системе обеспечения доступности, которая обеспечивает клиента информацией пользовательского интерфейса, причем система обеспечения доступности включает в себя механизм для переноса информации пользовательского интерфейса от стороны провайдера к клиентской стороне и логическое дерево для селективного обнаружения информации пользовательского интерфейса, а инструментальные средства клиентской стороны включают в себя механизм автоматизации клиентской стороны, включающий в себя класс автоматизации клиента для поиска информации события пользовательского интерфейса от стороны провайдера; и механизм логического элемента клиентской стороны, включающий в себя класс логического элемента для представления элемента пользовательского интерфейса в логическом дереве, при этом логическое дерево имеет только одно или более элементов пользовательского интерфейса, которые представляют интерес для клиента, причем каждый из одного или более элементов пользовательского интерфейса представляет управление, элемент в управлении или структуру группирования.24. Система по п.23, отличающаяся тем, что класс автоматизации клиента содержит инструментальные средства для добавления обработчика события автоматизации и инструментальные средства для удаления обработчика события автоматизации.25. Система по п.23, отличающаяся тем, что класс автоматизации клиента содержит инструментальные средства для добавления обработчика события изменения свойства автоматизации и инструментальные средства для удаления обработчика события изменения свойства автоматизации.26. Система по п.23, отличающаяся тем, что класс автоматизации клиента содержит инструментальные средства для добавления обработчика события изменения фокусировки и инструментальные средства для удаления обработчика события изменения фокусировки.27. Система по п.23, отличающаяся тем, что класс автоматизации клиента содержит инструментальные средства для добавления обработчика события окна верхнего уровня и инструментальные средства для удаления обработчика события окна верхнего уровня.28. Система по п.23, отличающаяся тем, что класс автоматизации клиента содержит инструментальные средства для добавления обработчика события изменения логической структуры и инструментальные средства для удаления обработчика события изменения логической структуры.29. Система по п.23, отличающаяся тем, что класс автоматизации клиента содержит инструментальные средства для нахождения логического элемента и инструментальные средства для нахождения исходного элемента.30. Система по п.23, отличающаяся тем, что дополнительно содержит класс исходного элемента клиентской стороны для представления элемента в дереве исходных элементов.31. Система по п.23, отличающаяся тем, что класс логического элемента дополнительно содержит инструментальные средства для получения всех шаблонов, поддерживаемых элементом.32. Система по п.23, отличающаяся тем, что дополнительно содержит класс ввода для обеспечения методов для имитации ввода.33. Система по п.32, отличающаяся тем, что ввод включает в себя ввод посредством мыши и ввод с клавиатуры.34. Система инструментальных средств стороны провайдера, реализованных в системе обеспечения доступности, которая обеспечивает клиента информацией пользовательского интерфейса, причем система обеспечения доступности включает в себя механизм для переноса информации пользовательского интерфейса от стороны провайдера к клиенту и логическое дерево для селективного обнаружения информации пользовательского интерфейса, при этом инструментальные средства стороны провайдера включают в себя класс автоматизации стороны провайдера, включающий в себя инструментальные средства для обеспечения уведомлений о событиях клиенту; интерфейс автоматизации стороны провайдера для предоставления свойств пользовательского интерфейса; интерфейс исходного элемента для возвращения информации, связанной с конкретным относительным элементом; и интерфейс контекста исходного элемента для управления событиями и функциональными средствами, не связанными с конкретным элементом.35. Система по п.34, отличающаяся тем, что класс автоматизации стороны провайдера содержит инструментальное средство для выведения события автоматизации.36. Система по п.34, отличающаяся тем, что класс автоматизации стороны провайдера содержит инструментальное средство для выведения события изменения свойства.37. Система по п.34, отличающаяся тем, что класс автоматизации стороны провайдера содержит инструментальное средство для выведения события изменения фокусировки.38. Система по п.34, отличающаяся тем, что класс автоматизации стороны провайдера содержит инструментальное средство для выведения события изменения логической структуры.39. Система по п.34, отличающаяся тем, что дополнительно содержит интерфейсы шаблонов управления провайдера.40. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс окна приложения провайдера для предоставления поведения и информации, ассоциированных с окном приложения верхнего уровня.41. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс расширения и сворачивания для отображения и скрытия содержимого.42. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс сетки провайдера для предоставления базовых функциональных возможностей сетки.43. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс элемента иерархии провайдера для обеспечения возможности клиенту перемещаться по иерархическим взаимосвязям между элементами пользовательского интерфейса.44. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс вызова провайдера для использования объектами, которые выполняют одно действие.45. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс множества представлений провайдера для предоставления возможности объекту переключаться между множеством представлений.46. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс значения диапазона провайдера для предоставления набора свойств, позволяющего управлять конечным диапазоном значений.47. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс прокрутки провайдера для предоставления возможности изменения области просмотра.48. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс выбора по идентификации провайдера для предоставления элемента, который обеспечивает возможность выбора между элементами.49. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс выбора провайдера для представления контейнера, который управляет выбором.50. Система по п.39, отличающаяся тем, что интерфейсы шаблонов управления провайдера включают в себя интерфейс окна провайдера для предоставления возможности изменять размер и положение.51. Система интерфейса прикладной программы для обеспечения информации пользовательского интерфейса клиенту через систему обеспечения доступности, причем система обеспечения доступности включает в себя механизм для переноса информации пользовательского интерфейса от стороны провайдера к клиентской стороне и логическое дерево для селективного обнаружения информации пользовательского интерфейса, при этом система интерфейса прикладной программы содержит интерфейсы прикладной программы клиентской стороны для обеспечения помощи клиенту в получении информации пользовательского интерфейса, причем интерфейсы прикладной программы клиентской стороны включают в себя класс автоматизации, класс исходного элемента, классы шаблонов управления, класс ввода и класс логического элемента для представления элемента пользовательского интерфейса в логическом дереве, причем логическое дерево имеет только один или более элементов пользовательского интерфейса, которые представляют интерес для клиента, причем каждый из одного или более элементов пользовательского интерфейса представляет управление, элемент в управлении или структуру группирования; и интерфейсы прикладной программы стороны провайдера для реагирования на запросы клиента, при этом интерфейсы прикладной программы стороны провайдера включают в себя класс автоматизации провайдера, интерфейс автоматизации провайдера, интерфейс исходного элемента и интерфейсы шаблонов управления провайдера.52. Система по п.51, отличающаяся тем, что дополнительно содержит вспомогательные классы, используемые стороной провайдера и клиентской стороной.53. Реализованный компьютером способ обеспечения информации пользовательского интерфейса клиенту через систему обеспечения доступности, причем система обеспечения доступности включает в себя механизм для переноса информации пользовательского интерфейса от стороны провайдера к клиентской стороне и логическое дерево для селективного обнаружения информации пользовательского интерфейса, при этом способ включает в себя

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

предоставление интерфейсов прикладной программы стороны провайдера для реагирования на запросы клиента, при этом интерфейсы прикладной программы стороны провайдера включают в себя класс автоматизации провайдера, интерфейс автоматизации провайдера, интерфейс исходного элемента и интерфейсы шаблонов управления провайдера.

запрос информации пользовательского интерфейса с использованием выбранного обработчика событий из класса автоматизации клиента,

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

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