Como ya comenté en una de las entradas anteriores, Empezar por un juego…, ha sido un buen ejercicio para conocer hasta que punto voy asimilando los conocimientos adquiridos. Es interesante plantearse pequeñas aplicaciones en las que aplicarlos, sin que acabemos perdiendonos en detalles que te ofuscan mas que te permiten avanzar. Yo me propuse implementar el juego del tres en raya desde la perspectiva de Velneo, de forma que pudiera combinar algunos de los conocimientos que enumeraba en dicha entrada.

El resultado lo podeis descargar de vTresEnRaya.zip por si puede ayudar a alguien. A mi me ha servido para comprender el funcionamiento de los eventos, las actualizaciones, el uso de librerias dll y funciones/procesos. Son algunos de los detalles que permite ver. Si el lector de esta entrada no proviene del ambito de Velneo puede descargar gratuitamente el editor de Velneo de su página oficial e instalarlo. El editor lo podéis descargar del siguiente enlace:

Descarga editor de Velneo (libre)

Una vez instalado, la forma mas sencilla de visualizar la ejecución del mapa es lanzar el editor de texto y pulsar el boton correspondiente a cargar un mapa (Abrir). Eso si, debeis previamente copiar la dll en una carpeta del sistema, como Sistem32 para que funcione. Una vez abierto el mapa, basta pulsar la tecla F5 y ejecutareis la aplicación. Es realmente sencillo.

Esta es una imagen del mapa en ejecución:

Respecto al mapa, estoy seguro que se puede mejorar u optimizar, sobretodo a nivel de ejecución de los distintos procesos que intervienen. Tiempo habrá de matizar algunos detalles que pueden pasar inadvertidos. De cualquier forma, los objetivos que quería cubrir, creo que mas o menos se cumplen ya que el resultado es “aceptable”.

Se pueden sacar algunas reflexiones que parecen interesantes, siempre desde el respeto y la imparcialidad, y sobretodo desde el deseo de ser constructivos. ¿Todos los sistemas tienen su talón de Aquiles?. Quizás el de Velneo haya sido el dejar los formularios de Menu para un proposito para el que posiblemente no fueron diseñados “enteramente”. Esto es tan solo una quimera mía. Veo un formulario de edición de Fichas, que comparte la “problematica” de toda transacción abierta, con una caducidad (timeout) de cuatro minutos, y que permitirá finalmente al servidor deshacer automaticamente la transacción. Esto en mi opinión le deja un poco margen en aquellos desarrollos que el usuario quede a la espera del cliente y su capacidad de decisión. Hay ejemplos en las mismas plantillas que inducen a pensar que esto pesa sobre la conciencia del desarrollador, y el primero que se me ocurre es la misma elección del interfaz del TPV, basado en un menu de Formulario en lugar de un Menu de Edición de Ficha.

Un cliente que tardara mas de cuatro minutos en decidirse en comprar la caja azul o la caja roja hubiera provocado que un formulario normal se hubiera suicidado automaticamente. =:-O Ojo… hablamos de aplicaciones ejecutadas en el servidor de Velneo y de procesos que dejen abierta la transacción (podría ser por ejemplo el alta de un cliente). (*)

Es facil de comprobar para los que tengais instalados el servidor de Velazquez. Basta ejecutar un formulario de alta y modificar algunos campos. Luego esperar aproximadamente 4 minutos y al intentar validar el registro recibiremos un mensaje de error ya que el servidor habrá deshecho la transacción.

¿Eso es malo o bueno? Pues… ummm… parece que según se mire. Desde luego es un buen sistema para evitar que el servidor se sature con peticiones que quedan olvidadas y bloquean registros que pueden ser necesitados por otros usuarios. En un sistema clientes/servidor, como lo es Velneo, es un tema a tener en cuenta y entiendo que no se puede dejar al azar.

(*) Vale… vale… Se que se escucharán algunos siseos y comentarios: siempre hay formas de evitar el timeout de la transacción tales como provocar el alta y convertirla de forma inadvertida en una edición, pero bueno… estamos hablando de los comportamientos lógicos, pues una solución como está obligaría a eliminar el registro si el alta es cancelada, lo cual es algo un tanto extraño.

