Benutzerdefinierte Automatisierungs-Peers

Beschreibt das Konzept von Automatisierungspeers für Microsoft Benutzeroberflächenautomatisierung und wie Sie Automatisierungsunterstützung für Ihre eigene benutzerdefinierte UI-Klasse bereitstellen können.

Benutzeroberflächenautomatisierung stellt ein Framework bereit, das Automatisierungsclients verwenden können, um die Benutzeroberflächen einer Vielzahl von UI-Plattformen und Frameworks zu untersuchen oder zu betreiben. Wenn Sie eine Windows-App schreiben, bieten die Klassen, die Sie für Ihre Benutzeroberfläche verwenden, bereits Benutzeroberflächenautomatisierung Unterstützung. Sie können von vorhandenen, nicht versiegelten Klassen abgeleitet werden, um eine neue Art von UI-Steuerelement oder Unterstützungsklasse zu definieren. In diesem Prozess kann Ihre Klasse Verhalten hinzufügen, das über Unterstützung für die Barrierefreiheit verfügen sollte, die standardmäßige Benutzeroberflächenautomatisierung-Unterstützung jedoch nicht abgedeckt wird. In diesem Fall sollten Sie die vorhandene Benutzeroberflächenautomatisierung-Unterstützung erweitern, indem Sie von der AutomationPeer-Klasse abgeleitet werden, die von der verwendeten Basisimplementierung abgeleitet wird, alle erforderlichen Unterstützung zu Ihrer Peerimplementierung hinzufügen und die Windows-App-Steuerungsinfrastruktur darüber informieren, dass ihr neuer Peer erstellt werden soll.

Benutzeroberflächenautomatisierung ermöglicht nicht nur Barrierefreiheitsanwendungen und Hilfstechnologien wie Bildschirmsprachausgaben, sondern auch Qualitätssicherheitscode (Testcode). In beiden Szenarien können Benutzeroberflächenautomatisierung Clients Benutzeroberflächenelemente untersuchen und die Benutzerinteraktion mit Ihrer App aus einem anderen Code außerhalb Ihrer App simulieren. Informationen zu Benutzeroberflächenautomatisierung auf allen Plattformen und in seiner breiteren Bedeutung finden Sie unter Benutzeroberflächenautomatisierung Übersicht.

Es gibt zwei unterschiedliche Zielgruppen, die das Benutzeroberflächenautomatisierung Framework verwenden.

• Benutzeroberflächenautomatisierung Clients rufen Benutzeroberflächenautomatisierung-APIs auf, um mehr über alle Benutzeroberflächen zu erfahren, die derzeit für den Benutzer angezeigt werden. Beispielsweise fungiert eine Hilfstechnologie wie eine Bildschirmsprachausgabe als Benutzeroberflächenautomatisierung Client. Die Benutzeroberfläche wird als Struktur von Automatisierungselementen dargestellt, die im Zusammenhang stehen. Der Benutzeroberflächenautomatisierung-Client kann jeweils nur an einer App oder an der gesamten Struktur interessiert sein. Der Benutzeroberflächenautomatisierung-Client kann Benutzeroberflächenautomatisierung APIs verwenden, um in der Struktur zu navigieren und Informationen in den Automatisierungselementen zu lesen oder zu ändern.
• Benutzeroberflächenautomatisierung Anbieter tragen Informationen zur Benutzeroberflächenautomatisierung Struktur bei, indem APIs implementiert werden, die die Elemente in der Benutzeroberfläche verfügbar machen, die sie als Teil ihrer App eingeführt haben. Wenn Sie ein neues Steuerelement erstellen, sollten Sie jetzt als Teilnehmer im Szenario Benutzeroberflächenautomatisierung Anbieters fungieren. Als Anbieter sollten Sie sicherstellen, dass alle Benutzeroberflächenautomatisierung Clients das Benutzeroberflächenautomatisierung Framework verwenden können, um mit Ihrem Steuerelement für Barrierefreiheits- und Testzwecke zu interagieren.

In der Regel gibt es parallele APIs im Benutzeroberflächenautomatisierung Framework: eine API für Benutzeroberflächenautomatisierung Clients und eine andere, ähnlich benannte API für Benutzeroberflächenautomatisierung-Anbieter. In diesem Thema werden die APIs für den Benutzeroberflächenautomatisierung-Anbieter und insbesondere die Klassen und Schnittstellen behandelt, die die Anbietererweiterung in diesem Benutzeroberflächenframework ermöglichen. Gelegentlich werden Benutzeroberflächenautomatisierung APIs erwähnt, die von den Benutzeroberflächenautomatisierung Clients verwendet werden, um eine Perspektive bereitzustellen oder eine Nachschlagetabelle bereitzustellen, die die Client- und Anbieter-APIs korreliert. Weitere Informationen zur Clientperspektive finden Sie in Benutzeroberflächenautomatisierung Clientprogrammiererhandbuch.

Hinweis

Benutzeroberflächenautomatisierung Clients verwenden in der Regel keinen verwalteten Code und werden in der Regel nicht als UWP-App implementiert (normalerweise Desktop-Apps). Benutzeroberflächenautomatisierung basiert auf einem Standard und nicht auf einer bestimmten Implementierung oder einem spezifischen Framework. Viele vorhandene Benutzeroberflächenautomatisierung-Clients, einschließlich Hilfstechnologieprodukten wie Bildschirmsprachausgaben, verwenden Com-Schnittstellen (Component Object Model), um mit Benutzeroberflächenautomatisierung, dem System und den Apps zu interagieren, die in untergeordneten Fenstern ausgeführt werden. Weitere Informationen zu den COM-Schnittstellen und zum Schreiben eines Benutzeroberflächenautomatisierung Clients mithilfe von COM finden Sie unter Benutzeroberflächenautomatisierung Grundlagen.

Ermitteln des vorhandenen Zustands der Benutzeroberflächenautomatisierung Unterstützung für ihre benutzerdefinierte UI-Klasse

Bevor Sie versuchen, einen Automatisierungspeer für ein benutzerdefiniertes Steuerelement zu implementieren, sollten Sie testen, ob die Basisklasse und ihr Automatisierungspeer bereits die benötigten Barrierefreiheits- oder Automatisierungsunterstützungen bereitstellen. In vielen Fällen kann die Kombination aus FrameworkElementAutomationPeer-Implementierungen, bestimmten Peers und den mustern, die sie implementieren, eine einfache, aber zufriedenstellende Barrierefreiheitserfahrung bieten. Ob dies zutrifft, hängt davon ab, wie viele Änderungen Sie am Objektmodell vorgenommen haben, wenn Sie das Steuerelement gegenüber der Basisklasse verwenden. Außerdem hängt dies davon ab, ob Ihre Ergänzungen der Basisklassenfunktionalität mit neuen UI-Elementen im Vorlagenvertrag oder mit der visuellen Darstellung des Steuerelements korrelieren. In einigen Fällen können Ihre Änderungen neue Aspekte der Benutzererfahrung einführen, die zusätzliche Unterstützung für die Barrierefreiheit erfordern.

Selbst wenn die vorhandene Basispeerklasse die grundlegende Unterstützung für die Barrierefreiheit bietet, empfiehlt es sich weiterhin, einen Peer zu definieren, damit Sie präzise ClassName-Informationen für automatisierte Testszenarien Benutzeroberflächenautomatisierung melden können. Diese Berücksichtigung ist besonders wichtig, wenn Sie ein Steuerelement schreiben, das für den Verbrauch von Drittanbietern vorgesehen ist.

Automatisierungspeerklassen

Die UWP baut auf vorhandenen Benutzeroberflächenautomatisierung Techniken und Konventionen auf, die von früheren Benutzeroberflächenframeworks mit verwaltetem Code verwendet werden, z. B. Windows Forms, Windows Presentation Foundation (WPF) und Microsoft Silverlight. Viele der Steuerelementklassen und deren Funktion und Zweck haben auch ihren Ursprung in einem vorherigen Benutzeroberflächenframework.

Gemäß der Konvention beginnen Namen von Peerklassen mit dem Klassennamen des Steuerelements und enden mit „AutomationPeer“. Beispielsweise ist ButtonAutomationPeer die Peerklasse für die Button-Steuerelementklasse.

