10. Event ‘AltaCli’ Call( TClientes, ‘INS’, 0) Endevent Event ‘ModifCli’ Call( TClientes, ‘UPD’, CliCod ) Endevent Event ‘ElimCli’ Call( TClientes, ‘DLT’, CliCod ) Endevent Event ‘Visualizar Cliente’ Call( TClientes, ‘DSP’, CliCod ) Endevent Parm( &Mode, &CliCod); Variable del Variable de sistema usuario CliCod = &CliCod if Update or Delete; EVENTOS del WKP RULES de TClientes Refresh Refresh Refresh CliCod = udp( ‘Pnumera’, ‘CLI’) if Insert; //si queremos autonumerar los clientes
11.
12.
13.
14. Estructura de los eventos Comienzo de ejecución del work panel Fin de ejecución del work panel Evento Start Evento Exit Evento Refresh Evento Load Se muestran datos en pantalla (subfile cargado) Evento Enter Evento ‘User defined’ N veces si work panel CON tabla base 1 vez si work panel SIN tabla base
15.
16.
17.
18.
19.
Editor's Notes
Podemos clasificar los objetos GeneXus estudiados hasta el momento como: Los work panels son objetos GeneXus que permiten consultar (y no actualizar) la base de datos en forma interactiva. “ En forma interactiva” se refiere a que el usuario, en ejecución, podrá seleccionar las condiciones que afectan a los datos a mostrar.... y sobre los datos consultados, podrá realizar distintas acciones como iremos viendo a medida que vayamos avanzando en su estudio. Interactivo No Interactivo Actualización TRANSACCIONES PROCEDIMIENTOS Solo consulta WORK PANELS REPORTES
Algunas características de los work panels: Form GUI-Windows : Cada work panel tiene un form GUI-Windows (Graphical User Interface Windows) mediante el cuál el usuario puede ingresar valores que serán cargados en variables, o podrá, por ejemplo, ver datos recuperados de la base de datos. Los work panels solo tienen form windows. Para hacer consultas en ambiente Web, se utiliza el objeto Web Panel, que será tratado en el curso avanzado. Reglas : Con las reglas definimos el comportamiento particular del work panel. Por ejemplo, qué parámetros recibe el objeto, qué variables no queremos que sean aceptadas, sino utilizadas para desplegar información (noaccept), qué atributos o variables queremos que sean incluidas en un archivo temporal, pero que no aparezcan en pantalla (hidden), etc. Conditions: Son filtros que establecemos sobre los datos a desplegar. Eventos : Los work panels soportan la programación orientada a eventos. Este tipo de programación permite el almacenamiento de código ocioso el cual es activado luego de ciertas acciones, provocadas por el usuario o por el sistema. Subrutinas : Son rutinas locales al objeto. Propiedades : Características que se pueden setear para definir el comportamiento general del objeto. Ayuda : Texto para la ayuda a los usuarios en el uso del work panel. Documentación : Texto técnico que se incluye para ser utilizado como documentación del sistema. Form Classes : Cada objeto puede tener asociado más de un form, que pertenece a una determinada Form Class. Existen dos Form Classes predefinidas: Graphic y Text. Style asociado : puede asociarse un “estilo” al work panel, es decir, un objeto GeneXus que se utiliza para definir estándares.
La anterior no es una clasificación interna de GeneXus . Por otro lado, como iremos viendo a medida que avancemos en su estudio, l os Work Panels se clasifican (internamente) en: Work Panels CON Tabla Base Work Panels SIN Tabla Base
Los Work Panels tienen un form asociado, y a diferencia de las Transacciones, en los Work Panels los atributos son de salida , y las variables de entrada , ya que el uso es justamente el contrario: mientras que en las Transacciones los atributos son ingresados a la base de datos, en el caso de los Work Panels, los datos son recuperados de la misma. Paneles de Entrada Son paneles en los que se aceptan valores digitados por el usuario. Por ejemplo, un panel de entrada puede ser una pantalla previa a una impresión, donde se piden los parámetros necesarios para la misma y luego se llama a un Reporte que realiza la impresión, pasándole esos valores como parámetros. Es t e es el caso del work panel que aparece en la figura: en las variables &ini y &fin se cargan los valores ingresados por el usuario. Luego de ingresados esos valores, s e invoca al reporte que lista todos los clientes que se encuentran dentro del rango establecido. Como veremos más adelante, cuando estudiemos los eventos que ocurren al ejecutar un work panel, l a invocación al reporte la haremos en el evento Enter , que ocurre cuando el usuario presiona la tecla Enter, o cuando hace clic sobre el botón Confirm.
Paneles de Salida En estos p aneles, los datos pueden ser solamente exhibidos. Un panel de salida p uede ser una pantalla plana, como la de la figura, o puede contener un subfile , como es el caso que se muestra en la siguiente hoja. En el work panel de esta figura, se muestran datos que están almacenados en las tablas CLIENTES y PAISES. El siguiente diagrama de Bachman explicita la relación entre ambas tablas: ¿Qué datos se muestran en el form de este work panel? El código, nombre, dirección, teléfono de un cliente, y el código de país y nombre de país del mismo . ¿De qué cliente? De aquel cuyo código es recibido como parámetro. En la sección de reglas tendremos: Parm( CliCod ); Diremos que este work panel tiene tabla base , y la misma es CLIENTES. Es decir, que se recorre la tabla CLIENTES, filtrando el cliente recibido en la regla: Parm( CliCod ) y mostrando sus datos en la pantalla. El PaisNom del cliente se infiere por el concepto de Tabla extendida y se muestra también en pantalla. CLIENTES PAISES
Con el Work Panel de la figura, la idea es consultar todas las facturas de un cliente dado. Para ello se utiliza en el form del Work Panel el control Subfile. Este Work Panel, a diferencia del anterior, no es plano, pero continúa siendo un Panel de Salida, ya que lo único que hace es mostrar datos de la base de datos, sin permitir que el usuario ingrese nada. En este work panel se nombran atributos de la tabla CLIENTES y de la tabla FACTURAS. La relación entre ambas tablas es: En tanto, este work panel tiene tabla base : FACTURAS. Es decir, que se recorre la tabla FACTURAS, desplegando todas las facturas que correspondan a un determinado cliente, que se recibe en la regla : Parm( CliCod ). De esta forma se realiza un filtro en la recorrida de facturas: solo se despliegan aquellas que correspondan al cliente recibido en el atributo CliCod . Podemos pensar que tenemos un for each implícito. La tabla base del work panel es la tabla base del for each (y se accede a la tabla extendida para desplegar otra información, como en este caso, CliNom , el nombre del cliente). CLIENTES FACTURAS
Los Paneles no tienen por qué ser solo de entrada o solo de salida. El work panel que se muestra en la figura es de Entrada/Salida (mixto), y este tipo de panel es el más interactivo, ya que permite al usuario modificar las condiciones sobre los datos a desplegar. En el work panel de la figura, el usuario especifica el rango de clientes que quiere ver, ingresando valores en las variables &ini y &fin. Los clientes que serán desplegados en el subfile no serán todos los de la tabla CLIENTES (tabla base del work panel), sino solo aquellos que estén en el rango especificado. Para ello se deben declarar las conditions , que es el lugar donde se especifican las condiciones que deberán cumplir los datos para ser listados. En este caso tendremos las siguientes conditions: CliNom >= &ini; CliNom <= &fin; Por otro lado, una vez cargado el subfile con los clientes en el rango especificado por el usuario, el work panel permite realizar distintas acciones sobre estos clientes. Por ejemplo, el usuario puede querer visualizar los datos del cliente seleccionado, o eliminar varios clientes, agregar uno nuevo, modificar los datos de uno o varios clientes, etc. En el ejemplo, agregamos al subfile una variable: &op, que el usuario cargará en ejecución con el código correspondiente a la operación que desee realizar con la línea en cuestión. Por ejemplo, si desea eliminar el cliente digitará 3, en otro cliente para el que desee visualizar sus datos digitará 4, y así. Habrá que asociar al evento Enter el código correspondiente para realizar estas acciones de forma tal que cuando el
usuario presione el botón de Confirm (o presione Enter), se realicen todas las acciones especificadas. El work panel programado de esta manera se conoce como Lista de Acción. El work panel que aparece en esta figura es similar al anterior, pero en éste no incluimos variable &op. Para modificar un cliente, por ejemplo, nos posicionamos sobre la línea del subfile y presionamos el botón Modificar. Este es el caso conocido como “Lista de selección de opción única”, ya que contiene un grupo de opciones (dar de alta un nuevo cliente, modificar uno existente, eliminarlo, ver sus datos, ver sus facturas), de las cuáles el usuario puede seleccionar solamente una. También podría programarse el work panel de forma tal que el usuario pueda seleccionar de todas las opciones una, pero que se aplique a varias líneas simultáneamente.
Al igual que las transacciones que tienen eventos definidos por el usuario, los work panels también permiten al usuario definir eventos asociados a botones y/o teclas de función. En el ejemplo visto en la hoja anterior, insertamos en el form botones a los que les asociamos eventos. En esta hoja programamos algunos de esos eventos, para que se realicen las acciones deseadas cada vez que el usuario posicionado sobre una línea del subfile presiona el botón correspondiente. Observemos que en cualquiera de los eventos mostrados estamos invocando a la transacción de clientes, pasando dos valores como parámetros: un literal de 3 letras, y un parámetro más, para identificar al cliente sobre el que queremos realizar la acción. El literal de 3 letras, es recibido en la transacción en la variable del sistema &Mode, que tiene como efecto abrir la transacción en el modo recibido. Esta variable “entiende” 4 valores posibles: ‘ INS’ para modo Insert ‘ UPD’ para modo Update ‘ DLT’ para modo Delete ‘ DSP’ para modo Display Cuando una transacción se abre en modo Display, todos los atributos están en Noaccept, es decir, solo despliega los valores asociados al registro, no permitiendo al usuario modificarlos. Todas las reglas que estén condicionadas al modo Update valen para el modo Display. (No existe la función booleana Display, como existe Insert, Delete y Update, es decir, no podemos escribir: msg(‘ Estoy en modo display’ ) if Display;
L os datos que se despliegan en l os subfiles se cargan en archivos temporales. Los c a mp os que se cargan en el archivo temporal son únicamente los correspondientes a los atributos o variables que aparecen en el subfile, y los que se declaran como hidden, como veremos más adelante. El comando For Each Line permite recorrer el Subfile (no la tabla física ). Para cada una de las l í neas del subfile, se ejecuta n l as sentencias escritas dentro del For Each Line. El comando For Each Selected Line permite recorrer sólo las líneas que fueron seleccionadas del Subfile. La palabra in que aparece como opcional es para el caso en el que definimos más de un subfile en el work panel. El in se utiliza para nombrar cuál de todos los posibles subfiles que aparecen en el form es el que se quiere recorrer. En Visual FoxPro, no es posible seleccionar varias líneas en los grids a diferencia de Visual Basic (es una limitación de l lenguaje , no del generador).
La forma de programar los paneles de trabajo , está inspirada en la Programación Dirigida por Eventos (Event Driven Programming). Por Programación Dirigida por Eventos se entiende un estilo de programación en el cual las aplicaciones contienen código que permanece ocioso hasta que es llamado para responder a eventos provocados por el usuario o por el sistema.
Evento Start : Es un evento del sistema, ocurre una vez, cuando comienza l a ejecu ción d el work panel. Es te evento se usa comúnmente para asignar valores a variables ( generalmente para a signa r valores por defecto a las variables ). Evento Refresh : Es un evento del sistema, ocurre inmediatamente antes de comenzar la carga del subfile. En un ambiente multiusuario, los datos de la pantalla pueden estar desactualizados si fueron modificados desde otra terminal. En este caso, cuando el usuario desee actualizarlos, deberá presionar el botón refresh (que dispara el evento Refresh) cuyo efecto es cargar nuevamente el subfile. Comando Refresh : En algunos casos, desde otro evento también puede ser necesario cargar nuevamente el subfile. Por ejemplo cuando en un evento se llama a una transacción que actualiza los datos (Ejemplo “ Agreg ar&quot; (F 5 )) y luego se desea que se vuelva a cargar el subfile actualizado, lo que se hace es ejecutar el comando refresh luego del call a la transacción, como vimos unas páginas antes. También se necesita hacer un refresh cuando una variable que aparece en las Condi ciones es modificada por el usuario. Estas variables determinan qué datos se cargarán en el subfile , así que s i cambia n , el subfile debe ser cargado nuevamente (esto es realizado automáticamente por GeneXus ). Evento Load : Es un evento del sistema que ocurre cuando un subfile está siendo cargado . Dependiendo de si el work panel es con o sin tabla base se ejecutará n veces o una, respectivamente.
Si es con tabla base , para cada registro que se cargará en el subfile, se disparará este evento. Por lo tanto, el Evento Load se utiliza para escribir operaciones que se desean efectuar para cada una de las líneas a ser cargadas en el subfile. Si es sin tabla base , este evento se disparará una sola vez, y es allí donde hay que realizar la carga, a mano, del subfile (que estará compuesto exclusivamente por variables), como veremos en más detalle más adelante al final de este tema. Evento Enter : Este evento ocurre cuando el usuario presiona Enter o el botón Confirm. Evento Exit : Este evento ocurre después que el usuario presionó la tecla de salida (ESC o F12), o si se ejecuta el comando &quot;return&quot; incluído en algún evento. User Defined Event : Se pueden definir eventos de usuario, los que pueden estar asociados a una tecla de función y/o a un botón. De esta manera el evento ocurre cuando el operador presiona la tecla de función o el botón asociado al evento.
Order: Es equivalente a la cláusula ORDER del For Each y se aplica todo lo dicho en la sección de Reportes sobre el tema (incluida la creación de índices temporales). Por ejemplo, si quisiéramos ver los clientes en el subfile ordenados por nombre , habría que incluir la regla : Order( CliNom ); Noaccept: A diferencia de las Transacciones, en los paneles de trabajo ningún atributo es aceptado. En cambio las variables presentes en la pantalla son aceptadas, a no ser que tengan la regla NOACCEPT. Search: Cuando el subfile es demasiado extenso, muchas veces se quiere brindar la posibilidad de que el usuario pueda “posicionarse” en alguna línea determinada del mismo, en forma directa, sin tener que avanzar página por página. Por ejemplo, para buscar un cliente por su nombre dentro del subfile , se debe definir la regla: Search( CliNom >= &Nom); o también: Search( CliNom like &Nom); Hidden: Esta regla se utiliza para indicarle a GeneXus cuáles atributos o variables debe n incluir se en el subfile (archivo temporal) sin estar visibles . Se usa cuando por razones de presentación, no es conveniente mostrar un atributo o variable en el subfile, pero se quiere capturar su valor cuando se haga la carga del subfile, por ejemplo para pasarlo luego como parámetro cuando se ejecute determinado evento sobre una línea. Workfile_lines (<MaxLine>) : Dado que los subfiles se cargan en archivos temporales y que no existe un límite en la cantidad de líneas a cargar en ellos, puede haber problemas si la tabla base asociada tiene muchos registros, ya que el archivo temporal cargaría todos los registros de la tabla base. U tilizan do esta regla, se menciona en MaxLine la máxima cantidad de líneas que se permite cargar en el subfile. En tiempo de ejecución, s i el límite especificado se excede, se despliega el siguiente mensaje “ Number of lines exceeded xxxx ”, y se permite continuar trabajando, solo que el resto de las líneas no van a ser cargadas en el subfile.
Load Records : Los posibles valores son ‘Load on request’ o ‘Load all records’. Load on request: A medida que el usuario va paginando (haciendo scroll) se va n cargando los registros en el subfile (‘Carga a pedido’). Load all records: Se cargan todos los registros en el subfile . Load at Startup : Los valores posibles son ‘Yes’ o ‘No’. Yes: En tiempo de ejecución, al abrir el Work Panel, i nmediatamente se carga el subfile (se ejecuta un Refresh) . No: En tiempo de ejecución, al abrir el Work Panel, n o se carga el subfile del panel automáticamente, sino que la carga se realizará cuando el usuario haga Refresh . Automatic Refresh : Los valores posibles de esta property son : Only when variables in condition change (default): Tiene el comportamiento de siempre. When any variable changes: Genera un refresh cada vez que cualquier variable de la parte fija del Workpanel es modificada. Esta property es especialmente útil en el caso de un subfile con sólo variables, cuando uno desea que se haga automáticamente un refresh cada vez que uno de los valores de la parte fija s ea modificado. Refresh Timeout : Esta property sirve para que se haga un refresh del subfile automáticamente si el usuario no efectuó ninguna operación en el lapso de tiempo especificado. No hay valores predefinidos. Debe especificarse un valor en segundos (lapso de tiempo).
Esta propiedad permite i ndica r para cada objeto , si utilizar diálogo “ modal ” o “ no modal ” . “ Diálogo modal” significa que mientras el objeto llamado no se cierre, el objeto llamador se mantendrá inactivo. “ Diálogo no modal” en cambio, significa que ambos objetos (llamador y llamado) pueden estar activos al mismo tiempo, es decir que se puede alternar entre uno y otro, trabajando con ambos simultáneamente. L o s valores posibles de esta prop iedad son: Yes if parameters specified : Es la opción por defecto. Significa que si el objeto r e cibe parámetros, el diálogo será “ modal ”, mientras que si no r e cibe parámetros el diálogo será “ no-modal ” . Yes : Diálogo modal. No : Diálogo no modal.
Como ya mencionamos, los Work Panels se clasifican en: Work Panels CON Tabla Base Work Panels SIN Tabla Base GeneXus determina la tabla base de un Work Panel , analizando: 1 - los atribut o s utilizados en el Panel (Form) 2 - los atibutos utilizados en las reglas Hidden () y Order () 3 - los atributos utilizados en los event o s fuera de comandos For Each Basta con mencionar un atributo en alguno de los lugares anteriores para que GeneXus determine l a tabl a base del Work Panel . Los atributos utilizados en la regla Parm() y en las C ondi ciones no participan en la determin ación de la tabl a base del Work Panel . É stos actúan como filtr o s , pero GeneXus no los tiene en cuenta para determinar la tabla base . Solamente los 3 puntos mencionados arriba, participan en la determinación de la tabla base del Work Panel.
Cuando no se mencionan atributos ni en el Panel , ni en las Reglas Hidden() ni Order() , ni en los Eventos fuera de comandos For each, GeneXus no tiene elementos para determinar una tabla base a recorrer. En este caso decimos que el Work Panel es SIN TABLA BASE , lo cual significa que GeneXus no determina un For Each implícito / automático, así que la carga la debe escribir el programador. En los Work Panels SIN TABLA BASE el Evento Load se ejecuta una sola vez luego del Refresh, y es en él donde se debe programar el For Each (o los For Each) explícitamente, cargando las variables del subfile y utilizando el comando LOAD dentro del For each para efectivamente realizar la carga de cada línea.
![Work Panels ,[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)