Патент на изобретение №2316043

(54) МЕХАНИЗМ И СПОСОБ ПРЕДОСТАВЛЕНИЯ ИНФОРМАЦИИ СОБЫТИЙ В СИСТЕМЕ ДОСТУПА

(57) Реферат:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фиг.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) или иные оптические носители информации. Другие съемные/несъемные, энергозависимые/энергонезависимые компьютерные носители информации, которые могут быть использованы в приведенной для примера операционной среде, могут включать, но ограничиваться указанным, кассеты на магнитных лентах, платы флэш-памяти, цифровые многофункциональные диски, цифровые видеомагнитные ленты, твердотельные RAM, твердотельные ROM и т.п. Накопитель 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 подключен к локальной сети LAN 171 через сетевой интерфейс или адаптер 170. При использовании в среде глобальной сети WAN компьютер обычно включает в себя модем 172 или иное средство для установления связи в глобальной сети WAN 173, такой как Интернет. Модем 172, который может быть внутренним или внешним, может соединяться с системной шиной 121 через интерфейс 160 пользовательского ввода или иной подходящий механизм. В сетевой среде программные модули, показанные на чертеже в связи с компьютером 110, или их части могут храниться в дистанционных устройствах памяти. В качестве примера, но не ограничения, фиг.1 иллюстрирует удаленные прикладные программы 185, находящиеся в устройстве 181 памяти. Ясно, что показанные сетевые соединения приведены для примера и могут быть использованы другие средства установления линий связи между компьютерами.

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

Структура системы доступа

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

Клиентская среда 300 предпочтительно включает продукт технологии поддержки (ТП) или автоматизированное инструментальное средство тестирования ПИ. Серверная сторона 400 может реализовывать множество различных технологий, как показано на фиг.2. Серверная система 410 включает в себя адаптер 412 и ядро 414, которые могут находиться в ПИ первого типа. Серверная система 420 включает в себя компонент-посредник 422 и органы управления 424, как это может иметь место в ПИ второго типа, таком как ПИ Win32, доступном в продуктах операционной системы Microsoft компании Microsoft Corporation (Redmond, Washington). Серверная система 430 включает в себя адаптер 432 и OM (управление объектами) 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 представляет собой отфильтрованный вид базовой структурной иерархии элементов ПИ, но не отдельную древовидную схему, которая должна быть реализована посредством управления или разработчиком приложения. Вместо этого она вычленяет ряд хорошо определенных свойств, представляющих интерес и не представляющих интереса, которые указывают, должен ли структурный элемент быть показан в логической древовидной схеме. Ядро 201 системы доступа потребляет эту информацию для выработки отфильтрованной логической древовидной схемы 222 ПИ, которая в свою очередь представляется для продуктов ТП или тестовых скриптов.

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

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

В противоположность одноэтапному построению, как в известных системах, логическая древовидная схема 222 строится из фрагментов, которые используются для построения исходного дерева. Как показано на фиг.5, три основные процедуры строят логическую древовидную схему 222. В процедуре 72 система 200 доступа определяет местоположение естественных элементов базовых технологий и получает дерево естественных элементов, показанное на фиг.4(А). В процедуре 74 система 200 доступа комбинирует естественные элементы для формирования исходного дерева 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 и способна обеспечивать информацию независимо от используемого серверного приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На фиг.2 показано, каким образом клиенты 300 взаимодействуют с системой 200 доступа. Здесь нет глобального управления событиями в ходе процессов. Вместо этого каждый клиент 300 системы доступа или сервер 400 имеет свой собственный контекст. Клиентские приложения будут только принимать события для приложений, которые поддерживают систему 200 доступа. Для того чтобы начать использовать события системы доступа в приложении, клиент 300 может сделать одно из следующего: (1) Использовать ИПП “AddTopLevelWindowListener” («добавить прослушивающий процесс окна верхнего уровня») для обнаружения нового ПИ, появляющегося на рабочем столе и в обработчике данного события, регистрации других событий и с помощью этого средства приема событий из любого процесса; (2) Использовать один из ИПП Find («найти») для определения местонахождения интересующего ПИ и достижения конкретного фрагмента ПИ; (3) Использовать некоторые другие средства для обнаружения интересующих ПИ, например найти описатель окна или некоторую точку на экране и с использованием этого описателя или точки обнаружить логический элемент для использования в качестве опорного для ожидания событий, и (4) Использовать ИПП “AddFocusChangedListener” («добавить прослушивающий процесс изменения выделения (активного окна)») для отслеживания выделения (активизации) ввода и регистрации событий на ПИ, который в текущий момент активизирован.

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

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

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

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

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

1. События окна верхнего уровня

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

2. Событие выделения

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

3. События изменения свойств