Hinweis

Im Rahmen dieses Themas behandeln wir die Eigenschaften, die mit der Barrierefreiheit zusammenhängen, als wichtiger, wenn Sie einen Steuerelementspeer implementieren. Für ein allgemeineres Konzept der Benutzeroberflächenautomatisierung-Unterstützung sollten Sie jedoch einen Peer gemäß den Empfehlungen implementieren, die im Handbuch des Benutzeroberflächenautomatisierung Anbieterprogrammierers und Benutzeroberflächenautomatisierung Grundlagen. In diesen Themen werden nicht die spezifischen AutomationPeer-APIs behandelt, die Sie verwenden würden, um die Informationen im UWP-Framework für Benutzeroberflächenautomatisierung bereitzustellen, aber sie beschreiben die Eigenschaften, die Ihre Klasse identifizieren oder andere Informationen oder Interaktionen bereitstellen.

Peers, Muster und Steuerelementtypen

Ein Steuerelementmuster ist eine Schnittstellenimplementierung, die einen bestimmten Aspekt der Funktionalität eines Steuerelements für einen Benutzeroberflächenautomatisierung-Client verfügbar macht. Benutzeroberflächenautomatisierung Clients verwenden die Eigenschaften und Methoden, die über ein Steuerelementmuster verfügbar gemacht werden, um Informationen zu funktionen des Steuerelements abzurufen oder das Verhalten des Steuerelements zur Laufzeit zu ändern.

Steuerelementmuster bieten eine Möglichkeit zum Kategorisieren und Verfügbarmachen der Funktionalität eines Steuerelements, unabhängig vom Typ des Steuerelements oder vom Erscheinungsbild des Steuerelements. Ein Steuerelement, das eine tabellarische Schnittstelle darstellt, verwendet z. B. das Raster-Steuerelementmuster, um die Anzahl der Zeilen und Spalten in der Tabelle verfügbar zu machen und einen Benutzeroberflächenautomatisierung Client zum Abrufen von Elementen aus der Tabelle zu aktivieren. Wie andere Beispiele kann der Benutzeroberflächenautomatisierung-Client das Aufruf-Steuerelementmuster für Steuerelemente verwenden, die aufgerufen werden können, z. B. Schaltflächen und das Scroll-Steuerelementmuster für Steuerelemente mit Bildlaufleisten, z. B. Listenfelder, Listenansichten oder Kombinationsfelder. Jedes Steuerelementmuster stellt einen separaten Funktionstyp dar, und Steuerelementmuster können kombiniert werden, um den vollständigen Satz von Funktionen zu beschreiben, die von einem bestimmten Steuerelement unterstützt werden.

Steuerelementmuster beziehen sich auf die Benutzeroberfläche als Schnittstellen auf COM-Objekte. In COM können Sie von einem Objekt abfragen, welche Schnittstellen es unterstützt, und dann mithilfe dieser Schnittstellen auf die Funktionen zugreifen. In Benutzeroberflächenautomatisierung können Benutzeroberflächenautomatisierung Clients ein Benutzeroberflächenautomatisierung-Element abfragen, um herauszufinden, welche Steuerelementmuster sie unterstützt, und dann mit dem Element und dem Peered-Steuerelement über die Eigenschaften, Methoden, Ereignisse und Strukturen, die von den unterstützten Steuerelementmustern verfügbar gemacht werden.

Einer der Hauptzwecke eines Automatisierungspeers besteht darin, einem Benutzeroberflächenautomatisierung Client zu melden, der Steuerelementmuster, die das UI-Element über seinen Peer unterstützen kann. Dazu implementieren Benutzeroberflächenautomatisierung Anbieter neue Peers, die das Verhalten der GetPattern-Methode ändern, indem die GetPatternCore-Methode überschrieben wird. Benutzeroberflächenautomatisierung Clients anrufe tätigen, die vom Benutzeroberflächenautomatisierung-Anbieter dem Aufrufen von GetPattern zugeordnet werden. Benutzeroberflächenautomatisierung Clients abfragen jedes bestimmte Muster, mit dem sie interagieren möchten. Wenn der Peer das Muster unterstützt, gibt er einen Objektverweis auf sich selbst zurück. andernfalls wird NULL zurückgegeben. Wenn die Rückgabe nicht NULL ist, erwartet der Benutzeroberflächenautomatisierung Client, dass er APIs der Musterschnittstelle als Client aufrufen kann, um mit diesem Steuerelementmuster zu interagieren.

Ein Steuerelementtyp ist eine Möglichkeit, die Funktionalität eines Steuerelements, das der Peer darstellt, allgemein zu definieren. Dies ist ein anderes Konzept als ein Steuerelementmuster, da während ein Muster informiert, Benutzeroberflächenautomatisierung welche Informationen sie abrufen kann oder welche Aktionen sie über eine bestimmte Schnittstelle ausführen können, ist der Steuerelementtyp eine Ebene darüber vorhanden. Jeder Steuerelementtyp enthält Anleitungen zu diesen Aspekten von Benutzeroberflächenautomatisierung:

• Benutzeroberflächenautomatisierung Steuerelementmuster: Ein Steuerelementtyp unterstützt möglicherweise mehrere Muster, die jeweils eine andere Klassifizierung von Informationen oder Interaktionen darstellen. Jeder Steuerelementtyp verfügt über einen Satz von Steuerelementmustern, die das Steuerelement unterstützen muss, einen optionalen Satz und einen Satz, den das Steuerelement nicht unterstützen darf.
• Benutzeroberflächenautomatisierung Eigenschaftswerte: Jeder Steuerelementtyp verfügt über eine Reihe von Eigenschaften, die das Steuerelement unterstützen muss. Dies sind die allgemeinen Eigenschaften, wie in Benutzeroberflächenautomatisierung Eigenschaftenübersicht beschrieben, nicht die Eigenschaften, die musterspezifisch sind.
• Benutzeroberflächenautomatisierung Ereignisse: Jeder Steuerelementtyp verfügt über einen Satz von Ereignissen, die das Steuerelement unterstützen muss. Auch hier handelt es sich um allgemeine, nicht musterspezifische Ereignisse, wie in Benutzeroberflächenautomatisierung Ereignisübersicht beschrieben.
• Benutzeroberflächenautomatisierung Struktur der Struktur: Jeder Steuerelementtyp definiert, wie das Steuerelement in der struktur Benutzeroberflächenautomatisierung angezeigt werden muss.

Unabhängig davon, wie Automatisierungspeers für das Framework implementiert werden, ist Benutzeroberflächenautomatisierung Clientfunktionalität nicht an die UWP gebunden, und es ist wahrscheinlich, dass vorhandene Benutzeroberflächenautomatisierung Clients wie Hilfstechnologien andere Programmiermodelle wie COM verwenden. In COM können Clients QueryInterface für die COM-Steuerelementmusterschnittstelle verwenden, die das angeforderte Muster oder das allgemeine Benutzeroberflächenautomatisierung Framework für Eigenschaften, Ereignisse oder Baumuntersuchungen implementiert. Für die Muster marshallt das Benutzeroberflächenautomatisierung Framework Code in UWP-Code, der für den Benutzeroberflächenautomatisierung Anbieter der App und dem relevanten Peer ausgeführt wird.

Wenn Sie Steuerelementmuster für ein Framework mit verwaltetem Code implementieren, z. B. eine UWP-App mit C# oder Microsoft Visual Basic, können Sie .NET Framework-Schnittstellen verwenden, um diese Muster darzustellen, anstatt die COM-Schnittstellendarstellung zu verwenden. Die Benutzeroberflächenautomatisierung Musterschnittstelle für eine Microsoft .NET-Anbieterimplementierung des Invoke-Musters lautet z. B. "IInvokeProvider".

Eine Liste der Steuerelementmuster, Anbieterschnittstellen und deren Zweck finden Sie unter Steuerelementmuster und Schnittstellen. Eine Liste der Steuerelementtypen finden Sie unter Benutzeroberflächenautomatisierung Übersicht über Steuerelementtypen.

Anleitung zum Implementieren von Steuerelementmustern

