La frustración surge cuando uno menos se lo espera, y ayer entré en este fatídico estado de  ánimo (hoy estoy totalmente calmado, ya que los problemas de las señales están resueltos en todo PaaSOS gracias a la plantilla v0.2d).

Es momento de mostrar los motivos del sufrimiento… espero que no hagáis vuestros nuestros motivos, si es así… calma… todo tiene solución.

El sistema de gestión de eventos de v7 es mucho mejor que lo que aporta v6, pero no le llega a la suela del zapato a plataformas como .NET o Java.

Entremos en detalle; en cualquier plataforma profesional (véase Java o .NET) el sistema de gestión de eventos es algo fundamental y por lo tanto tiene que ser completo, versátil y potente. Esto implica que cualquier evento que se produzca podría ser capturado, si no disponemos de tal evento solo tendremos que implementar el burbujeo necesario. Así es en muchos de los lenguajes y plataformas actuales.

¿Que sentido tiene que una plataforma como Velneo v7 no entregue toda esta potencia de serie?

Si sabéis de que hablo no sigáis leyendo, si no… continuar con un par de ejemplos.

Suponer un ejemplo como el de la captura… tenéis varios slots cargados desde proceso y todos ellos asociados a un formulario principal (véase tuiTv para ver como está implementado este mismo formulario).

image

En los slots queremos que cuando un elemento sea seleccionado el ID del mismo y su nombre aparezcan en nuestra statusbar.

Para ello lo lógico sería realizar una conexión a una señal que identifique cuando cambió el elemento seleccionado. Esta señal “Item: Cambio de seleccionado” captura el cambio de la selección. ¿Que sucede si salgo de un slot y me posiciono en otro y vuelvo a entrar nuevamente en el primer slot sobre el mismo elemento que tenia previamente seleccionado?, sencillo la señal “Item: Cambio de seleccionado” no se dispara. Esto es un problema (aún estando documentado en la documentación de v7).

Podemos intentar resolverlo con otra señal distinta. Por ejemplo “Item: Simple-click”… pero el problema sería que cuando cambiamos el elemento con el cursor no se lanza la señal.

Por último parece lógico que si combinamos ambas sería suficiente, pero no será optimo ya que genera dos ejecuciones en algunos casos.

Os hemos puesto un ejemplo, pero en tuiTv podéis apreciar otro… la ruleta de la muerte…

Cuando cambias la ruleta de la hora programada con la rueda del ratón no se lanza el filtro por hora. En este caso no tiene solución ya que esta señal no se puede capturar, por lo tanto no podemos resolver esta situación.

Otro caso es el de los checkbox y similares… ídem al caso de la ruleta de la muerte. Podemos aprovecharnos del pierde foco… pero no es adecuado en muchos casos.

En Windows existe el infierno de las dll en velneo v7 el de las señales, eventos y conexiones.

Para este pequeño infierno estamos preparando un poster/plantilla (a la que le falta una revisión) para intentar aclarar esta situación… esperemos pronto publicarla para os ayude en vuestros problemas con las señales, eventos y conexiones.

6 Comments

  1. Gracias
    Muy ilustrativo, esperemos que se solucionen todas estas incidencias.
    Vamos dejando tantas cosas pendientes que cada vez que hay una version nueva hay que volver a revisar todo de nuevo.
     

  2. Efectivamente, disponer de señales en V7 es un gran adelanto, pero aún tienen que mejorar bastante:
    – Deshabilitando las señales no disponibles en cada control
    – Teniendo claras las precedencias en el caso de señales simultáneas
    Y con todo, esto abre muchas posibilidades que, seguro, veremos crecer en el futuro.

  3. Hola
    Aunque la V7 esta cada vez mejor, este tipo de cosas son las que nunca termino de entender de parte de VELNEO, es realmente básico para cualquier aplicación el manejo de eventos y su optimización es necesario, ojala que puedan compartir en VELNEO el mismo pensamiento y solucionarlo a corto plazo.
     

  4. Hola velneadores,
    Con cada uno de nosotros existe una versión operativa de v7.
    Es por ello que cada vez pienso más en lo que realmente funciona en v7 para poder usarlo al 100%. Lo que no funciona algún día funcionará pero, no podemos perder el tiempo en ello. Usemos lo que funciona.
    Si montamos utilidades tendremos que desmontarlas cuando la funcionalidad original funcione.

Responder a Fran Varona Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *