Entrée et événements d’appareil (documentation du SDK POS pour .NET v1.14)

Tous les appareils POS ont la possibilité de générer des événements ou de changer d’état indépendamment de l’application. Par exemple, si un opérateur débranche un appareil PinPad, l’application n’a aucun moyen direct de détecter cette modification, car il ne s’agit pas d’un changement d’état demandé par l’application. Un objet de service doit avoir un moyen d’alerter l’application de ces changements d’état.

Multithreading

Étant donné que demander à l’application d’interroger en permanence l’objet de service sur son état actuel serait beaucoup trop coûteux, une autre solution est nécessaire. En règle générale, la solution consiste à créer un thread en arrière-plan pour surveiller l’appareil.

Comme d’autres exemples l’ont démontré, la création d’un thread de lecteur est toujours nécessaire pour les périphériques d’entrée, comme les scanneurs ou les lecteurs de bandes magnétiques. Toutefois, pour les périphériques de sortie, comme les écrans de ligne et les imprimantes, un deuxième thread est souvent nécessaire pour surveiller les changements d’état, comme la perte d’alimentation ou la mise hors connexion, puis pour envoyer un événement StatusUpdateEvent à l’application.

De cette façon, l’objet de service peut répondre aux demandes de l’application tout en surveillant de manière asynchrone le matériel.

Définition d’événements

Les événements sont le mécanisme par lequel l’objet de service notifie l’application d’un changement d’état dans l’appareil ou l’arrivée de nouvelles données.

En termes généraux, un événement est une notification entre un thread ou un processus et un autre qu’un événement s’est produit. Plus précisément, Microsoft Point of Service pour .NET (POS pour .NET) utilise la fonctionnalité de délégués .NET pour répondre aux demandes de l’application.

La spécification Unified Point Of Service (UnifiedPOS) définit un ensemble de cinq événements : DataEvent, DirectIOEvent, ErrorEvent, OutputCompleteEvent et StatusUpdateEvent. Chaque objet de service peut être autorisé à prendre en charge uniquement un sous-ensemble de ceux-ci. Le contenu exact des données dépend également du type d’objet de service.

Files d’attente d’événements

Lorsque vous créez une classe d’objet de service dérivée de l’une des classes Base de POS pour .NET, les événements ne sont pas envoyés directement de l’objet de service à l’application. Au lieu de cela, les événements sont placés dans une file d’attente gérée par la classe Base. Étant donné que certaines conditions doivent être remplies avant que des événements puissent être remis à une application, le code de la classe Base distribue les événements uniquement lorsqu’il est approprié de le faire. L’objet de service n’a pas besoin de connaître la file d’attente ou les exigences qui doivent être remplies avant qu’un événement puisse être déclenché. Cela allège considérablement la charge qui pèse sur le développeur d’objets de service.

La file d’attente d’événements fonctionne de manière asynchrone à l’aide de son propre thread. Cela signifie que l’objet de service n’attend pas la remise effective de l’événement.

Ajout d’événements à la file d’attente

Les classes Base de POS pour .NET fournissent plusieurs façons d’ajouter un événement à la file d’attente en fonction de l’objet de service et du type d’événement.

De nombreuses classes Base ont des méthodes d’assistance pour simplifier la mise en file d’attente de certains événements ; le plus souvent, les événements DataEvent. Par exemple, la méthode MsrBase.GoodRead peut être utilisée pour mettre en file d’attente un événement DataEvent après une lecture de carte réussie. De même, PosKeyboard.KeyDown met en file d’attente un DataEvent indiquant qu’une touche a été enfoncée.

Les événements peuvent également être mis en file d’attente automatiquement par la classe Base lorsqu’un certain état est modifié. Par exemple, si un objet de service a défini sa propriété Properties.CapPowerReporting, un StatusUpdateEvent indiquant un changement d’alimentation peut être envoyé simplement en définissant la propriété Properties.PowerState dans l’objet de service.

Enfin, si nécessaire, un objet de service peut spécifiquement mettre en file d’attente un événement à l’aide de l’un des remplacements de QueueEvent. Cela est utilisé le plus souvent pour envoyer un DirectIOEvent. Étant donné que les événements DirectIOEvent sont spécifiques au fournisseur et à l’appareil, aucun mécanisme générique ne peut être utilisé pour les mettre en file d’attente.

Entrée synchrone

Bien que la plupart des entrées d’appareil soient lues de manière asynchrone par l’objet de service, puis distribuées à l’application sous forme d’événements, il existe des cas où l’application peut demander des données à partir de l’objet de service et ne pas retourner tant que les données ne sont pas prêtes ou qu’un délai d’attente n’a pas été atteint. Pour plus d’informations sur les entrées pilotées par les événements, consultez Gestion des événements.

Voir aussi

Tâches

• Exemple de gestionnaire d’événements

Concepts

• Gestion des événements

Autres ressources

• Développement d’objets de service à l’aide de classes de base