Die Steuerelementmuster und deren Zweck sind Teil einer größeren Definition des Benutzeroberflächenautomatisierung-Frameworks und gelten nicht nur für die Barrierefreiheitsunterstützung für eine UWP-App. Wenn Sie ein Steuerelementmuster implementieren, sollten Sie sicherstellen, dass Sie es auf eine Weise implementieren, die den In diesen Dokumenten dokumentierten Anleitungen entspricht, und auch in der Benutzeroberflächenautomatisierung Spezifikation. Wenn Sie nach Anleitungen suchen, können Sie in der Regel die Microsoft-Dokumentation verwenden und müssen sich nicht auf die Spezifikation beziehen. Anleitungen für jedes Muster sind hier dokumentiert: Implementieren von Benutzeroberflächenautomatisierung Steuerelementmustern. Sie werden feststellen, dass jedes Thema in diesem Bereich über einen Abschnitt "Implementierungsrichtlinien und Konventionen" und "Erforderliche Member" verfügt. Die Anleitung bezieht sich in der Regel auf bestimmte APIs der relevanten Steuerelementmusterschnittstelle in der Referenz für Steuerelementmusterschnittstellen für Anbieter . Diese Schnittstellen sind die systemeigenen/COM-Schnittstellen (und ihre APIs verwenden die SYNTAX im COM-Stil). Aber alles, was Sie sehen, hat eine Entsprechung im Windows.UI.Xaml.Automation.Provider-Namespace.

Wenn Sie die Standardautomatisierungspeers verwenden und ihr Verhalten erweitern, wurden diese Peers bereits in Übereinstimmung mit Benutzeroberflächenautomatisierung Richtlinien geschrieben. Wenn sie Steuerelementmuster unterstützen, können Sie sich auf diese Musterunterstützung verlassen, die den Richtlinien bei der Implementierung von Benutzeroberflächenautomatisierung Steuerelementmustern entspricht. Wenn ein Steuerelementspeer meldet, dass er für einen steuerelementtyp steht, der durch Benutzeroberflächenautomatisierung definiert ist, wurde der Leitfaden unter "Unterstützende Benutzeroberflächenautomatisierung-Steuerelementtypen" von diesem Peer befolgt.

Dennoch benötigen Sie möglicherweise zusätzliche Anleitungen für Steuerelementmuster oder Steuerelementtypen, um die Benutzeroberflächenautomatisierung Empfehlungen in Ihrer Peerimplementierung zu befolgen. Dies wäre besonders dann der Fall, wenn Sie Muster- oder Steuerelementtypunterstützung implementieren, die noch nicht als Standardimplementierung in einem UWP-Steuerelement vorhanden ist. Beispielsweise wird das Muster für Anmerkungen nicht in einem der standardmäßigen XAML-Steuerelemente implementiert. Möglicherweise verfügen Sie jedoch über eine App, die Anmerkungen umfassend verwendet, und daher möchten Sie diese Funktionalität anzeigen, um barrierefrei zu sein. In diesem Szenario sollte Ihr Peer IAnnotationProvider implementieren und sich wahrscheinlich als Dokumentsteuerelementtyp mit entsprechenden Eigenschaften melden, um anzugeben, dass Ihre Dokumente Anmerkungen unterstützen.

Es wird empfohlen, die Anleitungen zu verwenden, die Sie für die Muster unter Implementieren von Benutzeroberflächenautomatisierung Steuerelementmustern oder Steuerelementtypen unter Unterstützen von Benutzeroberflächenautomatisierung Steuerelementtypen als Ausrichtung und allgemeine Anleitungen anzeigen. Sie können sogar versuchen, einige der API-Links für Beschreibungen und Hinweise zum Zweck der APIs zu folgen. Für Syntaxspezifien, die für die Programmierung von UWP-Apps erforderlich sind, finden Sie jedoch die entsprechende API im Windows.UI.Xaml.Automation.Provider-Namespace , und verwenden Sie diese Referenzseiten, um weitere Informationen zu erhalten.

Integrierte Automatisierungspeerklassen

Im Allgemeinen implementieren Elemente eine Automatisierungspeerklasse, wenn sie Benutzeroberflächenaktivitäten vom Benutzer akzeptieren oder Informationen enthalten, die von Benutzern von Hilfstechnologien benötigt werden, die die interaktive oder aussagekräftige Benutzeroberfläche von Apps darstellen. Nicht alle visuellen UWP-Elemente verfügen über Automatisierungspeers. Beispiele für Klassen, die Automatisierungspeers implementieren, sind Button und TextBox. Beispiele für Klassen, die keine Automatisierungspeers implementieren, sind Rahmen und Klassen, die auf Panel basieren, z. B. "Grid" und "Canvas". Ein Panel hat keinen Peer, da es ein Layoutverhalten bereitstellt, das nur visuell ist. Es gibt keine Barrierefreiheitsrelevante Möglichkeit, damit der Benutzer mit einem Panel interagiert. Alle untergeordneten Elemente, die ein Panel enthält, werden stattdessen Benutzeroberflächenautomatisierung als untergeordnete Elemente des nächsten verfügbaren übergeordneten Elements in der Struktur mit einer Peer- oder Elementdarstellung gemeldet.

Benutzeroberflächenautomatisierung- und UWP-Prozessgrenzen

In der Regel wird Benutzeroberflächenautomatisierung Clientcode, der auf eine UWP-App zugreift, außerhalb des Prozesses ausgeführt. Die Benutzeroberflächenautomatisierung Frameworkinfrastruktur ermöglicht informationen, über die Prozessgrenzen hinweg zu gelangen. Dieses Konzept wird in Benutzeroberflächenautomatisierung Grundlagen ausführlicher erläutert.

OnCreateAutomationPeer

Alle Klassen, die von UIElement abgeleitet werden, enthalten die geschützte virtuelle Methode "OnCreateAutomationPeer". Die Objektinitialisierungssequenz für Automatisierungspeers ruft OnCreateAutomationPeer auf, um das Automatisierungspeerobjekt für jedes Steuerelement abzurufen und damit eine Benutzeroberflächenautomatisierung Struktur zur Laufzeitverwendung zu erstellen. Benutzeroberflächenautomatisierung Code kann den Peer verwenden, um Informationen zu den Merkmalen und Features eines Steuerelements abzurufen und die interaktive Verwendung mithilfe seiner Steuerelementmuster zu simulieren. Ein benutzerdefiniertes Steuerelement, das die Automatisierung unterstützt, muss OnCreateAutomationPeer überschreiben und eine Instanz einer Klasse zurückgeben, die von AutomationPeer abgeleitet ist. Wenn beispielsweise ein benutzerdefiniertes Steuerelement von der ButtonBase-Klasse abgeleitet ist, sollte das von OnCreateAutomationPeer zurückgegebene Objekt von ButtonBaseAutomationPeer abgeleitet werden.

Wenn Sie eine benutzerdefinierte Steuerelementklasse schreiben und auch einen neuen Automatisierungspeer bereitstellen möchten, sollten Sie die OnCreateAutomationPeer-Methode für ihr benutzerdefiniertes Steuerelement überschreiben, sodass sie eine neue Instanz Ihres Peers zurückgibt. Ihre Peerklasse muss direkt oder indirekt von AutomationPeer abgeleitet werden.

Der folgende Code deklariert beispielsweise, dass das benutzerdefinierte Steuerelement NumericUpDown den Peer NumericUpDownPeer für Benutzeroberflächenautomatisierung Zwecke verwenden soll.

using Windows.UI.Xaml.Automation.Peers;
...
public class NumericUpDown : RangeBase {
    public NumericUpDown() {
    // other initialization; DefaultStyleKey etc.
    }
    ...
    protected override AutomationPeer OnCreateAutomationPeer()
    {
        return new NumericUpDownAutomationPeer(this);
    }
}

Public Class NumericUpDown
    Inherits RangeBase
    ' other initialization; DefaultStyleKey etc.
       Public Sub New()
       End Sub
       Protected Overrides Function OnCreateAutomationPeer() As AutomationPeer
              Return New NumericUpDownAutomationPeer(Me)
       End Function
End Class

// NumericUpDown.idl
namespace MyNamespace
{
    runtimeclass NumericUpDown : Windows.UI.Xaml.Controls.Primitives.RangeBase
    {
        NumericUpDown();
        Int32 MyProperty;
    }
}

