Benutzeroberflächenautomatisierung und Microsoft Active Accessibility

Aktualisiert: November 2007

Microsoft Active Accessibility war die frühere Lösung für den leichteren Zugriff auf Anwendungen. Microsoft-UI-Automatisierung ist das neue Zugriffsmodell für Microsoft Windows. Es wurde für die Anforderungen von Hilfstechnologieprodukten und automatisierten Testtools entwickelt. UI-Automatisierung bietet gegenüber Active Accessibility viele Verbesserungen.

In diesem Thema werden die wesentlichen Features von UI-Automatisierung dargestellt und erläutert, wie diese sich von Active Accessibility unterscheiden.

Dieses Thema enthält folgende Abschnitte.

• Programmiersprachen
• Unterstützung in Windows Presentation Foundation
• Server und Clients
• Benutzeroberflächenelemente
• Strukturansichten und Navigation
• Rollen und Steuerelementtypen
• Zustände und Eigenschaften
• Ereignisse
• Sicherheit
• Verwandte Abschnitte

Programmiersprachen

Active Accessibility basiert auf Component Object Model (COM) mit Unterstützung für duale Schnittstellen und ist daher in C/C++, Microsoft Visual Basic 6.0 und Skriptsprachen programmierbar. UI-Automatisierung (einschließlich der clientseitigen Anbieterbibliothek für Standardsteuerelemente) ist in verwaltetem Code geschrieben, und Benutzeroberflächenautomatisierungs-Client-Anwendungen werden am einfachsten mit Microsoft Visual C# oder Microsoft Visual Basic .NET programmiert. Benutzeroberflächenautomatisierungs-Anbieter, also Schnittstellenimplementierungen, können in verwaltetem Code oder C/C++ geschrieben werden.

Unterstützung in Windows Presentation Foundation

Windows Presentation Foundation (WPF) ist das neue Modell zum Erstellen von Benutzeroberflächen. WPF-Elemente bieten keine systemeigene Unterstützung für Active Accessibility. Stattdessen wird UI-Automatisierung unterstützt, wodurch eine überbrückende Unterstützung für Active Accessibility-Clients besteht. Nur Clients, die speziell für UI-Automatisierung geschrieben sind, können die Zugriffsfunktionen von WPF, wie z. B. die umfangreiche Unterstützung für Text, voll ausschöpfen.

Server und Clients

In Active Accessibility kommunizieren Server und Clients direkt miteinander, hauptsächlich durch die serverseitige Implementierung von IAccessible.

In UI-Automatisierung befindet sich zwischen dem Server (Anbieter genannt) und dem Client ein Basisdienst. Der Basisdienst führt Aufrufe an die von Anbietern implementierten Schnittstellen durch und bietet zusätzliche Dienste, wie das Generieren eindeutiger Laufzeitbezeichner für Elemente. Clientanwendungen verwenden Bibliotheksfunktionen, um den UI-Automatisierung-Dienst aufzurufen.

Benutzeroberflächenautomatisierungs-Anbieter können für Active Accessibility-Clients Informationen bereitstellen, und Active Accessibility-Server können für Benutzeroberflächenautomatisierungs-Client-Anwendungen Informationen bereitstellen. Da Active Accessibility jedoch nicht so viele Informationen wie UI-Automatisierung verfügbar macht, sind die beiden Modelle nur eingeschränkt kompatibel.

Benutzeroberflächenelemente

Active Accessibility stellt Benutzeroberfläche-Elemente entweder als IAccessible-Schnittstelle oder als untergeordneten Bezeichner dar. Es ist schwierig, zwei IAccessible-Zeiger miteinander zu vergleichen, um zu bestimmen, ob sie auf dasselbe Element verweisen.

In UI-Automatisierung wird jedes Element als AutomationElement-Objekt dargestellt. Der Vergleich wird mithilfe des Gleichheitsoperators oder der Equals-Methode durchgeführt. Dabei wird jeweils der eindeutige Laufzeitbezeichner der Elemente verglichen.

Strukturansichten und Navigation

Die Benutzeroberfläche (user interface, UI)-Elemente auf dem Bildschirm werden als Baumstruktur angezeigt, mit dem Desktop als Stamm, Anwendungsfenstern als unmittelbar untergeordnete Elemente sowie Elementen innerhalb von Anwendungen auf den Ebenen darunter.

In Active Accessibility werden viele Automatisierungselemente in der Struktur verfügbar gemacht, die für Endbenutzer nicht relevant sind. Clientanwendungen müssen alle Elemente überprüfen, um zu bestimmen, welche benötigt werden.

