Sprachausgaben und Hardwaresystemtasten
Technologien für das Vorlesen von Bildschirminhalten wie z. B. die Sprachausgabe von Microsoft, müssen in der Lage sein, Ereignisse von Hardwaresystemtasten zu erkennen und zu verarbeiten und Benutzer*innen den jeweiligen Tastenzustand mitzuteilen. In einigen Fällen muss die Sprachausgabe diese Hardwaretastenereignisse möglicherweise ausschließlich behandeln und nicht zulassen, dass sie bis zu anderen Handlern blasen.
Ab Windows 10, Version 2004, können UWP-Anwendungen die Fn-Hardwaretastenereignisse auf die gleiche Weise überwachen und verarbeiten wie andere Hardwaretasten. Bisher fungierte diese Systemschaltfläche nur als Modifizierer für die Meldung der Ereignisse und des Zustands anderer Hardwareschaltflächen.
Hinweis
Die Fn-Tastenunterstützung ist OEM-spezifisch und kann Features wie die Möglichkeit zum Ein- oder Ausschalten (im Vergleich zu einer Tastenkombination mit gedrückter Taste) zusammen mit einer entsprechenden Sperranzeige (die für Benutzer, die blind sind oder eine Sehbehinderung haben, möglicherweise nicht hilfreich sein) enthalten.
Fn-Schaltflächenereignisse werden über eine neue SystemButtonEventController-Klasse im Windows.UI.Input-Namespace verfügbar gemacht. Das SystemButtonEventController-Objekt unterstützt die folgenden Ereignisse:
- SystemFunctionButtonPressed
- SystemFunctionButtonReleased
- SystemFunctionLockChanged
- SystemFunctionLockIndicatorChanged
Wichtig
SystemButtonEventController kann diese Ereignisse nicht empfangen, wenn sie bereits von einem Handler mit höherer Priorität behandelt wurden.
Beispiele
In den folgenden Beispielen wird gezeigt, wie Sie einen SystemButtonEventController basierend auf einem DispatcherQueue erstellen und die vier von diesem Objekt unterstützten Ereignisse behandeln.
Es ist üblich, dass mehrere der unterstützten Ereignisse ausgelöst werden, wenn die Fn-Taste gedrückt wird. Wenn Sie z. B. die Fn-Taste auf einer Surface-Tastatur drücken, wird SystemFunctionButtonPressed, SystemFunctionLockChanged und SystemFunctionLockIndicatorChanged gleichzeitig ausgelöst.
In diesem ersten Codeausschnitt schließen wir einfach die erforderlichen Namespaces ein und geben einige globale Objekte an, einschließlich der DispatcherQueue und der DispatcherQueueController-Objekte zum Verwalten des SystemButtonEventController-Threads .
Anschließend geben wir die Ereignistoken an, die beim Registrieren der Ereignisbehandlungsdelegats vom SystemButtonEventController zurückgegeben werden.
namespace winrt { using namespace Windows::System; using namespace Windows::UI::Input; } ... // Declare related members winrt::DispatcherQueueController _queueController; winrt::DispatcherQueue _queue; winrt::SystemButtonEventController _controller; winrt::event_token _fnKeyDownToken; winrt::event_token _fnKeyUpToken; winrt::event_token _fnLockToken;
Außerdem geben wir ein Ereignistoken für das SystemFunctionLockIndicatorChanged-Ereignis zusammen mit einem Bool an, um anzugeben, ob sich die Anwendung im "Lernmodus" befindet (wobei der Benutzer einfach versucht, die Tastatur zu erkunden, ohne Funktionen auszuführen).
winrt::event_token _fnLockIndicatorToken; bool _isLearningMode = false;
Dieser dritte Codeausschnitt enthält die entsprechenden Ereignishandlerdelegat für jedes Ereignis, das vom SystemButtonEventController -Objekt unterstützt wird.
Jeder Ereignishandler gibt das aufgetretene Ereignis an. Darüber hinaus steuert der FunctionLockIndicatorChanged-Handler auch, ob sich die App im "Learning"-Modus (
_isLearningMode
= true) befindet, wodurch verhindert wird, dass das Ereignis auf andere Handler bubblingt und der Benutzer Tastaturfeatures erkunden kann, ohne die Aktion tatsächlich auszuführen.void SetupSystemButtonEventController() { // Create dispatcher queue controller and dispatcher queue _queueController = winrt::DispatcherQueueController::CreateOnDedicatedThread(); _queue = _queueController.DispatcherQueue(); // Create controller based on new created dispatcher queue _controller = winrt::SystemButtonEventController::CreateForDispatcherQueue(_queue); // Add Event Handler for each different event _fnKeyDownToken = _controller->FunctionButtonPressed( [](const winrt::SystemButtonEventController& /*sender*/, const winrt:: FunctionButtonEventArgs& args) { // Mock function to read the sentence "Fn button is pressed" PronounceFunctionButtonPressedMock(); // Set Handled as true means this event is consumed by this controller // no more targets will receive this event args.Handled(true); }); _fnKeyUpToken = _controller->FunctionButtonReleased( [](const winrt::SystemButtonEventController& /*sender*/, const winrt:: FunctionButtonEventArgs& args) { // Mock function to read the sentence "Fn button is up" PronounceFunctionButtonReleasedMock(); // Set Handled as true means this event is consumed by this controller // no more targets will receive this event args.Handled(true); }); _fnLockToken = _controller->FunctionLockChanged( [](const winrt::SystemButtonEventController& /*sender*/, const winrt:: FunctionLockChangedEventArgs& args) { // Mock function to read the sentence "Fn shift is locked/unlocked" PronounceFunctionLockMock(args.IsLocked()); // Set Handled as true means this event is consumed by this controller // no more targets will receive this event args.Handled(true); }); _fnLockIndicatorToken = _controller->FunctionLockIndicatorChanged( [](const winrt::SystemButtonEventController& /*sender*/, const winrt:: FunctionLockIndicatorChangedEventArgs& args) { // Mock function to read the sentence "Fn lock indicator is on/off" PronounceFunctionLockIndicatorMock(args.IsIndicatorOn()); // In learning mode, the user is exploring the keyboard. They expect the program // to announce what the key they just pressed WOULD HAVE DONE, without actually // doing it. Therefore, handle the event when in learning mode so the key is ignored // by the system. args.Handled(_isLearningMode); }); }
Weitere Informationen
Windows developer