// NumericUpDown.h
...
struct NumericUpDown : NumericUpDownT<NumericUpDown>
{
	...
    Windows::UI::Xaml::Automation::Peers::AutomationPeer OnCreateAutomationPeer()
    {
        return winrt::make<MyNamespace::implementation::NumericUpDownAutomationPeer>(*this);
    }
};

//.h
public ref class NumericUpDown sealed : Windows::UI::Xaml::Controls::Primitives::RangeBase
{
// other initialization not shown
protected:
    virtual AutomationPeer^ OnCreateAutomationPeer() override
    {
         return ref new NumericUpDownAutomationPeer(this);
    }
};

Hinweis

Die OnCreateAutomationPeer-Implementierung sollte nichts anderes tun, als eine neue Instanz Ihres benutzerdefinierten Automatisierungspeers zu initialisieren, das aufrufende Steuerelement als Besitzer zu übergeben und diese Instanz zurückzugeben. Versuchen Sie in dieser Methode nicht, zusätzliche Logik zu verwenden. Insbesondere kann jede Logik, die potenziell zur Zerstörung von AutomationPeer innerhalb desselben Aufrufs führen kann, zu unerwartetem Laufzeitverhalten führen.

In typischen Implementierungen von "OnCreateAutomationPeer" wird der Besitzer als "This" oder "Me" angegeben, da sich die Methodenüberschreibung im gleichen Bereich wie der Rest der Steuerelementklassendefinition befindet.

Die tatsächliche Peerklassendefinition kann in derselben Codedatei wie das Steuerelement oder in einer separaten Codedatei erfolgen. Die Peerdefinitionen sind alle im Windows.UI.Xaml.Automation.Peers-Namespace vorhanden, der einen separaten Namespace von den Steuerelementen darstellt, für die sie Peers bereitstellen. Sie können ihre Peers auch in separaten Namespaces deklarieren, solange Sie auf die erforderlichen Namespaces für den OnCreateAutomationPeer-Methodenaufruf verweisen.

Auswählen der richtigen Peerbasisklasse

Stellen Sie sicher, dass Ihr AutomationPeer von einer Basisklasse abgeleitet wird, die Ihnen die beste Übereinstimmung für die vorhandene Peerlogik der Steuerelementklasse bietet, von der Sie ableiten. Im Fall des vorherigen Beispiels, da NumericUpDown es von RangeBase abgeleitet ist, ist eine RangeBaseAutomationPeer-Klasse verfügbar, auf derEn Basis Sie Ihren Peer verwenden sollten. Wenn Sie parallel zur Ableitung des Steuerelements die am ehesten übereinstimmende Peerklasse verwenden, können Sie mindestens einige der IRangeValueProvider-Funktionen außer Kraft setzen, da die Basispeerklasse es bereits implementiert.

Die Basissteuerelementklasse verfügt nicht über eine entsprechende Peerklasse. Wenn Sie eine Peerklasse benötigen, um einem benutzerdefinierten Steuerelement zu entsprechen, das von Control abgeleitet wird, leiten Sie die benutzerdefinierte Peerklasse von FrameworkElementAutomationPeer ab.

Wenn Sie direkt von ContentControl abgeleitet werden, weist diese Klasse kein standardmäßiges Automatisierungspeerverhalten auf, da keine OnCreateAutomationPeer-Implementierung vorhanden ist, die auf eine Peerklasse verweist. Stellen Sie also sicher, dass Sie "OnCreateAutomationPeer" implementieren, um Ihren eigenen Peer zu verwenden, oder um FrameworkElementAutomationPeer als Peer zu verwenden, wenn diese Ebene der Barrierefreiheitsunterstützung für Ihr Steuerelement ausreichend ist.

Hinweis

Sie leiten in der Regel nicht von AutomationPeer und nicht von "FrameworkElementAutomationPeer" ab. Wenn Sie direkt von AutomationPeer abgeleitet wurden, müssen Sie viele grundlegende Barrierefreiheitsunterstützung duplizieren, die andernfalls von FrameworkElementAutomationPeer stammen.

Initialisierung einer benutzerdefinierten Peerklasse

Der Automatisierungspeer sollte einen typsicheren Konstruktor definieren, der eine Instanz des Besitzersteuerelements für die Basisinitialisierung verwendet. Im nächsten Beispiel übergibt die Implementierung den Besitzerwert an die RangeBaseAutomationPeer-Basis, und letztendlich ist es der FrameworkElementAutomationPeer, der den Besitzer zum Festlegen von FrameworkElementAutomationPeer.Owner verwendet.

public NumericUpDownAutomationPeer(NumericUpDown owner): base(owner)
{}

Public Sub New(owner As NumericUpDown)
    MyBase.New(owner)
End Sub

// NumericUpDownAutomationPeer.idl
import "NumericUpDown.idl";
namespace MyNamespace
{
    runtimeclass NumericUpDownAutomationPeer : Windows.UI.Xaml.Automation.Peers.AutomationPeer
    {
        NumericUpDownAutomationPeer(NumericUpDown owner);
        Int32 MyProperty;
    }
}

// NumericUpDownAutomationPeer.h
...
struct NumericUpDownAutomationPeer : NumericUpDownAutomationPeerT<NumericUpDownAutomationPeer>
{
    ...
    NumericUpDownAutomationPeer(MyNamespace::NumericUpDown const& owner);
};

//.h
public ref class NumericUpDownAutomationPeer sealed :  Windows::UI::Xaml::Automation::Peers::RangeBaseAutomationPeer
//.cpp
public:    NumericUpDownAutomationPeer(NumericUpDown^ owner);

Kernmethoden von AutomationPeer

Aus UWP-Infrastrukturgründen sind die überschreibbaren Methoden eines Automatisierungspeers Teil eines Methodenpaars: die Öffentliche Zugriffsmethode, die der Benutzeroberflächenautomatisierung-Anbieter als Weiterleitungspunkt für Benutzeroberflächenautomatisierung Clients verwendet, und die geschützte "Core"-Anpassungsmethode, die eine UWP-Klasse überschreiben kann, um das Verhalten zu beeinflussen. Das Methodenpaar wird standardmäßig so verkabelt, dass der Aufruf der Zugriffsmethode immer die parallele "Core"-Methode aufruft, die über die Anbieterimplementierung oder als Fallback verfügt, eine Standardimplementierung aus den Basisklassen aufruft.

Wenn Sie einen Peer für ein benutzerdefiniertes Steuerelement implementieren, überschreiben Sie eine der "Core"-Methoden aus der Basisautomatisierungspeerklasse, in der Sie das für Ihr benutzerdefiniertes Steuerelement eindeutige Verhalten verfügbar machen möchten. Benutzeroberflächenautomatisierung Code ruft Informationen zu Ihrem Steuerelement ab, indem öffentliche Methoden der Peerklasse aufgerufen werden. Um Informationen zu Ihrem Steuerelement bereitzustellen, überschreiben Sie jede Methode mit einem Namen, der mit "Core" endet, wenn ihre Steuerelementimplementierung und -design Barrierefreiheitsszenarien oder andere Benutzeroberflächenautomatisierung Szenarien erstellt, die sich von den von der Basisautomatisierungspeerklasse unterstützten Szenarien unterscheiden.

Wenn Sie mindestens eine neue Peerklasse definieren, implementieren Sie die GetClassNameCore-Methode , wie im nächsten Beispiel gezeigt.

protected override string GetClassNameCore()
{
    return "NumericUpDown";
}

Hinweis

Möglicherweise möchten Sie die Zeichenfolgen nicht direkt im Methodentext, sondern als Konstanten speichern, das liegt jedoch bei Ihnen. Für GetClassNameCore müssen Sie diese Zeichenfolge nicht lokalisieren. Die LocalizedControlType-Eigenschaft wird immer verwendet, wenn eine lokalisierte Zeichenfolge von einem Benutzeroberflächenautomatisierung-Client benötigt wird, nicht von ClassName.

GetAutomationControlType

