Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La administración de eventos representa uno de los aspectos clave de las aplicaciones de programación para Microsoft Point of Service for .NET (POS for .NET). Todas las entradas del sistema POS for .NET se basan en eventos y cada segmento de la arquitectura de POS for .NET usa eventos para comunicarse con las demás aplicaciones y objetos de servicio.
Modelo de procesamiento basado en eventos
La entrada basada en eventos comienza cuando un dispositivo POS conectado recibe la entrada de datos. Si ese dispositivo está habilitado (la propiedad DeviceEnabled está establecida en true), los datos recibidos se ponen en cola como un evento DataEvent y se envían a la aplicación. Los eventos se entregan según el modelo "primero en entrar, primero en salir" mediante un subproceso de servicio interno. Justo antes de que se genere este evento, un objeto de servicio puede usar el método PreFireEvent para actualizar las propiedades antes de que se envíe ese evento.
Una vez recibidos los datos del evento, el dispositivo se deshabilita automáticamente (la propiedad DeviceEnabled se establece en false) si la propiedad AutoDisable se establece en true. Mientras está deshabilitado, el dispositivo no puede poner en cola nuevas entradas y el dispositivo físico se deshabilitará, si es posible.
Cuando la aplicación esté lista para recibir la entrada del dispositivo, establece la propiedad DataEventEnabled en true. A continuación, la aplicación comienza a recibir eventos DataEvent en cola, incluso si esos eventos DataEvent se ponen en cola antes de que la propiedad DataEventEnabled se estableciera en true.
Se pueden deshabilitar eventos de datos adicionales estableciendo la propiedad DataEventEnabled o la FreezeEvents propiedad en false. Esto hace que los datos de entrada posteriores se pongan en cola mientras la aplicación procesa la entrada actual y las propiedades asociadas. Cuando la aplicación esté lista para más datos, puede volver a habilitar eventos estableciendo la propiedad DataEventEnabled en true.
Entrada basada en eventos y uso compartido de dispositivos
Si el dispositivo de entrada es un dispositivo de uso exclusivo, la aplicación debe reclamar y habilitar el dispositivo antes de usarlo para leer la entrada.
Si el dispositivo se puede compartir, una o varias aplicaciones deben abrir y habilitar el dispositivo antes de usarlo para leer la entrada. Una aplicación debe llamar al método Claim para solicitar acceso exclusivo al dispositivo antes de que el objeto de servicio le envíe datos mediante DataEvent. Si se recibe la entrada basada en eventos, pero el dispositivo permanece sin reclamar, la entrada se almacena en búfer hasta que una aplicación reclama el dispositivo y la propiedad DataEventEnabled se establece en true. Este comportamiento promueve el uso compartido ordenado del dispositivo entre varias aplicaciones, donde el foco de la entrada entre una y otra se pasa eficazmente.
Entrada basada en eventos y control de errores
El dispositivo entra en un estado de error si se encuentra un error al recibir entradas controladas basadas en eventos. A continuación, pone en cola un evento ErrorEvent (que contiene el evento InputData o InputErrorEvent). Estos eventos no se entregan hasta que la propiedad DataEventEnabled se establece en true para garantizar la secuenciación ordenada de las aplicaciones. Cada evento ErrorEvent indica cuál de los dos posibles eventos de error es responsable:
- InputData: se usa si el error se produjo mientras se ponían en cola uno o varios eventos DataEvent. ErrorEvent salta al encabezado de la cola de eventos de control inmediato para que la aplicación pueda responder inmediatamente borrando la entrada o notificando al usuario el error. A continuación, termine de procesar la entrada almacenada en búfer.
- Input: se usa si se ha producido un error y no hay datos disponibles. Si los datos de entrada ya se ha puesto en cola cuando se produce el error, se pone en cola un evento ErrorEvent con el evento InputData y se entregan primero; posteriormente, se generan y controlan el resto de eventos DataEvents de la cola. Por último, se envía un evento ErrorEvent con el valor Input para indicar que la cola está vacía y no hay datos disponibles. Es importante observar que si se entregó un evento ErrorEvent con el valor InputData y el controlador de eventos de aplicaciones respondió con un valor Clear, este evento InputDataErrorEvent no se entrega. Normalmente, este error se inserta al final de la cola de eventos.
El dispositivo puede salir del estado de error cuando se da una de las siguientes situaciones:
- La aplicación devuelve resultados del evento InputErrorEvent. La aplicación devuelve resultados del evento InputDataErrorEvent con un valor Clear para la propiedad ErrorResponse.
- La aplicación llama al método ClearInput.
En algunos dispositivos, la aplicación debe llamar a un método para comenzar la entrada basada en eventos. Cuando el objeto de servicio recibe la entrada, lo normal es que no se reciba ninguna entrada adicional hasta que se vuelve a llamar al método. Entre los ejemplos de dispositivos que usan esta variación de la entrada basada en eventos, también conocida como entrada asincrónica, se incluyen el reconocimiento de caracteres de tinta magnética (MICR) y los dispositivos de captura de firmas. La propiedad DataCount se puede leer para obtener el número de eventos DataEvent en la cola.
Todas las entradas de la cola se pueden eliminar llamando al método ClearInput. Se puede llamar a ClearInput después de Claim en los dispositivos de uso exclusivo o de Open en los dispositivos que se pueden compartir.
El modelo de entrada general basado en eventos no impide la definición de clases de dispositivo que contienen métodos o propiedades que devuelven datos de entrada directamente. Un ejemplo de esta variación de la entrada basada en eventos, también conocida como entrada sincrónica, es el dispositivo Keylock.
Tipos de eventos
POS for .NET implementa eventos Unified Point Of Service (UnifiedPOS) como eventos de .NET estándar con delegados de multidifusión. Los eventos informan a una aplicación de diversas actividades o cambios con un dispositivo, como cuando se agrega o se quita un dispositivo. En la tabla siguiente se enumeran los tipos de eventos.
| Evento | Descripción |
|---|---|
| DataEvent | Evento generado por el objeto de servicio para notificar a la aplicación que hay datos de entrada disponibles. |
| ErrorEvent | Evento generado por el objeto de servicio para notificar a la aplicación que se ha producido un error de dispositivo y que es necesaria una respuesta adecuada por parte de la aplicación para procesar la condición de error. |
| StatusUpdateEvent | Evento generado por el objeto de servicio para alertar a la aplicación de un cambio en el estado de un dispositivo. |
| OutputCompleteEvent | Evento generado por el objeto de servicio para notificar a la aplicación que la solicitud de salida en cola se ha completado correctamente. |
| DirectIOEvent | Evento generado por el objeto de servicio para comunicar información directamente a la aplicación. |
El objeto de servicio debe apilar estos eventos en una cola administrada y creada internamente. Los eventos se entregan según el modelo "primero en entrar, primero en salir" mediante un subproceso de servicio interno.
Las condiciones siguientes hacen que la entrega de eventos se retrase hasta que se corrija la condición:
- La aplicación ha establecido la propiedad FreezeEvents en true. La propiedad FreezeEvents permite poner en cola los eventos, pero impide su entrega hasta que FreezeEvents esté establecido en false.
- El evento es un evento DataEvent o un evento ErrorEvent de entrada, pero la propiedad DataEventEnabled es false.
Las reglas para la administración de colas de eventos son las siguientes:
- El dispositivo solo puede poner en cola nuevos eventos mientras el dispositivo está habilitado.
- El dispositivo entrega eventos en cola hasta que la aplicación llama al método Close o, para dispositivos de uso exclusivo, el método Release. Cuando se llama a estos métodos, se eliminan los eventos restantes de la cola.
- El método ClearInput borra DataEvents y los eventos DeviceErrorEvents de entrada (ErrorLocus = Input o InputData).
- El método ClearOutput borra la salida DeviceErrorEvents (ErrorLocus = Output).
Consulte también
Referencia
Conceptos
Colaborar con nosotros en GitHub
El origen de este contenido se puede encontrar en GitHub, donde también puede crear y revisar problemas y solicitudes de incorporación de cambios. Para más información, consulte nuestra guía para colaboradores.
