Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
La gestion des événements représente l’un des aspects clés de la programmation d’applications pour Microsoft Point of Service pour .NET (POS pour .NET). Toutes les entrées du système POS pour .NET sont pilotées par les événements, et chaque segment de l’architecture POS pour .NET utilise les événements pour communiquer avec les autres applications et objets de service.
Modèle de traitement piloté par les événements
L’entrée pilotée par les événements commence dès lors qu’un appareil POS attaché reçoit une entrée de données. Si cet appareil est activé (propriété DeviceEnabled définie sur true), les données reçues sont mises en file d’attente en tant qu’événement DataEvent et envoyées à l’application. Les événements sont remis selon le modèle premier entré, premier sorti par un thread de service interne. Juste avant le déclenchement de cet événement, un objet service peut utiliser la méthode PreFireEvent pour mettre à jour les propriétés avant l’envoi de cet événement.
Une fois les données d’événement reçues, l’appareil se désactive automatiquement (en définissant la propriété DeviceEnabled sur false) si la propriété AutoDisable est définie sur true. Pendant qu’il est désactivé, l’appareil ne peut pas mettre en file d’attente les nouvelles entrées, et l’appareil physique est désactivé, si possible.
Dès l’application est prête à recevoir une entrée de l’appareil, elle définit la propriété DataEventEnabled sur true. L’application commence alors à recevoir les événements DataEvent mis en file d’attente, même si ces événements DataEvent ont été mis en file d’attente avant que la propriété DataEventEnabled ait été définie sur true.
Les événements de données supplémentaires peuvent être désactivés en définissant la propriété DataEventEnabled ou la propriété FreezeEvents sur false. Les données d’entrée postérieures sont alors mises en file d’attente pendant que l’application traite l’entrée actuelle et les propriétés associées. Dès que l’application est prête à recevoir d’autres données, elle peut réactiver les événements en définissant la propriété DataEventEnabled sur true.
Entrée pilotée par les événements et partage d’appareil
Si l’appareil d’entrée est un appareil à usage exclusif, l’application doit à la fois revendiquer et activer l’appareil avant de l’utiliser pour lire l’entrée.
Si l’appareil peut être partagé, une ou plusieurs applications doivent ouvrir et activer l’appareil avant de l’utiliser pour lire l’entrée. Une application doit appeler la méthode Claim pour demander un accès exclusif à l’appareil avant que l’objet de service lui envoie des données à l’aide de DataEvent. Si une entrée pilotée par les événements est reçue, mais que l’appareil n’est pas revendiqué, l’entrée est mise en mémoire tampon jusqu’à ce qu’une application revendique l’appareil et que la propriété DataEventEnabled soit définie sur true. Ce comportement favorise le partage ordonné de l’appareil entre plusieurs applications, où le focus d’entrant passe efficacement de l’une à l’autre.
Entrée pilotée par les événements et gestion des erreurs
L’appareil entre dans un état d’erreur si une erreur est rencontrée pendant qu’il reçoit une entrée pilotée par les événements. Il met alors en file d’attente un événement ErrorEvent (qui contient les loci InputData ou InputErrorEvent). Ces événements ne sont pas remis tant que la propriété DataEventEnabled n’est pas définie sur true pour garantir un séquencement d’application ordonné. Chaque ErrorEvent indique lequel des deux loci d’erreur possibles sont responsables :
- InputData – Utilisé si l’erreur s’est produite pendant qu’un ou plusieurs événements DataEvent étaient en file d’attente. L’ErrorEvent passe en tête de la file d’attente d’événements pour être géré immédiatement de sorte que l’application puisse répondre immédiatement en effaçant l’entrée ou en notifiant l’erreur à l’utilisateur. L’entrée mise en mémoire tampon est ensuite traitée.
- Input – Utilisé si une erreur s’est produite et qu’aucune donnée n’était disponible. Si les données d’entrée sont déjà en file d’attente au moment où l’erreur se produit, un ErrorEvent avec le locus InputData est mis en file d’attente et remis en premier, puis les autres DataEvents en file d’attente sont déclenchés et gérés. Enfin, un ErrorEvent avec la valeur Input est envoyé pour indiquer que la file d’attente est vide et qu’aucune donnée n’est disponible. Il est important de remarquer que si un ErrorEvent avec la valeur InputData a été remis et que le gestionnaire d’événements d’application a répondu par une valeur Clear, cet InputDataErrorEvent n’est pas remis. En règle générale, cette erreur est entrée à la fin de la file d’attente d’événements.
L’appareil peut quitter l’état d’erreur quand l’un des éléments suivants se produit :
- L’application retourne à partir de l’InputErrorEvent. L’application retourne à partir de l’InputDataErrorEvent avec une valeur Clear pour la propriété ErrorResponse.
- L’application appelle la méthode ClearInput.
Pour certains appareils, l’application doit appeler une méthode pour commencer l’entrée pilotée par les événements. Une fois que l’entrée est reçue par l’objet de service, aucune entrée supplémentaire n’est généralement reçue tant que la méthode n’est pas rappelée. Parmi les appareils qui utilisent cette variante d’entrée pilotée par les événements, également appelée entrée asynchrone, figurent notamment les appareils de reconnaissance de caractères à encre magnétique (MICR) et les appareils de capture de signature. La propriété DataCount peut être lue pour obtenir le nombre d’événements DataEvent présents dans la file d’attente.
Toutes les entrées situées dans la file d’attente peuvent être supprimées en appelant la méthode ClearInput. ClearInput peut être appelé après Claim pour les appareils à usage exclusif ou Open pour les appareils qui peuvent être partagés.
Le modèle d’entrée général piloté par les événements n’empêche pas la définition des classes d’appareils qui contiennent des méthodes ou des propriétés qui retournent directement des données d’entrée. Un exemple de cette variante d’entrée pilotée par les événements, également appelée entrée synchrone, est l’appareil Keylock.
Types d’événements
POS pour .NET implémente les événements UnifiedPOS (Unified Point Of Service) en tant qu’événements .NET standard avec des délégués de multidiffusion. Les événements informent une application à propos des diverses activités ou des divers changements qui concernent un appareil, par exemple quand un appareil est ajouté ou supprimé. Le tableau suivant liste les types d'événements.
| Événement | Description |
|---|---|
| DataEvent | Événement déclenché par l’objet de service pour notifier l’application que des données d’entrée sont disponibles. |
| ErrorEvent | Événement déclenché par l’objet de service pour notifier l’application qu’une erreur d’appareil s’est produite et qu’une réponse appropriée de l’application est nécessaire pour traiter la condition d’erreur. |
| StatusUpdateEvent | Événement déclenché par l’objet de service pour alerter l’application à propos du changement d’état d’un appareil. |
| OutputCompleteEvent | Événement déclenché par l’objet de service pour notifier l’application que la demande de sortie mise en file d’attente a abouti. |
| DirectIOEvent | Événement déclenché par l’objet de service pour communiquer les informations directement à l’application. |
L’objet de service doit empiler ces événements dans une file d’attente créée et gérée en interne. Les événements sont remis selon le modèle premier entré, premier sorti par un thread de service interne.
Les conditions suivantes entraînent le report de la remise des événements tant que la condition n’est pas corrigée :
- L’application a défini la propriété FreezeEvents sur true. La propriété FreezeEvents permet la mise en file d’attente des événements, mais empêche leur remise tant que FreezeEvents n’a pas la valeur false.
- L’événement est un DataEvent ou un ErrorEvent en entrée, mais la propriété DataEventEnabled a la valeur false.
Les règles de gestion de file d’attente des événements se présentent comme suit :
- L’appareil peut mettre en file d’attente les nouveaux événements uniquement quand il est activé.
- L’appareil remet les événements en file d’attente jusqu’à ce que l’application appelle la méthode Close ou, dans le cas des appareils à usage exclusif, la méthode Release. Dès lors que ces méthodes sont appelées, tous les événements restants de la file d’attente sont supprimés.
- La méthode ClearInput efface les DataEvents et les DeviceErrorEvents en entrée (ErrorLocus = Input ou InputData).
- La méthode ClearOutput efface les DeviceErrorEvents en sortie (ErrorLocus = Output).
Voir aussi
Informations de référence
Concepts
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