Einige Hilfstechnologien verwenden den GetAutomationControlType-Wert direkt beim Melden von Merkmalen der Elemente in einer Benutzeroberflächenautomatisierung Struktur als zusätzliche Informationen über den Benutzeroberflächenautomatisierung Namen hinaus. Wenn sich Ihr Steuerelement erheblich von dem Steuerelement unterscheidet, von dem Sie ableiten und einen anderen Steuerelementtyp melden möchten, der von der Basispeerklasse gemeldet wird, die vom Steuerelement verwendet wird, müssen Sie einen Peer implementieren und GetAutomationControlTypeCore in Ihrer Peerimplementierung außer Kraft setzen. Dies ist besonders wichtig, wenn Sie von einer generalisierten Basisklasse wie ItemsControl oder ContentControl abgeleitet werden, bei der der Basispeer keine präzisen Informationen zum Steuerelementtyp bereitstellt.

Ihre Implementierung von GetAutomationControlTypeCore beschreibt Ihr Steuerelement, indem ein AutomationControlType-Wert zurückgegeben wird. Obwohl Sie AutomationControlType.Custom zurückgeben können, sollten Sie einen der spezifischeren Steuerelementtypen zurückgeben, wenn es die Hauptszenarien Ihres Steuerelements genau beschreibt. Im Folgenden sehen Sie ein Beispiel.

protected override AutomationControlType GetAutomationControlTypeCore()
{
    return AutomationControlType.Spinner;
}

Hinweis

Sofern Sie "AutomationControlType.Custom" nicht angeben, müssen Sie GetLocalizedControlTypeCore nicht implementieren, um einen LocalizedControlType-Eigenschaftswert für Clients bereitzustellen. Benutzeroberflächenautomatisierung allgemeine Infrastruktur stellt übersetzte Zeichenfolgen für alle möglichen Möglichkeiten bereit.AutomationControlType-Wert außer AutomationControlType.Custom.

GetPattern und GetPatternCore

Die Implementierung eines Peers von GetPatternCore gibt das Objekt zurück, das das im Eingabeparameter angeforderte Muster unterstützt. Insbesondere ruft ein Benutzeroberflächenautomatisierung-Client eine Methode auf, die an die GetPattern-Methode des Anbieters weitergeleitet wird, und gibt einen PatternInterface-Enumerationswert an, der das angeforderte Muster benennt. Die Außerkraftsetzung von GetPatternCore sollte das Objekt zurückgeben, das das angegebene Muster implementiert. Dieses Objekt ist der Peer selbst, da der Peer die entsprechende Musterschnittstelle jedes Mal implementieren sollte, wenn es meldet, dass es ein Muster unterstützt. Wenn Ihr Peer nicht über eine benutzerdefinierte Implementierung eines Musters verfügt, Sie aber wissen, dass die Basis des Peers das Muster implementiert, können Sie die Implementierung des Basistyps von GetPatternCore aus Ihrem GetPatternCore aufrufen. GetPatternCore eines Peers sollte NULL zurückgeben, wenn ein Muster vom Peer nicht unterstützt wird. Anstatt jedoch null direkt aus Ihrer Implementierung zurückzugeben, würden Sie in der Regel auf den Aufruf der Basisimplementierung angewiesen, um null für jedes nicht unterstützte Muster zurückzugeben.

Wenn ein Muster unterstützt wird, kann die GetPatternCore-Implementierung diesen oder me zurückgeben. Die Erwartung besteht darin, dass der Benutzeroberflächenautomatisierung Client den GetPattern-Rückgabewert in die angeforderte Musterschnittstelle umwandeln wird, wenn er nicht NULL ist.

Wenn eine Peerklasse von einem anderen Peer erbt und alle erforderlichen Unterstützungs- und Musterberichte bereits von der Basisklasse behandelt werden, ist die Implementierung von GetPatternCore nicht erforderlich. Wenn Sie beispielsweise ein Bereichssteuerelement implementieren, das von RangeBase abgeleitet ist und Ihr Peer von RangeBaseAutomationPeer abgeleitet ist, gibt dieser Peer sich für PatternInterface.RangeValue zurück und verfügt über funktionierende Implementierungen der IRangeValueProvider-Schnittstelle, die das Muster unterstützt.

Obwohl es sich nicht um den Literalcode handelt, nähert sich dieses Beispiel der Implementierung von GetPatternCore an, die bereits in RangeBaseAutomationPeer vorhanden ist.

protected override object GetPatternCore(PatternInterface patternInterface)
{
    if (patternInterface == PatternInterface.RangeValue)
    {
        return this;
    }
    return base.GetPatternCore(patternInterface);
}

Wenn Sie einen Peer implementieren, bei dem Sie nicht über alle Unterstützung verfügen, die Sie von einer Basispeerklasse benötigen, oder Sie den Satz von basisvererbten Mustern ändern oder hinzufügen möchten, die Ihr Peer unterstützen kann, sollten Sie GetPatternCore außer Kraft setzen, um Benutzeroberflächenautomatisierung Clients die Verwendung der Muster zu ermöglichen.

Eine Liste der Anbietermuster, die in der UWP-Implementierung von Benutzeroberflächenautomatisierung-Unterstützung verfügbar sind, finden Sie unter "Windows.UI.Xaml.Automation.Provider". Jedes solche Muster weist einen entsprechenden Wert der PatternInterface-Aufzählung auf, wodurch Benutzeroberflächenautomatisierung Clients das Muster in einem GetPattern-Aufruf anfordern.

Ein Peer kann melden, dass er mehrere Muster unterstützt. In diesem Fall sollte die Außerkraftsetzung die Rückgabepfadlogik für jeden unterstützten PatternInterface-Wert enthalten und den Peer in jedem übereinstimmenden Fall zurückgeben. Es wird erwartet, dass der Aufrufer jeweils nur eine Schnittstelle anfordert, und es liegt bei dem Aufrufer, in die erwartete Schnittstelle zu umwandeln.

Hier ist ein Beispiel für eine GetPatternCore-Außerkraftsetzung für einen benutzerdefinierten Peer. Es meldet die Unterstützung für zwei Muster, IRangeValueProvider und IToggleProvider. Das Steuerelement hier ist ein Medienanzeigesteuerelement, das als Vollbildmodus (Umschaltmodus) angezeigt werden kann und über eine Statusleiste verfügt, in der Benutzer eine Position (das Bereichssteuerelement) auswählen können. Dieser Code stammt aus dem XAML-Beispiel für die Barrierefreiheit.

protected override object GetPatternCore(PatternInterface patternInterface)
{
    if (patternInterface == PatternInterface.RangeValue)
    {
        return this;
    }
    else if (patternInterface == PatternInterface.Toggle)
    {
        return this;
    }
    return null;
}

Weiterleiten von Mustern aus Unterelementen

Eine GetPatternCore-Methodenimplementierung kann auch ein Unterelement oder Teil als Musteranbieter für seinen Host angeben. In diesem Beispiel wird nachgeahmt, wie ItemsControl die Bildlaufmusterbehandlung an den Peer des internen ScrollViewer-Steuerelements überträgt. Um ein Unterelement für die Musterbehandlung anzugeben, ruft dieser Code das Unterelementobjekt ab, erstellt einen Peer für das Unterelement mithilfe der FrameworkElementAutomationPeer.CreatePeerForElement-Methode und gibt den neuen Peer zurück.

protected override object GetPatternCore(PatternInterface patternInterface)
{
    if (patternInterface == PatternInterface.Scroll)
    {
        ItemsControl owner = (ItemsControl) base.Owner;
        UIElement itemsHost = owner.ItemsHost;
        ScrollViewer element = null;
        while (itemsHost != owner)
        {
            itemsHost = VisualTreeHelper.GetParent(itemsHost) as UIElement;
            element = itemsHost as ScrollViewer;
            if (element != null)
            {
                break;
            }
        }
        if (element != null)
        {
            AutomationPeer peer = FrameworkElementAutomationPeer.CreatePeerForElement(element);
            if ((peer != null) && (peer is IScrollProvider))
            {
                return (IScrollProvider) peer;
            }
        }
    }
    return base.GetPatternCore(patternInterface);
}

Andere Core-Methoden

