Funcionalidades

El FormCode es una sección que se hizo especialmente para compatibilizar una lógica cuando se tiene habilitado el Export a Excel que vimos al describir las propiedades del nodo Modes. Lo que ocurre es que podemos querer que los títulos de la Grilla que se declaran en la propiedad Description del nodo atribute que vimos en, sean dinámicos, o sea, que estos títulos se determinen a partir del estado de una cierta condición. Por ejemplo, podemos tener un dato del filtro que determine si se desea desplegar importes en moneda nacional o en moneda extranjera y entonces vamos a querer que el título de la columna sea “Moneda Nacional” o “Moneda Extranjera” según el caso.

Para esto, normalmente lo que tiene que hacerse es poner en el Event Refresh o en el Event Start del nodo Selection algo así como: Si el filtro tiene tal valor, la Variable.Title igual “Tal cosa”. Así es como se programaría. El tema es que cuando tenemos el Modo Export a Excel, esta acción al ejecutarse simula toda la lógica que tenemos en el Web Panel en un procedimiento que es el que realmente va a hacer el Export a Excel. Allí va a estar metida toda la lógica de Filtros, toda la lógica de Conditions, etc.

Esto es así porque en el Web Panel lo que muestra la Grilla es sólo una página del reporte. Uno podría preguntarse: ¿Por qué no se hace un For Each Line? Y es porque hay que acordarse de que el For Each Line, en Web, sólo recorre la página de la Grilla que en ese momento está mostrándose. No recorre todos los registros que un Work Panel obtendría.

La lógica de Export a Excel lo que hace es simular todo el For Each que haría con Tabla Base o sin Tabla Base en el propio procedimiento de Export a Excel y obviamente carga datos del Event Start porque tiene que inicializar variables, carga datos del Event Refresh para actualizar otras variables y si tenemos una propiedad que me dice Variable.Title en el procedimiento, seguramente me va a reventar el Export a Excel. Esta propiedad Variable.Title sólo está habilitada cuando tengo una Grilla y en un procedimiento no tenemos la Grilla.

Entonces, todas las acciones que tengamos que hacer específicamente orientadas a datos del formulario que sólo se activan en el Web Panel tendrían que definirse en este FormCode. Son todos los elementos que podamos poner y dependan específicamente de los controles que tenemos en la pantalla del Web Panel.

Este código que se agrega en el FormCode, cuando se hace el Export a Excel, no se transfiere. Es el único código que no se transfiere al procedimiento de Export a Excel.

Nodo Variables

Le da soporte a las variables del Web Panel. Algunas otras variables van a ser declaradas en la propia Grilla, dentro del nodo Attributes o en el nodo Filter y hay que tener en cuenta dos cosas:

· Cuando se declara una variable en cualquier lado, no es necesario duplicar la declaración en el nodo Variables. Por ejemplo, cuando se declara en la Grilla, todas sus propiedades quedan definidas allí.

· En el nodo Variables deberían estar declaradas sólo aquellas variables que se usan en un Evento temporalmente, por ejemplo una variable auxiliar, que se usa para cargar algo, etc.

Si en algún caso (que pasa muy a menudo), una variable que ya está definida en el nodo Filter o en la Grilla (en el nodo Attributes) la vuelven a declarar en el nodo Variables, cuando generan los objetos con el Pattern, GeneXus les advierte con un warnig que esa variable está definida dos veces.

En realidad, si una variable esta definida dos veces, simplemente se va a sobrescribir una declaración sobre la otra. Lo que sí puede pasar es que si se trata de una variable que está en el Filtro y no es una variable auxiliar, al duplicarla podría estar generando algún problema con los controles de edición. Porque los punteros son distintos y cuando se vuelve a alojar la variable en pantalla se sobrescribe su número de variable y provoca una inconsistencia. Por eso se da el warning y cuando les aparezca traten de solucionarlo. Especialmente para los procesos de migración Win a Web, implementamos dos funcionalidades al nodo Variables que son importantes.