Benutzeroberflächenautomatisierungs-Client-Anwendungen sehen die Benutzeroberfläche über eine gefilterte Ansicht. Die Ansicht enthält nur Elemente, die von Interesse sind, also diejenigen, die Informationen für den Benutzer enthalten oder Interaktion ermöglichen. Vordefinierte Ansichten nur von Steuerelementen und Inhaltselementen stehen zur Verfügung. Zusätzlich können durch Anwendungen benutzerdefinierte Ansichten definiert werden. UI-Automatisierung vereinfacht die Aufgabe, dem Benutzer die Benutzeroberfläche zu beschreiben und die Interaktion mit der Anwendung zu erleichtern.

Die Navigation zwischen Elementen in Active Accessibility ist entweder räumlich (z. B. Wechseln zum Element, das auf der linken Seite des Bildschirms liegt), logisch (z. B. Wechseln zum nächsten Menüelement oder zum nächsten Element in der Aktivierreihenfolge innerhalb eines Dialogfelds) oder hierarchisch (z. B. Wechseln zum ersten übergeordneten Element in einem Container oder vom übergeordneten zum untergeordneten Element). Die hierarchische Navigation wird dadurch kompliziert, dass es sich bei untergeordneten Elementen nicht immer um Objekte handelt, die IAccessible implementieren.

In UI-Automatisierung sind alle Benutzeroberfläche-Elemente AutomationElement-Objekte, die die gleiche grundlegende Funktionalität unterstützen. (Aus Sicht des Anbieters sind sie Objekte, die eine von IRawElementProviderSimple geerbte Schnittstelle implementieren.) Die Navigation ist hauptsächlich hierarchisch: von übergeordneten zu untergeordneten Elementen und von einem nebengeordneten Element zum nächsten. (Die Navigation zwischen nebengeordneten Elementen hat ein logisches Element, da sie sich eventuell nach der Aktivierreihenfolge richtet.) Mithilfe der TreeWalker-Klasse können Sie von jedem Startpunkt aus in einer beliebigen gefilterten Ansicht der Struktur navigieren. Mithilfe von FindFirst und FindAll können Sie außerdem zu bestimmten untergeordneten oder Nachfolgerelementen navigieren. Beispielsweise ist es sehr einfach, alle Elemente in einem Dialogfeld abzurufen, die ein bestimmtes Steuerelementmuster unterstützen.

Die Navigation in UI-Automatisierung ist konsistenter als in Active Accessibility. Einige Elemente wie Dropdownlisten und Popupfenster werden in der Active Accessibility-Struktur doppelt angezeigt, und die Navigation kann zu unerwarteten Ergebnissen führen. Es ist eigentlich nicht möglich, Active Accessibility für ein Infoleisten-Steuerelement ordnungsgemäß zu implementieren. UI-Automatisierung ermöglicht ein erneutes Zuweisen zu übergeordneten Elementen und eine erneute Positionierung, sodass ein Element ungeachtet der Hierarchie, die auf dem Besitz von Fenstern beruht, überall in der Struktur platziert werden kann.

Rollen und Steuerelementtypen

Active Accessibility verwendet die accRole-Eigenschaft (IAccessible::get_actRole), um eine Beschreibung der Rolle des Elements in Benutzeroberfläche abzurufen, wie z. B. ROLE_SYSTEM_SLIDER oder ROLE_SYSTEM_MENUITEM. Die Rolle eines Elements ist der Hauptanhaltspunkt für seine verfügbare Funktionalität. Die Interaktion mit einem Steuerelement wird mithilfe fester Methoden wie IAccessible::accSelect und IAccessible::accDoDefaultAction erreicht. Die Interaktion zwischen der Clientanwendung und Benutzeroberfläche ist auf die Funktionsweise von IAccessible beschränkt.

Im Gegensatz dazu entkoppelt UI-Automatisierung den Steuerelementtyp des Elements (beschrieben durch die ControlType-Eigenschaft) weitgehend von seiner zu erwartenden Funktionalität. Die Funktionalität wird durch die Steuerelementmuster festgelegt, die vom Anbieter durch Implementieren spezieller Schnittstellen unterstützt werden. Steuerelementmuster können miteinander kombiniert werden, um den vollständigen Funktionssatz zu beschreiben, der von einem bestimmten Benutzeroberfläche-Element unterstützt wird. Einige Anbieter müssen ein bestimmtes Steuerelementmuster unterstützen. Beispielsweise muss der Anbieter für ein Kontrollkästchen das Toggle-Steuerelementmuster unterstützen. Andere Anbieter müssen von mehreren Steuerelementmustern mindestens eines unterstützen. Beispielsweise muss eine Schaltfläche entweder Toggle oder Invoke unterstützen. Wieder andere Anbieter unterstützen gar keine Steuerelementmuster. Beispielsweise verfügt ein Bereich, der nicht verschoben, in der Größe geändert oder angedockt werden kann, über keine Steuerelementmuster.