Ihr Steuerelement muss möglicherweise Tastaturentsprechungen für primäre Szenarien unterstützen. weitere Informationen dazu, warum dies erforderlich sein könnte, finden Sie unter Barrierefreiheit der Tastatur. Die Implementierung der Schlüsselunterstützung ist notwendigerweise Teil des Steuerelementcodes und nicht des Peercodes, da dies Teil der Logik eines Steuerelements ist, aber Ihre Peerklasse sollte die GetAcceleratorKeyCore- und GetAccessKeyCore-Methoden überschreiben, um Benutzeroberflächenautomatisierung Clients zu melden, welche Schlüssel verwendet werden. Berücksichtigen Sie, dass die Zeichenfolgen, die wichtige Informationen melden, möglicherweise lokalisiert werden müssen und daher aus Ressourcen stammen sollten, nicht hartcodierte Zeichenfolgen.

Wenn Sie einen Peer für eine Klasse bereitstellen, die eine Sammlung unterstützt, empfiehlt es sich, von funktionalen Klassen und Peerklassen abzuleiten, die bereits über diese Art von Sammlungsunterstützung verfügen. Wenn dies nicht möglich ist, müssen Peers für Steuerelemente, die untergeordnete Sammlungen verwalten, möglicherweise die sammlungsbezogene Peermethode GetChildrenCore außer Kraft setzen, um die Beziehungen zwischen übergeordneten und untergeordneten Elementen ordnungsgemäß an die Benutzeroberflächenautomatisierung Struktur zu melden.

Implementieren Sie die Methoden IsContentElementCore und IsControlElementCore, um anzugeben, ob Ihr Steuerelement Dateninhalte enthält oder eine interaktive Rolle auf der Benutzeroberfläche (oder beides) erfüllt. Standardmäßig geben beide Methoden "true" zurück. Diese Einstellungen verbessern die Benutzerfreundlichkeit von Hilfstechnologien wie Bildschirmsprachausgaben, die diese Methoden verwenden können, um die Automatisierungsstruktur zu filtern. Wenn Ihre GetPatternCore-Methode die Musterbehandlung an einen Unterelement-Peer überträgt, kann die IsControlElementCore-Methode des Unterelement-Peers "false" zurückgeben, um den Unterelement-Peer aus der Automatisierungsstruktur auszublenden.

Einige Steuerelemente unterstützen möglicherweise Bezeichnungsszenarien, in denen ein Textbeschriftungsteil Informationen für einen Nicht-Textteil bereitstellt oder ein Steuerelement in einer bekannten Bezeichnungsbeziehung mit einem anderen Steuerelement in der Benutzeroberfläche enthalten sein soll. Wenn es möglich ist, ein nützliches klassenbasiertes Verhalten bereitzustellen, können Sie GetLabeledByCore außer Kraft setzen, um dieses Verhalten bereitzustellen.

GetBoundingRectangleCore und GetClickablePointCore werden hauptsächlich für automatisierte Testszenarien verwendet. Wenn Sie automatisierte Tests für Ihr Steuerelement unterstützen möchten, sollten Sie diese Methoden außer Kraft setzen. Dies kann für Bereichssteuerelemente gewünscht werden, bei denen Sie nicht nur einen einzelnen Punkt vorschlagen können, da der Benutzer auf den Koordinatenbereich klickt, einen anderen Effekt auf einen Bereich hat. Beispielsweise überschreibt der standardmäßige ScrollBar-Automatisierungspeer GetClickablePointCore, um einen Punktwert "keine Zahl" zurückzugeben.

GetLiveSettingCore beeinflusst den Steuerelementstandard für den LiveSetting-Wert für Benutzeroberflächenautomatisierung. Möglicherweise möchten Sie dies außer Kraft setzen, wenn Ihr Steuerelement einen anderen Wert als AutomationLiveSetting.Off zurückgeben soll. Weitere Informationen dazu, was LiveSetting darstellt, finden Sie unter AutomationProperties.LiveSetting.

Sie können GetOrientationCore außer Kraft setzen, wenn Ihr Steuerelement über eine settable-Ausrichtungseigenschaft verfügt, die automatisierungsorientation zugeordnet werden kann. Die Klassen ScrollBarAutomationPeer und SliderAutomationPeer tun dies.

Basisimplementierung in FrameworkElementAutomationPeer

Die Basisimplementierung von FrameworkElementAutomationPeer bietet einige Benutzeroberflächenautomatisierung Informationen, die von verschiedenen Layout- und Verhaltenseigenschaften interpretiert werden können, die auf der Frameworkebene definiert sind.

• GetBoundingRectangleCore: Gibt eine Rect-Struktur basierend auf den bekannten Layoutmerkmalen zurück. Gibt ein 0-Wert-Rect zurück, wenn IsOffscreen true ist.
• GetClickablePointCore: Gibt eine Punktstruktur basierend auf den bekannten Layoutmerkmalen zurück, solange ein nonzero BoundingRectangle vorhanden ist.
• GetNameCore: Umfassenderes Verhalten als hier zusammengefasst werden kann; siehe GetNameCore. Im Grunde wird versucht, eine Zeichenfolgenkonvertierung für alle bekannten Inhalte eines ContentControl oder verwandter Klassen mit Inhalt durchzuführen. Wenn ein Wert für "LabeledBy" vorhanden ist, wird der Name-Wert dieses Elements auch als Name verwendet.
• HasKeyboardFocusCore: Ausgewertet basierend auf den FocusState- und IsEnabled-Eigenschaften des Besitzers. Elemente, die keine Steuerelemente sind, geben immer "false" zurück.
• IsEnabledCore: Wird basierend auf der IsEnabled-Eigenschaft des Besitzers ausgewertet, wenn es sich um ein Steuerelement handelt. Elemente, die keine Steuerelemente sind, geben immer "true" zurück. Dies bedeutet nicht, dass der Besitzer im herkömmlichen Interaktionssinn aktiviert ist; dies bedeutet, dass der Peer aktiviert ist, obwohl der Besitzer keine IsEnabled-Eigenschaft hat.
• IsKeyboardFocusableCore: Gibt "true" zurück, wenn besitzer ein Steuerelement ist; andernfalls "false".
• IsOffscreenCore: Eine Sichtbarkeit von Collapsed für das Besitzerelement oder eines der übergeordneten Elemente entspricht einem echten Wert für IsOffscreen. Ausnahme: Ein Popupobjekt kann auch dann angezeigt werden, wenn die übergeordneten Elemente des Besitzers nicht vorhanden sind.
• SetFocusCore: Ruft den Fokus auf.
• GetParent: Ruft FrameworkElement.Parent vom Besitzer auf und sucht den entsprechenden Peer. Dies ist kein Außerkraftsetzungspaar mit einer "Core"-Methode, sodass Sie dieses Verhalten nicht ändern können.

Hinweis

Standardmäßige UWP-Peers implementieren ein Verhalten mithilfe von internem systemeigenen Code, der die UWP implementiert, nicht unbedingt mithilfe tatsächlichen UWP-Codes. Sie können den Code oder die Logik der Implementierung nicht über clR-Spiegelung (Common Language Runtime) oder andere Techniken anzeigen. Außerdem werden für unterklassenspezifische Außerkraftsetzungen des Basispeerverhaltens keine eindeutigen Referenzseiten angezeigt. Es kann z. B. zusätzliches Verhalten für "GetNameCore" einer TextBoxAutomationPeer geben, das auf der Referenzseite "AutomationPeer.GetNameCore" nicht beschrieben wird, und es gibt keine Referenzseite für TextBoxAutomationPeer.GetNameCore. Es gibt nicht einmal eine TextBoxAutomationPeer.GetNameCore-Referenzseite . Lesen Sie stattdessen das Referenzthema für die unmittelbarste Peerklasse, und suchen Sie im Abschnitt "Hinweise" nach Implementierungsnotizen.

Peers und AutomationProperties

Ihr Automatisierungspeer sollte geeignete Standardwerte für die Barrierefreiheitsinformationen Ihres Steuerelements bereitstellen. Beachten Sie, dass jeder App-Code, der das Steuerelement verwendet, einige dieses Verhalten außer Kraft setzen kann, indem AutomatisierungProperties-Eigenschaftswerte in Steuerelementinstanzen eingeschlossen werden. Aufrufer können dies entweder für die Standardsteuerelemente oder für benutzerdefinierte Steuerelemente tun. Der folgende XAML-Code erstellt beispielsweise eine Schaltfläche mit zwei angepassten Benutzeroberflächenautomatisierung Eigenschaften:<Button AutomationProperties.Name="Special" AutomationProperties.HelpText="This is a special button."/>

