Lecteurs d’écran et boutons système matériels
Les lecteurs d’écran, comme le Narrateur, doivent pouvoir reconnaître et gérer les événements de bouton système matériel, et communiquer leur état aux utilisateurs. Dans certains cas, le lecteur d’écran peut avoir besoin de gérer ces événements de bouton matériel exclusivement et de ne pas les laisser buller vers d’autres gestionnaires.
À compter de Windows 10 version 2004, les applications UWP peuvent écouter et gérer les événements de bouton système matériel Fn de la même façon que d’autres boutons matériels. Auparavant, ce bouton système n’a agi qu’en tant que modificateur pour la façon dont d’autres boutons matériels ont signalé leurs événements et leur état.
Remarque
La prise en charge du bouton Fn est spécifique à l’OEM et peut inclure des fonctionnalités telles que la possibilité de basculer/verrouiller ou désactiver (par rapport à une combinaison de touches d’appui et de mise en attente), ainsi qu’une lumière d’indicateur de verrouillage correspondante (qui peut ne pas être utile aux utilisateurs aveugles ou souffrant d’une déficience visuelle).
Les événements de bouton Fn sont exposés via une nouvelle classe SystemButtonEventController dans l’espace de noms Windows.UI.Input . L’objet SystemButtonEventController prend en charge les événements suivants :
- SystemFunctionButtonPressed
- SystemFunctionButtonReleased
- SystemFunctionLockChanged
- SystemFunctionLockIndicatorChanged
Important
SystemButtonEventController ne peut pas recevoir ces événements s’ils ont déjà été gérés par un gestionnaire de priorité supérieure.
Exemples
Dans les exemples suivants, nous montrons comment créer un SystemButtonEventController basé sur un DispatcherQueue et gérer les quatre événements pris en charge par cet objet.
Il est courant que plusieurs événements pris en charge se déclenchent lorsque le bouton Fn est enfoncé. Par exemple, appuyer sur le bouton Fn sur un clavier Surface déclenche SystemFunctionButtonPressed, SystemFunctionLockChanged et SystemFunctionLockIndicatorChanged en même temps.
Dans ce premier extrait de code, nous incluons simplement les espaces de noms requis et spécifions certains objets globaux, y compris les objets DispatcherQueue et DispatcherQueueController pour la gestion du thread SystemButtonEventController.
Nous spécifions ensuite les jetons d’événement retournés lors de l’inscription des délégués de gestion des événements SystemButtonEventController.
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;
Nous spécifions également un jeton d’événement pour l’événement SystemFunctionLockIndicatorChanged , ainsi qu’un bool pour indiquer si l’application est en « Mode Apprentissage » (où l’utilisateur essaie simplement d’explorer le clavier sans exécuter de fonctions).
winrt::event_token _fnLockIndicatorToken; bool _isLearningMode = false;
Ce troisième extrait de code inclut les délégués de gestionnaire d’événements correspondants pour chaque événement pris en charge par l’objet SystemButtonEventController .
Chaque gestionnaire d’événements annonce l’événement qui s’est produit. En outre, le gestionnaire FunctionLockIndicatorChanged contrôle également si l’application est en mode « Apprentissage » (
_isLearningMode
= true), ce qui empêche l’événement de se déplacer vers d’autres gestionnaires et permet à l’utilisateur d’explorer les fonctionnalités du clavier sans réellement effectuer l’action.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); }); }
Voir aussi
Windows developer