Mi madre tarda mas de diez minutos en decidir cosas menos urgentes… Así que un formulario de menu, que resulta un invento cojonudo para presentar las opciones de la aplicación, se reintroduce con unos controles que permiten (y perdón por la redundancia) un control bastante mediocre del flujo de la aplicación (1). No podemos mover los objetos dinámicamente, como nos permitiría una gran parte de los entornos. No podemos destruirlos, ni crearlos nuevamente… Nos basta jugar con la visibilidad de los mismos, establenciendo las condiciones adecuadas. Esto es posible hacerlo en un tablero pequeño, con nueve casillas y dos posibilidades por casilla. Si esto fuera el tablero de un ajedrez, aun existiendo la forma de registrar los movimientos y el modus operandi de la lógica del juego, resultaría inviable el uso de la ocultación, como medio de percepción del estado por el usuario. Así que si nuestra aplicación tiene que mover controles en el formulario no cuentes con la V6 de Velneo, o buscas nuevas formas de presentar tu aplicación, lo cual tampoco es malo, pues nos enseña que no siempre tenemos que seguir el camino esperado.

Luego existen algunos detalles que quedan bien resueltos en el formulario de edición de Fichas y que no me acaban de gustar en el formulario de Menu. Hablo concretamente del control del orden z de los objetos. En un formulario de edición de Fichas, existe adosado al mismo, una rejilla en la que se visualizan los distintos controles que aparecen y el orden en la lista se corresponde tambien con la condición de visibilidad o solapamiento. Debería haberse planteado un sistema similar en los formularios de Menú. Hubiera sido más práctico que el actual sistema de marcar el orden de forma manual mediante la pulsación del objeto, que en mi opinión no es un sistema comodo de trabajo.

Por otro lado, y razonando sobre el bloqueo de los registros en el inicio de la transacción, el uso de formularios de Menu parece mas adecuado para seguir el sistema de “coge el dinero y largate antes de que te pillen…” El sistema buscará la mejor forma de iniciar la transacción y que está dure el menor tiempo posible. Cuanto menos dure, menos conflictos existirán y por ende, menos problemática. Parece lógico: Un menu de edición de fichas va ligado a una tabla determinada, por definición. Un formulario de menú NO. Así que será la ejecución de los procesos ligados a el, los que inicien la transaccion y la finalicen, de forma que se cumple en principio esa primera parte del teorema, quedando a juicio del implementador la duración. Yo creo que se entiende, ¿no?

Podeis ver algo mas de información sobre el sistema de bloqueo de registros utilizado por Velneo en su web, a nivel de foro o en alguna entrada de su blog:
http://blog.velneo.com/web/p.pro?vdis=4&p=30700

Aun así, y a pesar de estos comentarios que a primera vista inducirían a tener una visión negativa, nada más lejos de la realidad. El peso de un formulario de Menu sobre la aplicación es bastante pequeño y siempre existen formas de minimizar algunos efectos negativos. Que no se pueda mover un control en tiempo de ejecución no debería ser un problema insalvable, de la misma forma que tampoco lo debería ser que una transacción tuviera un tiempo límite de vida. Basta entrar en el foro y descubrir como día a día se encuentran patrones que permiten plantear los problemas desde otra óptica y eso me parece muy positivo.

No existen sistemas perfectos. Todos son mejorables y cada cual tiene sus pros y sus contras. En próximas entradas intentaremos analizar y reflexionar sobre algunos aspectos muy positivos que también nos descubre.

(1) Si se comparan algunos controles existentes en un menu de edición de ficha frente a los mismos insertados en un menu de formulario, como por ejemplo una casilla de edición, veremos claramente que es algo mas restringida la funcionalidad del mismo en este segundo caso. La gente que provenimos de otros entornos, a menudo enfocamos los controles y disponemos del foco libremente mediante código. Se puede simular pero se echa en falta… Para compensar, en Velneo disponemos de la sincronización de controles que nos permite sin codigo la actualización de algunos objetos como rejillas o variables asociadas a controles del formulario. En fin… reconozco que la palabra “mediocre” es un tanto injusta, ya que el problema no es realmente que existan problemas en el cambio de foco sino que echamos de menos algunos recursos de los que disponemos en otros entornos a nivel de formulario de Menú.