UI-Automatisierung unterstützt benutzerdefinierte Steuerelemente, die durch die Custom-Eigenschaft festgelegt werden und durch die LocalizedControlTypeProperty-Eigenschaft beschrieben werden können.

Die folgende Tabelle enthält die Zuordnung von Active Accessibility-Rollen zu UI-Automatisierung-Steuerelementtypen.

Weitere Informationen zu den unterschiedlichen Steuerelementtypen finden Sie unter Steuerelementtypen der Benutzeroberflächenautomatisierung.

Zustände und Eigenschaften

In Active Accessibility unterstützen Elemente einen allgemeinen Eigenschaftensatz, und manche Eigenschaften (wie z. B. accState) müssen je nach Rolle des Elements sehr unterschiedliche Dinge beschreiben. Server müssen alle Methoden von IAccessible implementieren, die eine Eigenschaft zurückgeben. Dies gilt auch für diejenigen, die für das Element nicht relevant sind.

Mit UI-Automatisierung werden wesentlich mehr Eigenschaften definiert, von denen einige Zuständen in Active Accessibility entsprechen. Manche beziehen sich auf alle Elemente, andere dagegen nur auf Steuerelementtypen und Steuerelementmuster. Eigenschaften werden durch eindeutige Bezeichner unterschieden, und die meisten Eigenschaften können mithilfe einer einzelnen Methode, GetCurrentPropertyValue oder GetCachedPropertyValue, abgerufen werden. Viele Eigenschaften können auch leicht über die Eigenschaftenaccessoren Current und Cached abgerufen werden.

Nicht relevante Eigenschaften müssen von einem Benutzeroberflächenautomatisierungs-Anbieter nicht implementiert werden. Für nicht unterstützte Eigenschaften kann jedoch einfach ein null-Wert zurückgegeben werden. Auch der UI-Automatisierung-Basisdienst kann einige Eigenschaften vom Standardfensteranbieter abrufen. Diese werden dann mit Eigenschaften zusammengeführt, die vom Anbieter explizit implementiert werden.

Neben den vielen weiteren unterstützten Eigenschaften bietet UI-Automatisierung eine bessere Leistung, indem mehrere Eigenschaften mit einem einzigen prozessübergreifenden Aufruf abgefragt werden können.

In der folgenden Tabelle wird die Entsprechung zwischen Eigenschaften der beiden Modelle dargestellt.

In der folgenden Tabelle wird dargestellt, welche UI-Automatisierung-Eigenschaften Active Accessibility-Zustandskonstanten entsprechen.

Die folgenden Zustände wurden von den meisten Active Accessibility-Steuerelementservern nicht implementiert oder haben in UI-Automatisierung keine Entsprechung.

Eine vollständige Liste der UI-Automatisierung-Eigenschaftenbezeichner finden Sie unter Übersicht über die Benutzeroberflächenautomatisierungs-Eigenschaften.

Ereignisse

Der Ereignismechanismus in UI-Automatisierung ist im Gegensatz zu dem in Active Accessibility nicht vom Windows-Ereignisrouting abhängig (welches eng mit Fensterhandles verbunden ist) und erfordert keine Einrichtung von Hooks durch die Clientanwendung. Abonnements für Ereignisse können nicht nur für spezielle Ereignisse optimiert werden, sondern für bestimmte Teile der Struktur. Anbieter können außerdem das Aufrufen von Ereignissen optimieren, indem nachverfolgt wird, welche Ereignisse überwacht werden.

Darüber hinaus ist es für Clients leichter die Elemente abzurufen, welche Ereignisse auslösen, da diese direkt an den Ereignisrückruf übergeben werden. Eigenschaften des Elements werden automatisch vorab abgerufen, wenn eine Cacheanforderung aktiv war, während das Ereignis vom Client abonniert wurde.

In der folgenden Tabelle wird die Entsprechung von Active Accessibility-WinEvents und UI-Automatisierung-Ereignissen dargestellt.

Sicherheit

Einige IAccessible-Anpassungsszenarien erfordern, dass ein grundlegendes IAccessible umschlossen wird, über das dann die Aufrufe erfolgen. Dies hat Auswirkungen auf die Sicherheit, da eine teilweise vertrauenswürdige Komponente keinen Vermittler auf einem Codepfad darstellen sollte.

Mit dem UI-Automatisierung-Modell müssen Anbieter Aufrufe nicht mehr über anderen Anbietercode ausführen. Die gesamte notwendige Aggregation wird vom UI-Automatisierung-Basisdienst durchgeführt.

Siehe auch

Weitere Ressourcen

Grundlagen der Benutzeroberflächenautomatisierung