События изменения свойств запускаются, когда свойства логических элементов изменяются. В возможном варианте осуществления изобретения клиент 300 вызывает метод «добавить прослушивающий процесс для изменения свойств» для приема уведомлений об изменениях свойств. Метод «свойство изменилось» вызывается системой 200 доступа, когда значение свойства изменилось в логическом элементе в пределах древовидной схемы логических элементов, определенной в методе «добавить прослушивающий процесс для изменения свойств». Параметр области действия указывает, для каких элементов событие должно быть запущено. Например, прохождение корневого логического элемента окна и запрос потомков ограничивает обратные вызовы изменения свойств для этого окна. Если параметр области действия установлен для всех элементов дерева, то область действия игнорируется и любые изменения конкретных свойств, которые возникают на рабочем столе, передаются. Клиент 300 может вызвать метод «добавить прослушивающий процесс для изменения свойств» много раз с различными наборами свойств и/или с отличающимся объектом обратного вызова. Уведомление, обеспечиваемое системой 200 доступа, указывает следующее: свойство изменилось; новое значение свойства; старое значение свойства, если оно доступно.

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

4. События из шаблонов органов управления

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

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

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

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

5. События изменения логической структуры

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

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

Метод «добавлено множество дочерних объектов» вызывается системой доступа, когда большое число дочерних элементов добавляется (например, более 20 дочерних элементов) за короткий период времени. Метод «удалено множество дочерних элементов» вызывается системой доступа, когда большое число дочерних элементов удаляются за короткий период времени. Метод «дочерние элементы сделаны недействительными» вызывается системой 200 доступа, когда большое число дочерних элементов (например, более 20 дочерних элементов) как добавлены, так и удалены в течение короткого периода времени.

6. Мультимедийные события

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

7. Простые звуковые события

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

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

8. События мягкого (неконтрастного) выделения

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

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

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

Следующая диаграмма иллюстрирует действия клиента 300 и системы 200 доступа, когда клиент 300 использует ИПП «добавить прослушивающий процесс для окна верхнего уровня» для прослушивания событий из конкретного процесса.

Уведомление о событиях

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

Серверные методы

Методы «добавлено извещение о событиях» и метод «удалено извещение о событиях» вызываются клиентом автоматической обработки ПИ для уведомления сервера 400, когда клиенты запрашивают события. Это позволяет серверу 400 не передать события системе 200 доступа, когда они не представляют интереса. Серверы могут использовать эти уведомления для обеспечения зависимости рабочих характеристик оттого, имеются ли клиенты, использующие события.

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

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

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

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

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

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

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

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

Свойства

Система 200 доступа будет особым представлением общего метода «получить свойство». Свойства предпочтительно представляются посредством GUID с использованием сервисных методов для перевода в нелокализуемую мнемоническую форму и из этой формы (полезную для скриптов и файлов конфигурации), а также для получения локализованных описаний. Двумя ключевыми преимуществами обобщенного метода «получить свойство» по сравнению с индивидуальными методами являются следующие: (а) он позволяет добавлять новые свойства во времени без изменения интерфейса и (b) он допускает методы реализации, такие как запускаемая массивом большого объема выборка свойств, что не возможно при использовании отдельных методов.

Каждое свойство должно иметь четко определенное назначение. Должно быть четко определено, предназначается ли свойство для потребления человеком или машиной, должно ли свойство быть локализуемым и т.д.

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

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

Формула изобретения

1. Система доступа в среде клиент-сервер, предназначенная для поддержания уведомлений клиента об изменениях в пользовательском интерфейсе, причем упомянутая система содержит

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

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

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

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

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

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

3. Система по п.2, в которой клиентская среда автоматической обработки пользовательского интерфейса (ПИ) содержит средство для доставки информации объекта в определенное местоположение у клиента.

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

5. Система по п.1, в которой механизм регистрации получает запрос на определенный объем информации.

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

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

8. Система по п.7, в которой каждый элемент относится только к одному из типов событий.

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

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

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

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

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

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

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

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

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

12. Способ по п.11, в котором доставка определенной пользовательской информации включает доставку информации объекта в определенное местоположение у клиента.

13. Способ по п.10, в котором прием запроса регистрации включает прием запроса на определенный объем информации.

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

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

16. Способ по п.15, в котором каждый элемент относится только к одному из типов событий.

РИСУНКИ

MM4A – Досрочное прекращение действия патента СССР или патента Российской Федерации на изобретение из-за неуплаты в установленный срок пошлины за поддержание патента в силе

Дата прекращения действия патента: 30.04.2008

Извещение опубликовано: 27.07.2009 БИ: 21/2009

NF4A – Восстановление действия патента СССР или патента Российской Федерации на изобретение

Дата, с которой действие патента восстановлено: 20.06.2010

Извещение опубликовано: 20.06.2010 БИ: 17/2010