Weitere Informationen zu angefügten AutomationProperties-Eigenschaften finden Sie unter Grundlegende Informationen zur Barrierefreiheit.

Einige der AutomationPeer-Methoden sind aufgrund des allgemeinen Vertrags darüber vorhanden, wie Benutzeroberflächenautomatisierung Anbieter Informationen melden sollen, aber diese Methoden werden in der Regel nicht in Steuerelementpeers implementiert. Dies liegt daran, dass diese Informationen von AutomationProperties-Werten bereitgestellt werden sollen, die auf den App-Code angewendet werden, der die Steuerelemente in einer bestimmten Benutzeroberfläche verwendet. Die meisten Apps definieren beispielsweise die Bezeichnungsbeziehung zwischen zwei verschiedenen Steuerelementen auf der Benutzeroberfläche, indem ein AutomationProperties.LabeledBy-Wert angewendet wird. LabeledByCore wird jedoch in bestimmten Peers implementiert, die Daten- oder Elementbeziehungen in einem Steuerelement darstellen, z. B. die Verwendung eines Kopfzeilenteils zum Bezeichnen eines Datenfeldteils, das Bezeichnen von Elementen mit ihren Containern oder ähnliche Szenarien.

Implementieren von Mustern

Sehen wir uns an, wie ein Peer für ein Steuerelement geschrieben wird, das ein Expand-Collapse-Verhalten implementiert, indem die Steuerelementmusterschnittstelle für expand-collapse implementiert wird. Der Peer sollte die Barrierefreiheit für das Verhalten zum Erweitern reduzieren aktivieren, indem er sich selbst zurückgibt, wenn GetPattern mit dem Wert PatternInterface.ExpandCollapse aufgerufen wird. Der Peer sollte dann die Anbieterschnittstelle für dieses Muster (IExpandCollapseProvider) erben und Implementierungen für die einzelnen Member dieser Anbieterschnittstelle bereitstellen. In diesem Fall verfügt die Schnittstelle über drei Zuschreibungsmitglieder: Expand, Collapse, ExpandCollapseState.

Es ist hilfreich, die Barrierefreiheit im API-Design der Klasse selbst vorauszuplanen. Wenn Sie ein Verhalten haben, das möglicherweise aufgrund typischer Interaktionen mit einem Benutzer angefordert wird, der in der Benutzeroberfläche oder über ein Automatisierungsanbietermuster arbeitet, stellen Sie eine einzelne Methode bereit, die entweder die UI-Antwort oder das Automatisierungsmuster aufrufen kann. Wenn Ihr Steuerelement beispielsweise Über Schaltflächenteile mit verkabelten Ereignishandlern verfügt, die das Steuerelement erweitern oder reduzieren können, und über Tastaturentsprechungen für diese Aktionen verfügen, rufen diese Ereignishandler dieselbe Methode auf, die Sie im Textkörper der Expand- oder Collapse-Implementierungen für IExpandCollapseProvider im Peer aufrufen. Die Verwendung einer allgemeinen Logikmethode kann auch hilfreich sein, um sicherzustellen, dass die visuellen Zustände des Steuerelements aktualisiert werden, um den logischen Zustand auf einheitliche Weise anzuzeigen, unabhängig davon, wie das Verhalten aufgerufen wurde.

Eine typische Implementierung besteht darin, dass die Anbieter-APIs zuerst Besitzer für den Zugriff auf die Steuerelementinstanz zur Laufzeit aufrufen. Anschließend können die erforderlichen Verhaltensmethoden für dieses Objekt aufgerufen werden.

public class IndexCardAutomationPeer : FrameworkElementAutomationPeer, IExpandCollapseProvider {
    private IndexCard ownerIndexCard;
    public IndexCardAutomationPeer(IndexCard owner) : base(owner)
    {
         ownerIndexCard = owner;
    }
}

Eine alternative Implementierung besteht darin, dass das Steuerelement selbst auf seinen Peer verweisen kann. Dies ist ein gängiges Muster, wenn Sie Automatisierungsereignisse aus dem Steuerelement auslösen, da die RaiseAutomationEvent-Methode eine Peermethode ist.

Benutzeroberflächenautomatisierung-Ereignisse

Benutzeroberflächenautomatisierungs-Ereignisse werden in die folgenden Kategorien unterteilt.

Ereignis	Beschreibung
Eigenschaftenänderung	Wird ausgelöst, wenn sich eine Eigenschaft in einem Benutzeroberflächenautomatisierung Element oder Steuerelementmuster ändert. Wenn ein Client beispielsweise das Kontrollkästchen-Steuerelement einer App überwachen muss, kann er sich registrieren, um auf ein Eigenschaftsänderungsereignis für die ToggleState-Eigenschaft zu lauschen. Wenn das Kontrollkästchen-Steuerelement aktiviert oder deaktiviert ist, löst der Anbieter das Ereignis aus, und der Client kann nach Bedarf handeln.
Elementaktion	Wird ausgelöst, wenn eine Änderung der Benutzeroberfläche aus benutzer- oder programmgesteuerter Aktivität resultiert; Wenn beispielsweise über das Aufrufmuster auf eine Schaltfläche geklickt oder aufgerufen wird.
Strukturänderung	Wird ausgelöst, wenn sich die Struktur der Benutzeroberflächenautomatisierung Struktur ändert. Die Struktur wird geändert, wenn neue Benutzeroberflächenelemente angezeigt, ausgeblendet oder vom Desktop entfernt werden.
Globale Änderung	Wird ausgelöst, wenn Aktionen von globalem Interesse für den Client auftreten, z. B. wenn der Fokus von einem Element zu einem anderen wechselt oder wenn ein untergeordnetes Fenster geschlossen wird. Einige Ereignisse bedeuten nicht zwangsläufig, dass sich der Zustand der Benutzeroberfläche geändert hat. Wenn der Benutzer beispielsweise zu einem Texteingabefeld tabstoppt und dann auf eine Schaltfläche klickt, um das Feld zu aktualisieren, wird ein TextChanged-Ereignis ausgelöst, auch wenn der Benutzer den Text nicht tatsächlich geändert hat. Bei der Verarbeitung eines Ereignisses muss eine Clientanwendung möglicherweise erst überprüfen, ob sich tatsächlich etwas geändert hat, bevor eine Aktion ausgeführt wird.

AutomationEvents-Bezeichner

Benutzeroberflächenautomatisierung Ereignisse werden durch AutomationEvents-Werte. Die Werte der Enumeration identifizieren eindeutig die Art des Ereignisses.

Auslösen von Ereignissen

Benutzeroberflächenautomatisierung Clients können Automatisierungsereignisse abonnieren. Im Automatisierungspeermodell müssen Peers für benutzerdefinierte Steuerelemente Änderungen am Steuerelementstatus melden, die für die Barrierefreiheit relevant sind, indem die RaiseAutomationEvent-Methode aufgerufen wird. Wenn sich ein Schlüssel Benutzeroberflächenautomatisierung Eigenschaftswert ändert, sollten benutzerdefinierte Steuerelementspeers die RaisePropertyChangedEvent-Methode aufrufen.

Das nächste Codebeispiel zeigt, wie das Peerobjekt aus dem Steuerelementdefinitionscode abgerufen und eine Methode aufgerufen wird, um ein Ereignis von diesem Peer aus auszulösung. Als Optimierung bestimmt der Code, ob Listener für diesen Ereignistyp vorhanden sind. Das Auslösen des Ereignisses und das Erstellen des Peerobjekts nur dann, wenn Listener vorhanden sind, vermeiden unnötigen Aufwand und hilft dem Steuerelement, reaktionsfähig zu bleiben.

if (AutomationPeer.ListenerExists(AutomationEvents.PropertyChanged))
{
    NumericUpDownAutomationPeer peer =
        FrameworkElementAutomationPeer.FromElement(nudCtrl) as NumericUpDownAutomationPeer;
    if (peer != null)
    {
        peer.RaisePropertyChangedEvent(
            RangeValuePatternIdentifiers.ValueProperty,
            (double)oldValue,
            (double)newValue);
    }
}

Peernavigation

