Comment on page
Manejador de evento
Este subobjeto es un contenedor de instrucciones de proceso que puede ser ejecutado desde una conexión de evento cuando la señal sea disparada.
Para crear una conexión de evento hemos de pulsar el botón 
en el panel de subobjetos de Velneo vDevelop.
El sistema nos pedirá, en primer lugar, el lenguaje en el cual programaremos el proceso: Velneo o Javascript.
Los manejadores de evento serán creados directamente en el editor de procesos que se abre al crear/editar un sub-objeto de este tipo.
Los manejadores de evento Javascript requieren de la creación de un fichero de script, que será asignado al manejador de evento en la propiedad fichero script. Consultar los siguientes capítulos para ampliar información al respecto: inspector de scripts.
Las propiedades de un manejador de evento son:
Etiqueta alfanumérica que identifica al subobjeto. Este identificador será el que se usa para referenciarlo en los inspectores y en las propiedades de otros objetos.
Etiqueta alfanumérica que servirá como descriptor del manejador de evento. Es el texto que se presentará al usuario final de la aplicación para referenciar el manejador de evento.
Podemos definir una etiqueta por cada idioma presente en el proyecto.
Podemos definir el estilo privado que limita el acceso del usuario final al objeto desde puntos donde no se haya programado el acceso al mismo.
Esta propiedad nos permite documentar el uso del manejador de evento.
Además de los comandos estándar para procesos, en los manejadores de eventos que dispara el manejador de evento.
En el caso de objetos de ficha (formulario, por ejemplo) el origen del manejador de evento será la ficha editada en el formulario.
En el caso de objetos de lista (rejilla, por ejemplo) el origen del manejador de evento será la lista mostrada en la misma.
Los manejadores de eventos no refrescan el interfaz hasta su finalización.
El motivo de ello es que si refrescaran el interfaz antes de su finalización se podrían disparar más señales, debido a un cambio en un campo, variable, etc…., lo que podría producir problemas de sincronización y de refresco.
Desde proyectos heredados podremos acceder a docks que se ejecuta si hay coincidencia de identificadores. Por ejemplo, ejecutamos un proyecto B que hereda un proyecto A y en dicho proyecto A tenemos programados procesos que interactúan con un dock de A. Si en el proyecto B creamos un dock con el mismo identificador que el de A, al ejecutar B y hacer uso de esos procesos de A, actuarán sobre el dock de B.
1) Debemos ser conscientes de que, cuando se ejecuta un manejador de evento, no se dispararán otras señales y sus manejadores de evento, ya que podría dar lugar a recursividad o ejecuciones en cascada no deseadas.
Lo veremos más claro con un ejemplo:
Hemos programado un manejador de evento que se dispara con la señal “gana foco” asociada a un control de un formulario, y programamos otro manejador de evento que lleva el foco a dicho control con el comando interfaz: establecer foco.
Según lo dicho antes, al ejecutar el manejador de evento que establece foco en el control, no se disparará la señal de ganancia de foco, por lo tanto, si queremos que se ejecute el manejador de evento asociado a la misma, lo único que tendremos que hacer es, en el manejador de evento que establece el foco, disparar el otro manejador de evento con el comando Interfaz: ejecutar evento.
2) Si tenemos programadas varias conexiones de evento asociadas a un mismo control y con la misma señal, solamente se disparará la primera de ellas.
Por ejemplo, si hemos programado varias conexiones de evento del tipo “gana foco” sobre el mismo control, sólo se lanza la primera de ellas y no el resto.
Lo que se podría hacer es declarar una única señal del tipo “gana foco” que dispare un manejador de evento que lance todos los manejadores que se quieran ejecutar al ganar foco el control.
Durante la ejecución del manejador de evento se controlan los mensajes del sistema, señales, etc., para evitar que se produzcan y no afecten, ya que se podrían producir conflictos de señales que se disparan en medio del procesamiento de otra señal, ocasionando problemas de señales reentrantes en bucle que fuerzan a su vez la ejecución de manejadores asociados, etc.
Este control no se produce cuando llamamos a un proceso en primer plano, por lo que, si durante la ejecución del proceso se producen otras señales y mensajes que provocan la ejecución de otros manejadores de evento, reentradas u otros, a medias de las ejecución de otro manejador que todavía no ha finalizado, dependiendo del sistema esto puede llevar a dar errores, provocados por la imposibilidad de gestionar las señales y mensajes durante la ejecución del proceso.
Para evitar esto, debemos, o bien incluir en el manejador de evento el código del proceso, o bien, crear otro manejador de evento en lugar de proceso y ejecutarlo desde otro manejador.
En el caso de reutilización, podemos ejecutar, siempre que sea posible, los procesos en tercer plano, o hacer uso de manejadores javascript que nos permitan hacer uso de funciones compartidas mediante la inclusión de código.
De esta forma, todo lo que genere interfaz se realizará dentro de un manejador de evento y se evitarán problemas señales o manejadores de evento que se puedan disparar, ya que incluso desde javascript podemos gestionar cuándo se refresca el interfaz.
En las vistas de datos no hay multi-tarea. Esto quiere decir que si desde un manejador de evento disparamos un proceso en 2º plano, éste será ejecutado en primer plano.
Los manejadores de evento se agrupan en una única transacción, es decir, los manejadores de evento no generan transacciones independientes, es decir, si desde un manejador de evento que no transacciona se ejecutan dos manejadores de evento que sí lo hacen, todo quedará englobado en una misma transacción.
Última actualización 3yr ago