Si hacen botón derecho sobre el nodo les van a aparecer, entre otras, las opciones “Import Variables” y “Sort Variables”. Si seleccionamos Import Variables abre una ventana pop up donde se puede seleccionar de dónde queremos importar las variables para no tener que crear nuevamente una a una.

Actions

Tipos y ubicación

Inclusive puede pasar que varíen las opciones de la Combo, dependiendo de la línea que se esté seleccionando, porque cada Acción en la parte superior de su barra de Propiedades tiene lo que se llama la Condition y podríamos condicionar la muestra de esa Acción, sea Imagen o sea Texto con el valor que tenga esta propiedad.

Evaluate Condition

También tenemos la propiedad Evaluate Condition que nos permite declarar que la condición debe evaluarse en determinada situación. Por ejemplo, queremos que se evalúe cuando se apriete el botón (no antes), o al revés, queremos que se evalúe al hacer la carga de la imagen o del Texto.

Por defecto el sistema prevé que la condición se evalúe en el primer evento posible, es decir, la va a tratar de evaluar lo antes posible y eso significa que si la condición es de tipo sencillo, la va a tratar de evaluar en el Event Load.

Puede pasar que no queramos que sea allí que se produzca la evaluación, entonces podemos indicar que se evalúe en el momento de apretar el botón (Event). E incluso puede pasar que sea necesario evaluar la condición en ambos eventos (Both).

El Error Message y el Message Type que figuran debajo son comportamientos que pueden variar dependiendo del Tipo de la Acción. Por ejemplo, si la Acción es de tipo Imagen, es InGrid, estando la evaluación en el Event Load y resultando “False”, lo que ocurre es que la imagen no aparece (se pone una imagen transparente para que la misma no se vea), se deshabilitan todos los JavaScript posibles sobre esa Acción y se sustituye el Error Message tradicional por un ToolTip Text que muestra (cuando me posicione encima de donde debería estar la imagen de dicha Acción), el error que hayamos declarado aquí y por el cual no se habilita la Acción.

Ahora, si la condición de la Acción estaba a nivel de Evento, es decir que disparamos la Acción y el error se detecta a este nivel, entonces sí, va a aparecer un Error Message de los típicos de GeneXus en Web, abajo, en la pantalla, mostrando el texto del error que hayamos declarado en esta propiedad.

Si la Acción es de tipo Imagen o Botón (Texto) pero no InGrid, estando la evaluación en el Event Load y resultando “False”, también lo que hace directamente el sistema es desaparecer la Imagen o el Botón, de modo que simplemente no existe la posibilidad de apretarlo. Esto a diferencia de lo que ocurre InGrid que la columna va a tener que seguir estando, porque algún otro registro de la Grilla debe tener posibilidad de habilitar la Acción.

En cuanto al Message Type, por defecto viene en “Constant”, lo que significa que lo ingresado en Error Message es el texto del error. Si pasamos el Message Type a “Variable” entonces en Error Message debemos ingresar el nombre de la variable (&message) que va a contener el texto del error.

Esta variable se instancia en la sección “Selection Events” de la barra de Propiedades. En la propiedad PreviousCode. Allí, al seleccionarla se abre una ventana pop up con una cajita donde podemos escribir un código de tipo Evento para determinar el texto del mensaje de error según las condiciones de error.

Este PreviousCode muchas veces sirve no sólo para instanciar la variable con el mensaje de error, sino para instanciar la propia condición que se declaró en la propiedad Condition de la sección Condition, donde sólo se puede escribir la condición (que sería lo que puede ir dentro de un “If”) y muchas veces se requiere instanciar las variables a las que se refiere esta condición.

Por ejemplo, si la condición depende de lo devuelto por un

udp, lo correcto es cargar una variable con el udp de la función en este PreviousCode y en la Condition preguntar por el contenido de la variable directamente.

Confirm