Nach dem Auffinden eines Automatisierungspeers kann ein Benutzeroberflächenautomatisierung Client in der Peerstruktur einer App navigieren, indem die GetChildren- und GetParent-Methoden des Peerobjekts aufgerufen werden. Die Navigation zwischen UI-Elementen innerhalb eines Steuerelements wird von der Implementierung des Peers der GetChildrenCore-Methode unterstützt. Das Benutzeroberflächenautomatisierung System ruft diese Methode auf, um eine Struktur von Unterelementen zu erstellen, die in einem Steuerelement enthalten sind, z. B. Listenelemente in einem Listenfeld. Die Standardmäßige GetChildrenCore-Methode in FrameworkElementAutomationPeer durchläuft die visuelle Struktur von Elementen, um die Struktur der Automatisierungspeers zu erstellen. Benutzerdefinierte Steuerelemente können diese Methode außer Kraft setzen, um eine andere Darstellung untergeordneter Elemente für Automatisierungsclients verfügbar zu machen und die Automatisierungspeers von Elementen zurückzugeben, die Informationen vermitteln oder Benutzerinteraktionen zulassen.

Systemeigene Automatisierungsunterstützung für Textmuster

Einige der standardmäßigen UWP-App-Automatisierungspeers bieten Unterstützung für Steuerelementmuster für das Textmuster (PatternInterface.Text). Sie bieten diese Unterstützung jedoch über systemeigene Methoden, und die beteiligten Peers notieren die ITextProvider-Schnittstelle in der (verwalteten) Vererbung nicht. Wenn jedoch ein verwalteter oder nicht verwalteter Benutzeroberflächenautomatisierung Client den Peer nach Mustern abfragt, meldet er die Unterstützung für das Textmuster und stellt das Verhalten für Teile des Musters bereit, wenn Client-APIs aufgerufen werden.

Wenn Sie von einem der Textsteuerelemente der UWP-App abgeleitet werden möchten und auch einen benutzerdefinierten Peer erstellen möchten, der von einem der textbezogenen Peers abgeleitet wird, lesen Sie die Abschnitte "Hinweise" für den Peer, um mehr über die Unterstützung auf systemeigener Ebene für Muster zu erfahren. Sie können auf das systemeigene Basisverhalten in Ihrem benutzerdefinierten Peer zugreifen, wenn Sie die Basisimplementierung von Implementierungen der verwalteten Anbieterschnittstelle aufrufen, aber es ist schwierig zu ändern, was die Basisimplementierung tut, da die systemeigenen Schnittstellen sowohl für den Peer als auch für das Besitzersteuerelement nicht verfügbar gemacht werden. Im Allgemeinen sollten Sie entweder die basisbasierten Implementierungen verwenden (nur Basis aufrufen) oder die Funktionalität vollständig durch Ihren eigenen verwalteten Code ersetzen und die Basisimplementierung nicht aufrufen. Letzteres ist ein erweitertes Szenario, Sie benötigen eine gute Vertrautheit mit dem Textdienstframework, das von Ihrem Steuerelement verwendet wird, um die Anforderungen an die Barrierefreiheit bei Verwendung dieses Frameworks zu unterstützen.

AutomationProperties.AccessibilityView

Zusätzlich zur Bereitstellung eines benutzerdefinierten Peers können Sie auch die Strukturansichtsdarstellung für jede Steuerelementinstanz anpassen, indem Sie "AutomationProperties.AccessibilityView" in XAML festlegen. Dies wird nicht als Teil einer Peerklasse implementiert, aber wir werden es hier erwähnen, da es deutsch ist, die allgemeine Barrierefreiheitsunterstützung für benutzerdefinierte Steuerelemente oder für Vorlagen, die Sie anpassen, zu unterstützen.

Das Hauptszenario für die Verwendung von AutomationProperties.AccessibilityView besteht darin, bestimmte Steuerelemente in einer Vorlage absichtlich aus den Benutzeroberflächenautomatisierung Ansichten wegzulassen, da sie nicht sinnvoll zur Barrierefreiheitsansicht des gesamten Steuerelements beitragen. Um dies zu verhindern, legen Sie AutomationProperties.AccessibilityView auf "Raw" fest.

Auslösen von Ausnahmen von Automatisierungspeers

Die APIs, die Sie für Ihre Automatisierungspeerunterstützung implementieren, dürfen Ausnahmen auslösen. Es wird erwartet, dass alle Benutzeroberflächenautomatisierung Clients, die lauschen, robust genug sind, um fortzufahren, nachdem die meisten Ausnahmen ausgelöst wurden. In aller Wahrscheinlichkeit betrachtet der Listener eine gesamte Automatisierungsstruktur, die andere Apps als Ihre eigenen enthält, und es ist ein inakzeptables Clientdesign, den gesamten Client herunterzubringen, nur weil ein Bereich der Struktur eine peerbasierte Ausnahme ausgelöst hat, wenn der Client seine APIs aufgerufen hat.

Für Parameter, die an Ihren Peer übergeben werden, ist es akzeptabel, die Eingabe zu überprüfen, und geben Sie beispielsweise ArgumentNullException aus, wenn sie null übergeben wurde und dies kein gültiger Wert für Ihre Implementierung ist. Wenn es jedoch nachfolgende Vorgänge gibt, die von Ihrem Peer ausgeführt werden, denken Sie daran, dass die Interaktionen des Peers mit dem Hostingsteuerelement etwas asynchrones Zeichen für sie haben. Alles, was ein Peer tut, blockiert nicht unbedingt den UI-Thread im Steuerelement (und es sollte wahrscheinlich nicht). So könnten Sie Situationen haben, in denen ein Objekt verfügbar war oder bestimmte Eigenschaften hatten, wenn der Peer erstellt wurde oder wenn eine Automatisierungspeermethode zuerst aufgerufen wurde, aber in der Zwischenzeit hat sich der Steuerelementstatus geändert. Für diese Fälle gibt es zwei dedizierte Ausnahmen, die ein Anbieter auslösen kann:

• Lösen Sie "ElementNotAvailableException " aus, wenn Sie nicht auf den Besitzer des Peers oder ein verwandtes Peerelement basierend auf den ursprünglichen Informationen zugreifen können, die Ihre API übergeben hat. Beispielsweise haben Sie möglicherweise einen Peer, der versucht, seine Methoden auszuführen, aber der Besitzer wurde seitdem aus der Benutzeroberfläche entfernt, z. B. ein modales Dialogfeld, das geschlossen wurde. Für einen non-.NET-Client ist dies UIA_E_ELEMENTNOTAVAILABLE zugeordnet.
• Lösen Sie "ElementNotEnabledException" aus, wenn noch ein Besitzer vorhanden ist, sich dieser Besitzer jedoch in einem Modus befindet, z. B. "IsEnabled=false", der einige der spezifischen programmgesteuerten Änderungen blockiert, die Ihr Peer auszuführen versucht. Für einen non-.NET-Client ist dies UIA_E_ELEMENTNOTENABLED zugeordnet.

Darüber hinaus sollten Peers in Bezug auf Ausnahmen, die sie von ihrer Peerunterstützung auslösen, relativ konservativer sein. Die meisten Clients können ausnahmen von Peers nicht verarbeiten und diese in Aktionen erfordernde Auswahlmöglichkeiten umwandeln, die ihre Benutzer bei der Interaktion mit dem Client treffen können. Manchmal ist also eine No-Op-Funktion und das Abfangen von Ausnahmen ohne Erneuteinschränkung innerhalb Ihrer Peerimplementierungen eine bessere Strategie als das Auslösen von Ausnahmen bei jedem Versuch, was der Peer zu tun versucht, nicht funktioniert. Beachten Sie auch, dass die meisten Benutzeroberflächenautomatisierung Clients nicht in verwaltetem Code geschrieben werden. Die meisten werden in COM geschrieben und suchen einfach nach S_OK in einem HRESULT, wenn sie eine Benutzeroberflächenautomatisierung Clientmethode aufrufen, die am Ende auf Ihren Peer zugreift.

Zugehörige Themen

• Bedienungshilfen
• Beispiel für XAML-Barrierefreiheit
• FrameworkElementAutomationPeer
• AutomationPeer
• OnCreateAutomationPeer
• Steuerelementmuster und Schnittstellen