1

Herramientas y metodologas

HERRAMIENTAS Y METODOLOGAS:

Nuestra tarea como profesionales de la informtica es desarrollar y mantener aplicaciones para apoyar al usuario en su actividad final. Para realizar esta tarea se han instrumentado diferentes herramientas y metodologas. Con GeneXus se desarrollan aplicaciones aplicando una metodologa que tiene un enfoque muy diferente al de las metodologas mas comnmente utilizadas. Aprender a utilizado adecuadamente va ms all de conocer el lenguaje de especificacin ms importante es el aprendizaje de una nueva metodologa de desarrollo. y lo

El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la obtencin del conocimiento de la realidad. Cmo obtener el conocimiento de la realidad en una forma lo suficientemente objetiva y detallada al mismo tiempo, que nos permita construir un modelo corporativo.

Todos compartirn la afirmacin de que cada usuario conoce muy bien los objetos con los que trabaja cotidianamente, conoce claramente la informacin que se maneja en ellos, que reglas deben seguirse y que clculos deben realizarse. Por lo tanto, utilizar estas visiones de los objetos de su realidad como fuente de informacin parece muy razonable. Se ha demostrado con mucha rigurosidad que es posible obtener un modelo de datos a partir de la sntesis de visiones, por lo que nuestro problema se ha reducido a un problema matemtico ya que si conseguimos describir adecuadamente estas visiones podremos obtener mediante Ingeniera Inversa el modelo de datos. Este mtodo que se conoce como sntesis de visiones cannicas. Este es el punto de partida de la metodologa de GeneXus: Describir las visiones de los usuarios para modelar el sistema, y se construir a partir de este modelo el soporte computacional (base de datos y programas) para soportarlo. COMPARACIN DE METODOLOGAS Es bueno, para fijar ideas, comparar la metodologa utilizada por GeneXus conocida como Metodologa Incremental con las metodologas tradicionales ms utilizadas actualmente. Algunos de los ejemplos de estas metodologas son: Anlisis Estructurado, Ingeniera de la Informacin, Anlisis Escencial. Estas metodologas son diferentes entre s, pero en todos los casos, separan el anlisis de los datos del de los procesos. Veremos un esquema general que podra aplicarse a cualquiera de stas metodologas y estudiaremos sus problemas. Metodologa Tradicional: La primera tarea, generalmente, es el anlisis de datos.

Se pretende analizar la empresa y dar como producto un modelo de datos con las Entidades y Relaciones encontradas (Modelo ER). Aqu se analiza la empresa desde el punto de vista de los objetos que existen en ella y sus relaciones. Construir un sistema integrado, que requiere un modelo de datos Corporativo de la empresa no es una tarea simple debido a que el nmero de objetos y relaciones hacen que esta tarea sea extremadamente compleja. Debido a la complejidad de la construccin de un sistema integrado, lo que se hace normalmente es dividirlo en mdulos, y cada uno solucionar los problemas operativos de un rea en particular de la empresa. Simplificaremos notablemente la tarea de modelado ya que lo que precisamos normalmente son 10 o a lo sumo 20 archivos para cada modelo. Los mdulos operan sin una real integracin, lo que hace que exista informacin redundante y como consecuencia todo intento de buscar informacin fuera del entorno de cada aplicacin resulte imposible o por lo menos peligroso. En caso de que deseramos posteriormente realizar la integracin de esos mdulos es necesario realizar modificaciones al modelo de datos (lo que a pesar de la complejidad podramos calificar como posible), pero las modificaciones que deberemos realizar en los programas tienen un costo tan grande que hacen inviable la realizacin de la integracin. La empresa tendr de esta forma, resueltos sus problemas operativos, pero luego aparecern con mucha claridad los problemas de la carencia de informacin que permitan orientar la gestin y la toma de decisiones de alto nivel, ya que la informacin que se necesita es en general de naturaleza corporativa. En la medida que nos orientamos cada vez ms a las bases de datos corporativas, la cantidad de objetos que integran la base de datos y sus relaciones se hacen ms complejas. Esto lleva a que el diseo de una base de datos corporativa sea una tarea muy complicada y en la que son muchos los errores que se pueden cometer. GeneXus apunta a la creacin de sistemas corporativos, brindando herramientas y una metodologa que hagan posible la realizacin de esta tarea.

4
Continuando con el proceso de desarrollo en una metodologa tradicional, luego de obtener el modelo de datos se pasa a disear la base de datos. Podemos ver que entre un buen modelo de datos, y el diseo de la base de datos necesaria para soportarte, existe una transformacin trivial. Por ello, para mayor claridad del dibujo, eliminaremos la etapa intermedia y colocaremos directamente la base de datos. Pero el modelo de datos no es suficiente para desarrollar los programas de aplicacin, porque describe los datos, pero no los comportamientos. Se recurre a una tarea generalmente llamada Anlisis Funcional, donde se estudia la empresa desde el punto de vista de las fundones y que tiene como resultado una Especificacin Funcional. El producto de la funcin anterior es la Especificacin Funcional. Sera deseable que esta Especificacin Funcional fuera independiente de la Especificacin de Datos. Pero esto no es lo comn en las metodologas estudiadas. Las especificaciones producidas son "file dependents" y, en consecuencia, modificaciones en el diseo de la base de datos, implican la necesidad de revisar las especificaciones funcionales. Esta es la causa fundamental de los grandes costos de mantenimiento que deben soportar las empresas. Entre las alternativas ms usadas se destacan la programacin en lenguajes de 3a. generacin, y en lenguajes de 4a. generacin. Lenguajes de 3a. Generacin: Lenguajes de bajo nivel como pueden ser COBOL, RPG. C, PASCAL, ADA, FORTRAN. Lenguajes de 4a. Generacin: Lenguajes de programacin de alto nivel como pueden ser CA IDEAL. INFORMIX 4GL. NATURAL 2, PROGRESS, etc. Desde un punto de vista conceptual, ambos casos son idnticos. En ambos el analista debe estudiar el problema, transformarlo en un algoritmo y codificar dicho algoritmo en el lenguaje de programacin. Sin embargo, existe una fuerte diferencia: en los lenguajes de 4a. generacin se escribe mucho menos (probablemente 10 veces menos) y, como consecuencia, la productividad es mucho mayor y el nmero de errores cometidos es mucho menor. Podra argumentarse en contrario, que se pierde flexibilidad con estas herramientas, lo que es cierto en trminos tericos, pero es irrelevante en trminos prcticos, dado que hoy estas herramientas estn dotadas de primitivas que permiten complementar su cdigo, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta a ambos por igual. Como consecuencia, los lenguajes de 4a. generacin permiten aumentos de productividad muy grandes sobre los de 3a., en la tarea de desarrollo, pero ayudan bastante poco en la de mantenimiento. Otra alternativa es la utilizacin de un "generador" que es una herramienta que puede interpretar la especificacin funcional, (que obviamente debe ser totalmente rigurosa), y producir automticamente los programas.

5
Aqu existe una diferencia conceptual muy grande con el caso anterior. En este caso el analista describe el problema de una forma declarativa (no existe algoritmo ni codificacin procedural alguna). Algunos ejemplos son ADELIA, AS/SET. LANSA, SYNON. TELN. etc. Existe otra categora de herramientas conceptualmente idntica: la de aquellas que, simplemente, interpretan la especificacin, como por ejemplo: MAGIC y SAPIENS. La programacin en ambos casos es totalmente automtica, por lo que el aumento de productividad sobre las herramientas de 3a. generacin es muy grande. Podra argumentarse en contrario, como a menudo se ha hecho con las herramientas de 4a. generacin, que se pierde flexibilidad con estas herramientas, lo que es cierto en trminos tericos, pero es irrelevante en trminos prcticos, dado que, hoy, estas herramientas estn dotadas de Lenguajes de Diagramas de Accin, (en la prctica lenguajes de 4a. generacin), que permiten complementar su cdigo, por lo que su aplicabilidad ha crecido mucho. El problema visto, de que las descripciones de los procesos dependen de la base de datos, afecta tambin a las aplicaciones generadas mediante estas herramientas. Como consecuencia, los Generadores y los Interpretadores (como los lenguajes de 4a. generacin) ayudan bastante poco en la tarea de mantenimiento. Resumiendo aqu las tres opciones vistas: Lenguajes de 3a. Generacin Lenguajes de 4a. Generacin Generadores Baja productividad en el desarrollo Buen aumento de productividad en el desarrollo sobre L3G.

Buen aumento de productividad en el desarrollo sobre L3G y L4G.

Desde el punto de vista del mantenimiento, ninguna de las herramientas ayuda mucho dado que, en todas ellas, se utilizan descripciones de procesos que pueden perder su validez cuando existen modificaciones de archivos y que, por ello, deben ser revisadas y mantenidas manualmente. Existe, sin embargo, un postulado cuyo cumplimiento evitara este problema: PUEDE OBTENERSE UNA BASE DE DATOS ESTABLE. Lamentablemente, este postulado es falso, y sobran los contraejemplos que lo demuestran.

METODOLOGA CENEXUS: Los fundadores de ARTech han desarrollado una amplia actividad de consultara internacional en diseo de grandes bases de datos. Cuando se comenzaron a utilizar verdaderos modelos corporativos, que normalmente poseen cientos de tablas, les qued claro que no deba perderse ms tiempo buscando algo que no existe: las bases de datos estables. Luego de importantes investigaciones, desarrollaron una teora, organizaron una metodologa e implementaron una herramienta para posibilitar el desarrollo incremental y permitir la convivencia con las bases de datos reales (inestables), a costo mnimo.

6
Desarrollo con GENEXUS:

Utilizando GENEXUS, la tarea bsica del analista es la descripcin de la realidad. Slo el hombre podra desarrollar esta tarea, ya que slo l puede entender el problema del usuario. Desde luego que esto modifica la actividad del analista e, incluso, su perfil ptimo, ya que lo transforma en un "Business Analyst". Ahora trabaja en alto nivel, discutiendo problemas con el usuario y probando con l las especificaciones a nivel de prototipo, en vez de desarrollar su actividad a travs de tareas de bajo nivel como son: disear archivos, normalizar, disear programas, programar, buscar y eliminar los errores de los programas.

Al crear un nuevo sistema o proyecto Genexus, se crea una nueva Base de Conocimiento. Una vez creada la nueva Base de Conocimiento, el siguiente paso es empezar a describir los objetos de la realidad mediante objetos Genexus. A partir de los objetos definidos en la Base de Conocimiento, GENEXUS genera automticamente tanto los programas de creacin / reorganizacin de la base de datos como los programas de la aplicacin.

7
El trmino Base de Conocimiento hace referencia a la capacidad de reutilizar en forma automtica el conocimiento almacenado y sobre todo a la capacidad de realizar inferencias que permiten obtener ms conocimiento.

Como se ha visto, existen varios caminos para la implementacin de aplicaciones:

1. PROGRAMACIN UTILIZANDO LENGUAJE DE 3A. GENERACIN. 2. PROGRAMACIN UTILIZANDO LENGUAJES DE 4A. GENERACIN 3. GENERACIN / INTERPRETACIN AUTOMTICA DE LA ESPECIFICACIN FUNCIONAL. 4. DESARROLLO INCREMENTAL.

La productividad en el desarrollo de aplicaciones aumenta de arriba a abajo. Disminuir en gran forma el mantenimiento de las aplicaciones (datos y programas), slo se consigue con el desarrollo incremental.

La primera tarea que hay que realizar es pasar a describir los objetos de la realidad, mediante objetos Genexus. Para ello existen 5 objetos bsicos: Transacciones: Las transacciones permiten definir los objetos de la realidad. La mayor parte de las transacciones pueden ser identificadas prestando atencin a las entidades que el usuario menciona (por eje. Clientes, Proveedores, Artculos). A partir de las transacciones Genexus infiere el diseo de la base de datos.

8
Procedimientos: Procesos no interactivos de actualizacin de la base de datos (procesos baten). Reportes: Recuperan informacin a partir de los datos almacenados y no los alteran. Los reportes son lo que conocemos habitualmente como listados. Paneles de trabajo: Permite definir consultas interactivas a la base de datos. Es un objeto muy flexible que se presta para mltiples usos. Menes: Objetos organizadores del resto. Sistematizacin del conocimiento:

Veamos ahora con ms detalle el proceso de desarrollo de una aplicacin con GeneXus. GeneXus captura el conocimiento que reside en los objetos descritos y lo sistematiza en una base de conocimiento. GENEXUS funciona basado en su capacidad de inferencia. As infiere, por ejemplo:
En el modelo de datos: las tablas, las restricciones de integridad y los ndices necesarios. Los programas de creacin y/o de reorganizacin de la base de datos. Los programas de la aplicacin. Los anlisis de impacto de los cambios.

A partir del conocimiento especificado a travs de las transacciones, GENEXUS disea el modelo de datos normalizados (en 3 Forma normal).

GENEXUS genera automticamente los programas necesarios para crear la base de datos, y la crea mediante ellos. GENEXUS genera automticamente, a partir de la base de conocimiento, los programas de la aplicacin.

10

En este estado, la aplicacin est lista.

Como se ha dicho, durante el ciclo de vida de la aplicacin, existen muchas modificaciones.

11
Ante cambios en las visiones de usuarios, GENEXUS disea la nueva base de datos.

Algunas veces, la nueva base de datos coincide con la anterior, en cuyo caso, todos los programas existentes seguirn siendo vlidos. Otras veces, existen cambios en la base de datos. El anlisis de impacto de los cambios nos informa si debe reorganizarse la base de datos, cmo debe ser hecha esa reorganizacin y, los eventuales problemas que esa reorganizacin podra ocasionar. Una vez analizado el anlisis de impacto, el analista resolver efectuar la reorganizacin o renunciar a ella volviendo a la situacin anterior.

Si el analista ha dado el visto bueno a la reorganizacin, GENEXUS genera automticamente los programas necesarios para esa reorganizacin. GENEXUS, considerando la base de conocimientos nueva y la vieja, estudia el impacto de los cambios sobre los programas actuales y produce un informe sobre el tema. La reorganizacin

12
consiste entonces, en ejecutar esos programas. En realidad es de esperar que tengan muchas tablas comunes, que no se modificarn en la reorganizacin.

GENEXUS genera / regenera automticamente los programas necesarios.

13
Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento est completo.

Mltiples Plataformas de ejecucin a partir de una nica especificacin.

ARQUITECTURAS CENTRALIZADAS Plataforma AS/400 ARQUITECTURAS FILE SERVER Plataforma DOS WINDOWS Lenguaje Generado Foxpro, Clipper Foxpro for Windows Visual Basic Visual Fox Lenguaje Generado COBOL/ 400, RPG/400

DBF DBF Access DBF

ARQUITECTURAS CLIENT/ SERVER Plataforma FOXPRO FOR WIN, VB, VFP Lenguaje Generado ORACLE MS SQL SERVER INFORMIX DB2 Common Servers DB2/ 400

Unix, NT Alfa, Windows NT y 95 Unix, NT RS6000, OS2 AS400

La construccin automtica de la Base de Datos y programas a partir de una nica fuente de especificacin permitir a GENEXUS aplicar una metodologa de desarrollo que podramos llamar "Metodologa Incremental", ya que el proceso se realiza mediante aproximaciones sucesivas.

14
En cada momento desarrollamos la aplicacin con el conocimiento que tenemos y luego cuando pasamos a tener ms (o simplemente diferente) conocimiento, GENEXUS se ocupar de hacer automticamente todas las adaptaciones en la base de datos y programas. El incrementar una aplicacin implica cambios en la base de datos y programas. Los cambios en la base de datos pueden tener un costo aceptable, pero el alto costo de las adaptaciones de los programas haran inviable la aplicacin de este mtodo si no fueran resueltos automticamente. Ciclos Diseo-Prototipo y Diseo-Produccin

El trabajo consiste de dos ciclos: el Ciclo de Prototipacin y el Ciclo de Produccin. Ciclo de Prototipacin: El diseador recorrer repetidamente el bucle Diseo-Prototipo durante la fase de diseo, construyendo y probando sucesivos prototipos del modelo. Ciclo de Produccin: Por el contrario, pasar menos frecuentemente al bucle de Diseo-Produccin, ya que la generacin del sistema se realiza solamente cuando el prototipo ha sido totalmente aprobado, o luego de haber instrumentado y probado algn cambio. Prototipacin Integral en PC:

15
La construccin automtica del soporte computacional nos dar la gran posibilidad de crear prototipos. Verdaderos prototipos, ya que estos tendrn un funcionamiento equivalente al del sistema en produccin real, permitiendo que se pruebe hasta el ltimo detalle de la aplicacin. Los resultados que todos quieren ver, estn en forma de programas ejecutando, lo que no es posible sin la utilizacin de prototipos. Ventajas de la Prototipacin: Permite ver resultados en forma temprana Permite el seguimiento de los requerimientos del usuario Deteccin de errores en forma temprana Logra el compromiso de los usuarios con el desarrollo Sistemas de mejor calidad Toda comunicacin es suceptible de errores: El usuario olvida ciertos detalles. El analista no toma nota de algunos elementos. El usuario se equivoca en algunas apreciaciones. El analista interpreta mal algunas explicaciones del usuario. Pero, adems, la implementacin del sistema es, habitualmente, una tarea que consume bastante tiempo. Como muchos de estos problemas slo son detectados en las pruebas finales del sistema, el costo (tiempo y dinero) de solucionarlos es muy grande y la realidad cambia, por lo que no es razonable pensar que se pueden mantener las especificaciones mientras se implementa el sistema. La consecuencia de mantener las especificaciones, es que se acaba implementando una solucin relativamente insatisfactoria. El impacto de estos problemas disminuira mucho si se consiguiera probar cada especificacin, inmediatamente, y saber cual es la repercusin de cada cambio sobre el resto del sistema. Una primera aproximacin a esto, ofrecida por diversos sistemas, es la posibilidad de mostrar al usuario formatos de pantallas, informes, etc. animados por menes. Esto permite ayudar al usuario a tener una idea de qu sistema se le construir pero, al final, siempre se presentan sorpresas. Una situacin bastante diferente sera la de poner a disposicin del usuario para su ejecucin, inmediatamente, una aplicacin funcionalmente equivalente a la deseada, hasta en los mnimos detalles. Esto es lo que hace GeneXus: Un prototipo GeneXus es una aplicacin pronta, funcionalmente equivalente a la aplicacin de produccin. La diferencia entre prototipacin y produccin consiste en que la primera se hace en un ambiente de PC, mientras que la produccin se realiza en el ambiente objeto del usuario (AS/400, PC o redes de PC). El prototipo permite que la aplicacin sea totalmente probada antes de pasar a produccin. Durante estas pruebas, el usuario final puede trabajar con datos reales, o sea que prueba, de una forma natural, no solamente formatos de pantallas, informes, etc. sino tambin frmulas, reglas del negocio, estructuras de datos, etc. Problema: Analizar un proceso de emisin de las facturas en una empresa:

Ahora vamos a concentramos en cul es la forma prctica utilizada por GeneXus, para la captura de la realidad de la que tanto hablamos. Jean Dominique Wamier y Ken Orr, formularon una teora acerca de cmo puede ser construida una aplicacin de procesamiento de datos. Algunos de sus enunciados fueron los siguientes:

16

Los datos y los procesos estn estructurados. Todos los procesos son subdivididos en subconjuntos partiendo del nivel ms alto y empleando reglas de subdivisin adecuadas (de manera Jerrquica). Todo Proceso tiene un Comienzo, un Cuerpo, y un Final. Esta regla se aplica a la organizacin de datos y resultados.

Resolucin: Tenemos en este proceso 5 niveles, distinguiendo en cada nivel, los conjuntos repetitivos de lo que est presente una sola vez. Vemos que la gestin jerrquica de los datos hace aparecer relaciones entre los conjuntos definidos en los distintos niveles.

Existe entonces una ley de correspondencia: Un elemento de un conjunto de un nivel inferior, se corresponde con uno del nivel superior, si esta incluido en l. Todo conjunto de nivel inferior se llama Conjunto de Partida y todo conjunto de nivel superior se llama Conjunto de Llegada. En el momento de jerarquizar procesos y datos, sera muy bueno que obtuviera este tipo de relaciones. El no observar esta ley es fuente de confusin, eliminando la claridad y la simplicidad de la organizacin de los datos tanto como la de los procesos. DISEO DE TRANSACCIONES Notacin GeneXus para Transacciones: Ejemplo: Proceso de Emisin de Facturas FacNro* CliCod CliNom FacFch (ProdCod* ProdNom ProdPre) Cdigo de la factura Cdigo del cliente Nombre del cliente Fecha de la factura Cdigo del producto Nombre del producto Precio del producto

17

El siguiente paso es encontrar una forma de notacin adecuada para GeneXus. Por ejemplo, una transaccin de emisin de Facturas tendr la siguiente notacin. Cada nivel definir un conjunto de atributos que deben operar en conjunto. Se ingresarn, eliminarn o modificarn conjuntamente en la base de datos. Precisamos entonces encontrar un conjunto de atributos que acte como identificador de cada instancia de este conjunto. Notaremos a estos atributos con un asterisco. Este es en definitiva el concepto de clave primaria por lo que en la eleccin de estos atributos debemos atender a todas las reglas correspondientes a su definicin. El conjunto de atributos entre parntesis representa la ocurrencia de varios para cada instancia del nivel anterior. En el ejemplo, una factura tiene varios productos. Definicin del diseo de Base de Datos en 3era Forma Normal para soportar las transacciones definidas.

Veamos el proceso de obtencin de una base de datos en 3a Forma normal a partir de las especificaciones de transacciones. Para esto utilizaremos como ayuda las dependencias funcionales que se derivaran de la definicin de la transaccin. La definicin de esta primera transaccin a determinado las siguientes dependencias funcionales. FacNro FacNro FacNro CliCod CliNom FacFch

Por lo que se definir una tabla con el siguiente diseo FacNro* CliCod CliNom FacFch Tenemos adems las siguientes dependencias funcionales determinadas por el 2do nivel de la transaccin.

18

FacNro, ProdCod FacNro, ProdCod FacNro, ProdCod FacNro, ProdCod

ProdNom ProdPre FacLinCnt FacLinImp

Que definirn una tabla con el siguiente diseo ProdCod* ProdNom ProdPre FacLinCnt FacLinImp

La definicin de dos nuevas transacciones: Clientes y Productos han determinado la aparicin de nuevas dependencias funcionales. GeneXus disear las nuevas tablas que correspondan (Clientes y Producto) y realizar las modificaciones necesarias en las ya existentes (Factura y Factura1) para considerar el conjunto total de dependencias funcionales. CliCod ProdCod CliNom ProdNom, ProdPre

La siguiente dependencia funcional FacNro CliNom

Se ha vuelto transitiva a partir de la existencia de las dependencias funcionales. FacNro CliCod CliCod CliNom

Por lo que deber modificarse la tabla Factura. Anlogamente con la tabla Factura1 y las dependencias funcionales FacNro, ProdCod ProdCod ProdNom, ProdPre ProdNom, ProdPre

19

Es conveniente usar padrones para los nombres de atributos. Facilitan la tarea de darle nombre a un atributo dentro de las reglas establecidas Facilitan la tarea de integracin de bases de conocimiento

ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos ms o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilizacin de conocimiento entre ellos. Nombre de atributo Objeto + Categora + Calificador Objeto, Es el nombre de la transaccin a la que pertenece el atributo. Categora, Es la categora semntica del atributo.

20
Calificador, Puede existir uno o dos calificadores.

Ejemplo: de Nomenclatura GIK Objeto Cli Cli Cli Cli FacVta FacCmp Tipos de Datos: Numeric, Character, Date Long Varchar VarChar - Equivalente al Character, salvo en la forma en que se almacena en la BD. DateTime - Los valores de M y N no afectan la forma de almacenar el tipo de datos, sino la forma de aceptar o mostrar su contenido. Long Varchar: Permite almacenar una cantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, descripciones, comentarios, etc. El largo que se le asigna es considerado el largo mximo (la implementacin depende de la plataforma). VarChar: Permiten almacenar texto de largo variable. Su funcin, en contraposicin al character, es la de optimizar el almacenamiento en la base de datos. Definicin: Varchar(M, N)
M: Es el largo mximo posible que depender del DBMS. Si el largo asignado al atributo es mayor que el soportado por el DBMS se utilizar el mximo soportado. N: Es el largo promedio. Se utiliza para optimizar los accesos a disco en algunos DBMSs.

Categoras Cod Nom Fch Fch Nro Nro

Calificador

Ini Fin

La idea es que si el valor de un atributo varchar es menor o igual que N, se almacenan N caracteres (rellenados con blancos) en el registro del archivo y se utiliza un nico acceso a disco para leerlo o grabarlo. En caso que el valor del atributo varchar sea mayor que N, se almacenan los primeros N en el registro del archivo y el resto en un rea de overflow para lo cual es necesario un acceso adicional tanto para lectura como para escritura. Se le pueden aplicar todas las funciones y operadores existentes para el tipo de datos character. El tipo de datos Varchar es equivalente al tipo Character en todos los sentidos salvo en la forma en que se almacena en la base de datos. Para los DBMS que no soportan este tipo de dato se crean como Character. DateTime: Permite almacenar una combinacin de fecha y hora (hasta el segundo). DateTime(M. N)
M = Largo de la fecha. Valores posibles: 0, 8 y 10. N = Largo de la hora. Valores posibles: 2, 5 y 8.

21
Los valores de M y N, no afectan la forma de almacenar el tipo de datos sino especficamente a la forma de aceptar o mostrar su contenido. En caso que M sea 0 (no se considera la fecha) para un campo que ha de ser ingresado, el valor de fecha a asignar ser el mnimo soportado por el DBMS y reconocido como fecha vaca o nula en GeneXus. En caso que N sea distinto de 8 para un campo que ha de ser ingresado, los valores no aceptados (minutos o minutos y segundos) sern considerados en cero. Dominios: Cuando debemos usar dominios? Atributos con la misma definicin No existe relacin entre ellos Ejemplo: Direccin Char30 Direccin del Cliente Atributos Direccin del Banco El objetivo de los dominios es permitir usar definiciones de atributos genricos y luego poder asociar un atributo con su correspondiente dominio. En el ejemplo, el dominio Direccin es definido como Char de 30. Los atributos direccin del banco y del diente son asociados a l. Por lo tanto, si en el futuro se cambia la definicin de este dominio, los cambios van a ser automticamente propagados a todos los atributos que pertenezcan a ste. De esta forma los dominios permiten un mayor nivel de abstraccin en la definicin de la aplicacin. Reglas: Se utilizan para definir el comportamiento de las transacciones. Algunas reglas
- Defult, Error, Ask, Msg, Asignacin, Add, Subtract, etc.
Default(FacFch, &today); Error('No se permiten clientes sin nombre') ifnull(CliNom);

Dominio

Pueden incluir: atributos, variables, constantes y funciones. Las reglas son LOCALES a la transaccin. Programacin DECLARATIVA Segn el Anlisis Orientado a Objetos, para cada objeto del sistema se debe definir cual es su estructura y su COMPORTAMIENTO. En el caso de las Transacciones, el comportamiento se define mediante el uso de Reglas (Rules). Algunas reglas: Defult: Se utiliza para definir los valores por defecto de algunos atributos. Error: Es para definir los controles que deben cumplir los datos, por ejemplo si no queremos permitir que queden ingresados clientes sin nombre:

22
Error('No se permiten clientes sin nombre')ifnull(CliNom); Cuando se cumple la condicin ( null(CliNom) ) se despliega el mensaje ('No se permiten clientes sin nombre') en pantalla y no se permite continuar hasta que el usuario ingrese un nombre sobre el campo CliNom. Asignacin: Dentro de las reglas de la transaccin se permiten definir asignaciones a atributos, dicha asignacin implica una actualizacin en la tabla base del nivel o en alguna de las tablas que pertenecen a la tabla extendida del nivel. Una asignacin en las reglas es LOCAL (vale solo para la transaccin en la cual fue definida). Orden de evaluacin: La definicin de reglas es una forma DECLARATIVA de definir el comportamiento de la transaccin. El orden en el cual fueron definidas no necesariamente indica que ese sea el orden en que se encuentran en el programa generado. GeneXus se encarga de determinar el orden correcto segn las dependencias de atributos existentes (en este tema entraremos en detalle mas adelante).

Tool Bars de Controles:

Usados en el diseo de Pantallas: Atributo / Variable Recuadro Botn Bitmap Tab Control PrintBIock

Se utiliza para disear la pantalla (form) en forma grfica. Mientras se est diseando un form (de TRN's, WKP's o Reports) est disponible la tool bars de Controles que contiene los tipos de controles que se pueden agregar al form que se est editando. Tab Control: Permite definir varios controles dentro de un Tab Control. Tiene una o varias pginas. - Defult: Dos pginas - Agregar o eliminar pginas: Botn derecho sobre el Tab Control - Pgina Ttulo rea til - Check Box de Hide Tabs Para diseo de Wizards
(Recuadro al cambiar de pantalla)

Slo para los generadores visuales.

23
Un Tab Control tiene una o varias pginas (por defecto tiene dos). Cada pgina tiene un ttulo y un rea til, es decir donde se ponen los controles de esa pgina. Slo una de las pginas puede estar activa a la vez y es la que se puede ver. Del resto slo se ver su ttulo. Las opciones Edit/Add Tab Page y Edit/Remove Tab Page son para agregar y eliminar pginas respectivamente. Puede accederse tambin a estas opciones con botn derecho sobre el Tab Control. Hide Tabs: Para mostrar slo la pgina activa y no mostrar los tabs. til para la definicin de Wizards. Generacin de HELP Tipo Windows: Es necesario generar y compilar el Help. - Opcin: Build/Generate Help - El compilador viene con el Visual Basic/Foxpro/Visual FoxPro Disponible solamente en los generadores windows.

Esto es para los generadores Windows. Se genera un .HLP compatible con el Help de Windows. El compilador de Help como se mencion ms arriba viene con el Visual Basic/FoxproA/isual FoxPro y se requiere como mnimo la version3.10.505. Botn de Help: - Llama al help del objeto. F1: - Llama al help del atributo en donde se encuentra el cursor. Si ese atributo no tiene help se llama al help del objeto. INTEGRIDAD REFERENCIA:

Diagrama de Bachean:

Las reglas de integridad referencial permiten asegurar la consistencia entre los datos de las distintas tablas. El diagrama anterior se ha inspirado en los conocidos Diagramas de Bachman, y tiene la virtud de explicitar la integridad referencial del modelo de datos.

24
En el ejemplo, existe una relacin entre la tabla Clientes y Departamentos y tambin entre Clientes y Categoras. La relacin entre dos tablas se determina analizando los atributos que tienen en comn. Por ejemplo, entre las tablas Clientes y Categoras tenemos que el atributo comn es el cdigo de la categora, que es la clave primaria de la tabla Categora. Decimos que la relacin entre ambas tablas es 1-N, que indica que un cliente tiene una categora y una categora tiene N clientes. Tambin es usual decir: . La tabla Categoras est Superordinada a la tabla de Clientes . La tabla de Clientes est Subordinada a la tabla de Categoras Esta relacin implica que la informacin contenida en ambas tablas no es independiente, por lo que es necearlo realizar controles para que la informacin sea consistente. A estos controles se les llama de Integridad Referencial y bsicamente son los siguientes: Cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir el registros correspondientes en la tabla subordinada (Client). Definicin de ndices: Tabla Tipo Catego Depart Client PK PK PK FK FK CatCod DtoCod CliCod DtoCod CatCod Indice Composicin

Definicin de ndices: Para hacer eficiente los controles de Integridad, GeneXus crea automticamente ndices, que son vas de acceso eficientes a las Tablas. Existen tres tipos de ndices: Primarios, Extranjeros y del Usuario. ndice Primario (PK): El ndice primario es el que se define para la Clave Primaria, se utiliza para el control de unicidad de los registros y para el control de que cuando se crean registros en la tabla subordinada (Client), debe existir el registro correspondiente en la tabla superordinada (Catego). Con GeneXus todos los ndices primarios son definidos automticamente a partir de los identificadores de las transacciones. ndice Extranjero (FK): Los ndices extranjeros son utilizados para hacer eficientes los controles de integridad inter-tablas. Tambin son definidos automticamente. Cuando se elimina un registro en la tabla superordinada (Catego), no deben existir registros correspondientes en la tabla subordinada (Client). ndice del Usuario: Los ndices del usuario se definen, fundamentalmente, para recorrer los datos por determinado orden de una forma eficiente. Por ejemplo, en la tabla Client se puede definir un ndice por CliNom, que es muy til para los listados ordenados por nombre.

25
Los ndices del usuario NO son definidos automticamente ya que no se usan para los controles de integridad. En una Base de Datos Relacional los ndices se utilizan slo por problemas de performance, pero siempre es posible acceder a los datos de la tabla por cualquiera de los atributos de la misma. CONCEPTO DE TABLA EXTENDIDA: Definicin de Tabla Extendida: Dada una tabla de la base de datos, se denomina tabla extendida de la misma al conjunto de atributos conformado por: - Atributos que pertenecen a la tabla. - Atributos que tengan una relacin N-1 con la tabla extendida determinada hasta el momento. Los criterios de normalizacin del diseo de la base de datos apuntan a minimizar la posibilidad de inconsistencia en los datos. Una base de datos diseada de esta manera tiene una serie de ventajas importantes (tal es as que actualmente la normalizacin de datos es un standard de diseo), pero se deben tener en cuenta tambin algunos inconvenientes. El inconveniente ms notorio es que los datos se encuentran dispersos en muchas tablas, y por lo tanto cuando se quieren hacer consultas ms o menos complejas a la base de datos se debe consultar una cantidad importante de tablas. As, por ejemplo, para listar las facturas sera necesario consultar las tablas Cabezal y lneas de Facturas, Clientes, Categoras y Productos. Para simplificar esta tarea GeneXus utiliza el concepto de tabla extendida.

Tabla Base
Categora Cliente Factura

Tabla Extendida
Categora Cliente Categora Factura Cliente Categora Factura1 Producto Factura

Factura1

26
Cliente Categora Producto

Producto

ATRIBUTOS FORMULAS: Caractersticas: Relacin entre Atributos, Constantes o Funciones. Definicin Global, definidas a nivel del modelo. Atributo Virtual (No se almacena en la tabla). Son calculadas siempre que se hace referencia al atributo. Un atributo es una frmula si su valor se puede calcular a partir del valor de otros atributos. En cada transaccin se puede definir qu atributos son frmulas, pero esta definicin es global (no es local a la transaccin), es decir toda vez que se necesite el atributo se calcula la frmula, tanto en transacciones como en los otros objetos GeneXus. Existe una similitud entre frmulas y asignaciones (regla), incluso la sintaxis de definicin es similar. La diferencia entre ambas es que una frmula es GLOBAL (vale para todos los objetos GeneXus que la utilicen), mientras que una asignacin en las reglas es LOCAL (vale slo para la transaccin en la cual fue definida). Cuando un atributo es frmula, ste no est almacenado (a no ser que se lo defina como redundante) y cuando es una Asignacin, por ser esta local, si esta almacenado. Clasificacin: Horizontales: Una o varias expresiones aritmticas condicionales. Verticales: SUM COUNT Aggregate / Select: Select Max, Min, Find Aggregate Sum, Count, Set Frmula Horizontal: Los atributos involucrados en la misma deben pertenecer a la tabla extendida del atributo definido como frmula. Frmula Vertical: Los atributos involucrados deben pertenecer a la tabla directamente subordinada del atributo definido como frmula. Son incondicionales. Aggregate / Select: Pueden navegar sobre cualquier tabla del modelo. Son condicionales.

Fmulas Horizontales: Atributo = <Expresin> if<Condicin>; <Expresin> if<Condicin>; <Expresin> Otherwise;

27

<Expresin>: es una expresin aritmtica que puede involucrar atributos, constantes y funciones. Los atributos que participan de la expresin deben pertenecer a la tabla base y/o a tablas que estn en una relacin N para 1 con la tabla sobre la que se define la frmula (es decir, a la tabla extendida del atributo definido como frmula). El atributo frmula deja de estar almacenado en la tabla y decimos que es un atributo virtual. <Condicin>: Es la condicin de disparo de la frmula. Cuando se define una frmula horizontal, GeneXus sabe cual es la tabla extendida del atributo que se est definiendo como frmula, y controla que todos los atributos utilizados en dicha frmula se encuentren en ella.

Frmulas Horizontales: Ejemplo: TRANSACCIN CliCod* CliNom CliTotCmp CliTotPgo TABLA CliCod* CliNom CliTotCmp CliTotPgo

CliSdo = CliTotCmp - CliTotPgo Un atributo puede definirse como frmula cuando su valor se obtiene siempre de un clculo que puede involucrar atributos, constantes y/o funciones. Por ejemplo, el saldo del cliente es siempre la diferencia entre el total de compras y el total de pagos. Diferencias entre Frmulas y Reglas: Frmula: La frmula es una definicin global ya que est a nivel del modelo de datos, su valor ser calculado cada vez que se utilice en cualquier objet GeneXus ya que el atributo no est almacenado en la tabla. Regla: La regla est definida a nivel local en la transaccin. Cada vez que se mencione el atributo, su valor no se calcular, sino que se tomar directamente de la tabla.

28

En el ejemplo, definimos al importe del producto en la factura (FacLinImp) como una frmula horizontal, por lo cual dicho atributo no est almacenado en la tabla Factura1. Frmulas Verticales: SUM - COUNT Sintaxis: - AtriFla = SUM(Att) - AtriFla = COUNT(Att) Caractersticas: - Att debe pertenecer a una tabla directamente subordinada a la tabla en la que se encuentra AtriFla. - Son incondicionales. - Navegacin vertical Performance Caractersticas de las Frmulas Verticales: SUM: Suma un atributo perteneciente a una tabla directamente subordinada. COUNT: Cuenta las filas de una tabla directamente subordinada. Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de una tabla que est directamente subordinada. La tabla est en una relacin 1 a N. Se consideran todas las filas que pertenecen a la relacin ya que no se pueden establecer condiciones. Se resuelve mediante una navegacin vertical, de ah el nombre Frmulas Verticales. Performance: El hecho que la frmula no est almacenada puede ocasionar problemas de performance, debido al tiempo que puede demorar el reclculo. Para evitar este inconveniente se puede definir la frmula como REDUNDANTE. En este caso la frmula se almacena en la Base de Datos y no es necesario recalcularla cada vez que se use. Profundizaremos en este tema ms adelante.

29
Precisamos calcular ahora el subtotal de las lneas de la factura, que hemos llamado FacSubTot. Este atributo est en el cabezal de la factura y el atributo a ser sumado en las lneas. Estas tablas estn en una relacin de 1 a N. por lo que no podemos utilizar una frmula horizontal. Precisamos una frmula que recorra todas las lneas de la factura y las sume, utilizamos para esto una frmula SUM( ) perteneciente a las llamadas Frmulas Verticales. Se puede decir que un SUM redundante es equivalente a la regla ADD.

Frmulas Verticales:

Slo se puede definir entre atributos de tablas directamente subordinadas. Dentro de una frmula vertical no se puede mencionar directa o indirectamente una frmula AGGREGATE/SELECT. El atributo mencionado en la frmula COUNT no puede formar parte de ninguna clave. El atributo mencionado en la frmula SUM puede ser frmula. Para frmulas de frmulas GeneXus determina cul es el orden de evaluacin correspondiente. Frmulas Aggregate/Select: Son frmulas que permiten buscar, sumar, contar atributos que cumplan determinadas condiciones, en cualquier tabla del modelo. Aggregate - Sum - Count - Set Select - Max - Min - Find Frmulas Aggregate: Sum: Suma condicionalmente atributos de cualquier tabla del modelo. Count: Cuenta condicionalmente filas de cualquier tabla del modelo. Set: Imprime instancias de un atributo en determinadas condiciones.

30

Frmulas Seiect: Find: Buscar el valor de un atributo en determinadas condiciones. Max: Buscar el mximo valor de un atributo en determinadas condiciones. Min: Buscar el mnimo valor de un atributo en determinadas condiciones.

Sintaxis: - atrib = Sum | Count (<att>, <cond. bsq.>, <def>) - atrib = Set(<Att>, <Cond>, <Def>) - atrib = Max | Min(<att>, <cond. bsq. >, <def>, <ret>) - atrib = Find(<att>, <cond. bsq.>, <def>)

atrib: es el atributo que se define como frmula. Sum: (atributo a ser sumado, condiciones que debe cumplir, valor por defecto) Set: Selecciona las primeras ocurrencias (hasta 50) del atributo <att> que cumplen la condicin <cond.>, y las manipula como si fueran un solo atributo. Si no se especifica ninguna condicin, las primeras 50 ocurrencias sern seleccionadas. <def>: Es el valor por defecto devuelto cuando ningn registro cumple la condicin <cond>. Si no se menciona nada en <def> se devuelve el nulo del tipo de datos de <att>. Max: (atributo a maximizar. condiciones de maximizadn, valor por defecto en caso de no encontrar quien cumpla con las condiciones, valor de retomo en caso de encontrar) Find: (atributo a buscar, condiciones de bsqueda, valor por defecto en caso de no encontrar quien cumpla con las condiciones). Frmulas Aggregate: .Sum() Aggregate .Count() Aggregate Se utilizan cuando el valor de un atributo se obtiene sumando o contando filas de cualquier tabla del modelo que cumplan una determinada condicin. Atributo = Sum | Count (<Atributo Sumado o Contado>,<Condicin para sumar o contar> , <valor de retomo por defecto) IF <Condicin de disparo> A diferencia de las Frmulas SUM y COUNT Verticales no es necesario que estn en una relacin de subordinacin. NOTA: Para distinguirlas en los listados: Verticales: SUM y COUNT todas las letras en maysculas. Aggregate - Sum y Count: Slo la primera letra con mayscula Los siguientes ejemplos de frmulas Aggregate y frmulas Select, se incluyen como documentacin y no necesariamente se harn ejemplos en el curso, salvo que los alumnos lo pidan. Ejemplo de Count Aggreaate: Total de productos con descuento en la factura: Factura FacNro* FacFch

31
CliCod FacTotArtDscto = Count(ProdCod, FacDscto > 0) Factura1 FacNro* ProdCod* FacLinCnt FacDscto FacLinImp FacNro 1 1 1 1 ProdCod 1 2 3 4 FacDscto 10 0 20 0

FacTotArtDscto = 2 Find: Se utiliza para obtener el valor de un atributo que est en cualquier tabla del modelo, pudiendo establecerse relaciones con cualquiera de los atributos de la tabla. Sintaxis: Atributo=Find(<Atributo a buscar>, <Condicin de bsqueda>, <Valor por defecto>) IF <Condicin de disparo) Ejemplo de uso de Find (): El atributo DocCotDolar obtiene la cotizacin del dlar del da. La tabla de cotizaciones no tiene ninguna relacin con la de documentos. Documentos DocNro* DocFch Docimp Cotizaciones MonCod* MonFch* MonCot

DoclmpDolar = Doclmp / DocCotDolar DocCotDolar = Find(MonCot, MonCod = 'U$S' .and. MonFch = DocFch)

Max: Esta funcin determina el mximo valor de un atributo en una tabla. Obtenido este valor, que corresponder a una determinada fila, la funcin devuelve el valor de cualquier atributo de dicha fila. Sintaxis: MAX(<Atributo a Maximizar>, <Condicin de Maximizacin>, <Valor por defecto, <Atributo a Devolver>) IF <Condicin de ejecucin> Atributo a Maximizar: Debe estar almacenado en la tabla en la que se busca (Tabla de llegada), es decir no puede ser un atributo frmula o pertenecer a su tabla extendida.

32
Condicin de bsqueda: Se pueden mencionar atributos almacenados o virtuales de la tabla base y de la tabla extendida de la tabla de partida. Se pueden mencionar atributos almacenados de la tabla en la que se realiza la bsqueda (Tabla de llegada). Atributo a devolver: Atributo a devolver para asignar al atributo frmula, debe estar almacenado en la tabla de bsqueda. Condicin de disparo: Se pueden mencionar atributos almacenados o virtuales de la tabla base y de la tabla extendida de la tabla de partida. Ejemplo de uso del Max: Obtener la ltima (mxima) cotizacin del dlar anterior a la fecha del documento. Documentos DocNro* DocFch DocImp DoclmpDolar DocCotDolar Cotizaciones MonCod* MonFch* MonCot

Atributo a maximizar... MonFch Condicin......................... MonCod = U$S y el mximo valor de MonFch debe ser menor o igual a la fecha de documento. Atributo a devolver............... MonCot Valor por defecto..................... 0 Ejemplo de uso del Max: DoclmpDolar = Doclmp / DocCotDolar DocCotDolar = Max(MonFch, MonCod = 'USS .and. MonFch <= DocFch. , MonCot) Fecha del Documento 15/01/94, le corresponde la cotizacin del da 13/01/94. MonFch 10/01/94 11/01/94 12/01/94 13/01/94 16/01/94 Min: Atributo = Min(<Atributo a Minimizar>, <Condicin de minimizacin>, <Valor por defecto>, <Atributo a Devolver>) IF <Condicin de disparo> Esta funcin determina el minino valor de un atributo en una tabla. Obtenido este valor, que corresponder a una determinada fila, la funcin devuelve el valor de cualquier atributo de dicha fila. Ejemplo de uso de la funcin Min: Se quiere obtener la cotizacin del dlar para el da de la fecha y en caso de que no exista, la inmediatamente posterior. MonCot 100 110 112 115 117

33

Documentos DocNro* DocFch DocImp

Cotizaciones MonCod* MonFch* MonCot

DocImpDolar = DocImp / DocCotDolar DocCotDolar = Min(MonFch, MonCod = U$S' .and. MonFch >= DocFch, , MonCot) Fecha del Documento 15/01/94, le corresponde la cotizacin del da 16/01/94. MonFch MonCot 10/01/94 100 11/01/94 110 12/01/94 112 13/01/94 115 16/01/94 117 17/01/94 118 Consideraciones aplicables a todas las frmulas Aggregate/Select: Atributo = Find(<Atributo a buscar>, <Condicin de bsqueda>, <Valor por defecto>) IF <Condicin de disparo> En la definicin de la frmula intervienen atributos de varias tablas: La tabla en la que est definido el atributo frmula (tabla de partida). La tabla extendida de la tabla de partida. La tabla en la que se busca (tabla de llegada). IMPORTANTE: No se pueden utilizar atributos de la tabla extendida de la tabla de llegada: Documentos (Tabla de partida) Cotizaciones (Tabla de llegada)

Consideraciones de performance: Tanto las frmulas Verticales como las frmulas Agregate/Select, implican la realizacin de navegaciones en la Base de Datos, por lo que es importante considerar la forma en que esto es realizado. Las frmulas Verticales pueden almacenarse en forma redundante y GeneXus se encargar de mantenerlas actualizadas. Uso de la frmula MAX(): Ejemplo: Buscar el precio del producto segn la fecha de la Factura. Transaccin Productos ProdCod* ProdDsc (ProdFch* ProdPre) Transaccin Factura FacNro* CliCod FacTot FacFch (ProdCod'* FacProdPre FacLinCnt FacLinImp)

34
Atributo = MAX(Atributo a Maximizar), (Condicin de Maximizacin), (Valor por defecto), (Atributo a devolver) IF (Condicin de ejecucin) Uso de la Frmula Max( ) para buscar el precio del producto segn la fecha de la factura. Definimos la transaccin de productos de tal forma de guardar el histrico de precios, con la fecha de aumento de precio asociada. Con la fecha de la factura buscaremos el precio del producto correspondiente. Por ejemplo: Fecha de Factura: 10/10/93 Precio producto correspondiente: 220

correspondiente al 3/10/92

Incluiremos en las lneas de la factura el atributo ProdCod. No podemos incluir ProdFch debido a que no podramos saber que valor darle a la fecha para poder heredar directamente el ProdPre. Definimos el atributo FacProdPre y buscaremos con una frmula el precio correspondiente de acuerdo a la fecha de factura. Buscaremos el precio de fecha mxima anterior a la fecha de factura. La frmula quedara: FacProdPre = Max (ProdFch, ProdFch <= FacFch. 0, ProdPre)

Atributo a Maximizar.. Condicin. Atributo a devolver. Valor por defecto

ProdFch Factura1.ProdCod = Producto1.ProdCod (cond. implcita). El mximo valor de ProdFch <= FacFch (cond. explcita). ProdPre 0, si no se encuentra ningn registro que cumpla la condicin.

Ejemplo: Hacer lo siguiente: A. B. Buscar la cotizacin de la moneda para la fecha del asiento En caso de que no exista, dar un aviso y buscar la ltima ingresada a la fecha del asiento.

35

Transaccin de Cotizaciones MonId* CotMes* MonDsc (CotDia* CotImp) Transaccin de Asientos: AsiNro* AsiFch AsiMes AsiDia* (AsiIidLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) Solucin: A Transaccin de Cotizaciones: MonId* CotMes* MonDsc (CotDia* CotImp) Transaccin de asientos: AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia =Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) =Find(CotImp, CotMes=AsiMes .and. CotDia =AsiDia) ifMonId<NS'; 1 otherwise; B Transaccin de Asientos: AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia Day(AsiFch) (AsiIdLin* MonId AsiImpME AsiImpNS = AsiImpME* AsiFndCot if AsiFhdCot <>0;

36
AsiImpME* AsiMaxCot ifAsiMaxCot <> 0; 1 otherwise; AsiTipDH CtaId AsiFndCot a = Find(CotImp, CotMes = AsiMes .and. CotDia =AsiDia) ifMonId <> NS"; 1 otherwise; AsiMaxCot) = Max(CotDia, CotMes = AsiMes .and. CotDia <=AsiDia, 0 , CotImp) if null (AsiFndCot); 0 otherwise; Rules: Msg ("No existe Cotizacin, se toma la ltima ingresada") if null (AsiFndCot) .and. MonId <> NS"; 1. Condiciones involucradas en una Frmula Aggregate Select: Condicin de Bsqueda: Es la condicin a la cual est sujeta la bsqueda. Condicin de Disparo: Es la condicin que determina si la frmula se ejecuta. 2. Inferencias en el caso de una Frmula Aggregate Select: La condicin de bsqueda queda determinada por: - La condicin explicitada como segundo parmetro. - Atributos que quedan instanciados por el ambiente en el que se dispara la Frmula: Interseccin de la tabla extendida del atributo definido como frmula (tabla de partida) y la tabla sobre la cual se est resolviendo la frmula (tabla de llegada). En el ejemplo: Transaccin de Cotizaciones: Monid* CotMes* Given: MonId MonDsc (CotDia* CotImp) Transaccin de Asientos: AsiNro* AsiFch AsiMes =Month(AsiFch) AsiDia =Day(AsiFch) (AsUdLin* MonId AsiImpME AsiImpNS AsiTipDH CtaId AsiFndCot) = Find(CotImp, CotMes = AsiMes .and. CotDia = AsiDia) if MonId <> S"; 1 otherwise; En la frmula AsiFndCot, est implcita la condicin de que Asiento1.MonId = Cotizad .MonId

37

Esto se refleja en la navegacin como "Given: MonId" 1. Cmo se determina la tabla sobre la cual efectuar la bsqueda (tabla de llegada) Atributo de Bsqueda Atributos que estn en la condicin y que no pertenecen a la tabla extendida del Atributo Frmula Atributo de Retomo De otra forma: <Atr.Frm.> - Frmula Invlida Es importante aclarar que los atributos involucrados en la frmula agrgate select y pertenecientes a la tabla de llegada, deben estar ALMACENADOS en la misma. Es decir, que no pueden ser frmula ni pertenecer a la tabla extendida de la tabla de llegada.

38
4. Frmulas Aggregate Select no pueden participar en frmulas SUM y COUNT simples: No se permite definir una frmula SUM que suma un atributo que es una Aggegate/Select o depende de ella. Ejemplo: FacProdPre = frmula MAX FacLinImp = FacLinCnt * FacProdPre FacSubTot = SUM (FacLinImp) Para resolver esto, se debera almacenar el valor de FacProdPre en otro atributo, pues las Frmulas Aggregate Select NO PUEDEN SER DEFINIDAS REDUNDANTES. O utilizar la regla ADD en lugar del SUM vertical. 5. Dependencia fsica de las frmulas Aggregate Select: Las Frmulas Aggregate Select dependen de la insercin, actualizacin o eliminacin fsica del o los registros que involucran. EJEMPLO: Transaccin de Asientos AsiNro* AsiFch AsiTotDeb = Sum(RengImp, RengTipDH="D", 0) AsiTotHab = Sum(RengImp, RengTipDH="H", 0) (Rengid* MonCod RengInpNS RengImp RengTipDH CtaCod) Dependen de la insercin: El COUNT vertical en caso de agregar o borrar una lnea no recorre toda la tabla de nuevo a diferencia del Count Aggregate/Select. Las frmulas verticales cuentan o suman los valores que estn en "memoria". Las aggregate/select no. Diferencias entre frmulas aggregate select y frmulas verticales: 1. Las frmulas agg/sel actan sobre cualquier tabla de la base de datos y las frmulas verticales solamente sobre tablas directamente subordinadas. 2. En las frmulas agg/sel se pueden especificar condiciones de bsqueda. En las verticales no. 3. Las frmulas verticales cuentan o suman los valores que estn en memoria. Las aggregate/ select no. 4. Las frmulas verticales cuentan o suman atributos que pueden ser frmulas (pero esta frmula no puede ser agg/ sel ni involucrar en su definicin una frmula agg/sel). Los atributos mencionados en las frmulas aggregate/ select y pertenecientes a la tabla de llegada deben estar ALMACENADOS FSICAMENTE en la tabla de llegada. 5. Las frmulas agg/sel no se pueden definir como redundantes. Las verticales si.

39
COMINICACIN ENTRE OBJETOS: Comunicacin entre objetos GeneXus: Una de las caractersticas importantes de los objetos de GeneXus es poder comunicarse entre ellos o con otros programas externos. Un objeto GeneXus puede llamar o ser llamado por otro objeto, intercambiando informacin entre ellos a travs de parmetros que se declaran en cada uno. Reglas y Comandos para implementar la comunicacin: CALL UDP (User defined Procedure) UDF (User defined Function) Para implementar la comunicacin entre objetos GeneXus (y "no GeneXus", es decir programas externos) se disponen de los siguientes comandos o reglas: CALL: Llama a un objeto o programa externo, permitindose pasar parmetros si stos son necesarios. Los parmetros especificados son de entrada/salida. UDP, UDF: Se llama a un objeto GeneXus o a un programa externo, al cual se le pasarn los parmetros necesarios y retomar un valor, que es resultado de la ejecucin de dicho objeto o programa. La diferencia entre los UDP y UDF es que los programas llamados por la funcin UDF no deben abrir ninguna tabla, mientras que los llamados por la funcin UDP s lo hacen. Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 v VFP (en los dems generadores no existe diferencia entre los udp y udf), las UDF al regresar no reabren/reposicionan las tablas, por lo tanto no soportan que el programa llamado abra tablas. Por otro lado, el Call es un poco ms rpido. Las UDP restauran las tablas al volver y se usan para llamar a programas que abren tablas. Cul es la convencin usada para el nombre de los objetos GeneXus en las llamadas? Objeto Transaccin Procedimiento Reportes Work Panel Men WebPaneIs Prefijo T P R W M H El nombre se trunca a: 7 caracteres 7 caracteres 7 caracteres 7 caracteres 7 caracteres 7 caracteres

Los programas llamados con las reglas o comandos mencionados pueden ser cualquier objeto GeneXus (Transacciones, Procedimientos, etc.), o un programa externo escrito por el usuario. El nombre de dichos objetos a utilizar en la llamada (call, udp) se forma por un prefijo (identificando el tipo de objeto) seguido por el nombre del objeto truncado de acuerdo a la tabla de ms arriba. En caso de que el objeto llamado sea un programa externo, debe mencionarse el nombre del programa entre comillas; en caso de ser un objeto GeneXus va sin comillas.

40
Ejemplo: Por ejemplo, si luego del ingreso de una Factura se quiere un listado de la misma, lo que habra que poner en las Rules de la Transaccin Factura es: call(RlmpFac, FacNro) if insert .and. after(TRN); Donde ImpFac es el nombre del Report que imprime la factura recibida como parmetro. Call: Sintaxis: En regla de Transacciones: call(nom-prog, par1,...,par2) if (condicin); En layout de los reports, program source de los procedures, eventos de Work Panel y eventos de Transacciones: if (condicin) call(nom-prog, par1,...,par2) endif La regla o comando Cali ejecuta el programa 'nom-prog', donde 'nom-prog' es el nombre de un objeto GeneXus o un programa externo escrito por el usuario (segn sea el caso hay que poner o no al nombre entre comillas). El momento del disparo del cali va a depender del lugar donde se encuentra. Si el call est en las reglas de la transaccin, se va a tomar en cuenta en el rbol de evaluacin de las reglas. Si est en el layout o program source de un reporte o procedimiento, o en los eventos (tanto de transacciones como work-panels) se va a ejecutar proceduralmente en el lugar donde fue escrito. Cali - Regla Parm: La regla PARM tiene como funcin declarar los parmetros en el objeto llamado. Sintaxis: Ejemplo: Parm(atributo/ variable); call(PAltaCli, par1,... ,parn);

En las Rules de PAltaCli poner: parm(par1,..., parn); NOTA: Si en la regla parm se recibe en un atributo, se instancia el valor y no es posible cambiarlo (noaccept implcito) Con la regla PARM se declaran los parmetros que recibe un objeto GeneXus, estos parmetros son posicionales, se deben escribir en el mismo orden, la misma cantidad y el mismo tipo que los indicados en el CALL. Los parmetros especificados en la regla parm, cuando se est invocando al objeto con el CALL, son de entrada/salida.

41
Udp: Sintaxis: En reglas de Transacciones <Att|&var> = Udp(nom-prog, par1,...,parm) if (condicin); En Frmulas: <Att> = Udp(nom-prog, parl,...,pam) if (condicin); En el layout de los reportes, y en los eventos de Work Paneis o Transacciones: <&var> = Udp(nom-prog, par1,... ,pam) En el program source de un procedimiento: if (condicin) <Att|&var> = Udp(nom-prog, par1,.. .,parm) endif La Udp ejecuta el objeto o programa 'nom-prog' que retomar un valor que ser asignado a un atributo o a una variable dependiendo del caso. Udp - Regla Parm: El ltimo parmetro en la regla parm es el valor de retorno. Ejemplo: parsal = udp(PA1taCli, par1,... , parn) En las Rules de PA1taCli poner: parm(par1,..., parm, parsal); Al igual que en los programas llamados con call, en los programas llamados por UDPs se debe declarar los parmetros con la regla Parm. A diferencia con los calls, el programa llamado siempre va a tener un parmetro como mnimo (el parmetro de retomo). Ejemplo: Tenemos un procedimiento que calcula la calificacin de un funcionario: FunValCalificacion = Udp(PCalif,FunId, FunFchIngreso); En el procedimiento PCalif, tenemos la siguiente regla parm: parm( &funid, &funfching, &ValorRetorno ); Al terminar el clculo, en el program source del procedimiento se asigna a la variable &ValorRetorno el valor de la calificacin del funcionario, y dicho valor es el devuelto por la llamada y asignado al atributo FunValCalificacion.

42
Ejemplo: FacImpDesc = udp(Tcaldto, FacTot, FacCat) En procedimiento PCaldto: parm(&tot, &cat, &desc);

Parmetro de retorno Los programas llamados se pueden considerar como funciones, ya que al ser llamados utilizando UDP van a retomar un valor. Este valor que retoman es el ltimo parmetro en la regla parm del objeto llamado y no debe ser especificado en la invocacin de la UDP. En el ejemplo, se utiliza una funcin externa (por ser externa es que el nombre se pone entre comillas) para calcular el descuento dado el total de una factura y la categora del cliente. Las Udps pueden ser utilizadas en las reglas de los objetos, en las frmulas, en el program source de procedimientos, en el layout de reportes, y en los eventos de transacciones o work-panels. SUBRUTINAS: Comando SUB: Sintaxis: Sub RoutineName //cuerpo de la subrutina EndSub No se permite el pasaje de parmetros. Todas las variables del programa fuente pueden ser usadas en la rutina 'RoutineName', es decir que son globales. Disponible en Transacciones, Work Paneis, Reportes y Procedures. Comando DO: Sintaxis: Do 'RoutineName Ejecuta la rutina 'RoutineName'. Disponible en Transacciones, Work Paneis, Reportes y Procedures.

43
RBOL DE EVALUACIN Y EVENTOS:

rbol de Evaluacin: El conjunto de reglas y frmulas han sido definidas sin especificar su secuencia de ejecucin; pero en el momento de generar el programa GeneXus deber determinar esta secuencia. GeneXus determina las dependencias existentes entre estas reglas y frmulas, construyndose lgicamente un rbol de dependencia que determinar la secuencia de evaluacin. Podemos imaginar que el rbol se ejecuta de abajo hacia arriba, cada vez que cambia algn valor de un atributo, se ejecuta todo lo que depende de este atributo. Por ejemplo, si cambi la Cantidad se redispara el Importe de la lnea, y a partir de esto el SubTotal, y el Descuento y el Total y la actualizacin del Total de compras del cliente. Tambin vinculado con la cantidad est el Stock, y se disparar tambin el Subtract correspondiente. El rbol muestra claramente que debe especificarse: error(No hay Stock Suficiente') if ArtStk < 0 ; No es correcto definir: error('No hay Stock suficiente') if FctCnt > ArtStk; Esto no es correcto, pues decamos que primero se dispara el SUBTRACT y luego el ERROR, o sea que al momento de considerar el error, ya se dispar el subtract, y se disminuy el stock. Es importante mencionar que cuando se encuentra un error se desarma el rbol de Evaluacin, dejndose todo en el estado anterior a producirse el error. El error detiene cualquier actualizacin a la base de datos. El rbol es en realidad una red pero donde no pueden haber ciclos, si los hubiera en algunos casos se dispara con el valor anterior. Ejemplo: A = 1/A, se ejecuta en realidad con el valor anterior de A. A = 1 / Old(A)

44

Alteraciones del orden de disparo de las Reglas:

En la mayora de los casos el orden de ejecucin de las reglas definido por GeneXus a partir de nuestras especificaciones es el deseado. Pero en algunos casos puedo querer cambiar el momento de disparo de una Rule. Por ejemplo: En las facturas que recibimos de nuestro proveedor queremos controlar que el total que viene impreso en la factura (FctTotIng) sea correcto, por lo que lo calculamos nuevamente (FctTotCalc), y emitimos un error si no es as. Si construimos el rbol de evaluacin vemos que las dependencias entre las reglas y frmulas determinan que cada vez que cambie el importe, se cambiar el total calculado que es parte de la condicin de la regla Error. Esta condicin se va a cumplir (total calculado o total ingresado) ya para la primera lnea ingresada en la factura y se va a disparar el error en ese momento y no podr seguir adelante. En este caso la inferencia del rbol de evaluacin no me sirve, lo que quiero en realidad es que se me dispare el error cuando termine de ingresar las lneas (a la salida del nivel). Entonces le marco el evento de disparo After(level(ArtCod)) Error('EI total ingresado no coincide con el total calculado') if (FctTotCalc <> FctTotIng) .and. after(level(ArtCod)); Es importante mencionar que cuando se encuentra un error se desarma el rbol de Evaluacin, dejndose todo en el estado anterior a producirse el error. El error detiene cualquier actualizacin a la base de datos. Estos casos no son muy frecuentes, pero se dan y hay que conocerlos.

45
A continuacin se describirn cada una de estas funciones que permiten resolver casos como este, en el que el momento que GeneXus defini para ejecutar la regla no es el deseado.

// INCORRECTO Error('EI total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc; // CORRECTO Error('EI total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc .and. after(level(ArtCod)); Funciones booleanas que permiten cambiar el momento de disparo de una regla: Level( Atributo) After( Atributo ) After(Insert) After(Update) After(Delete) After(Confirm) After(Level(Atributo)) After(Tm) Inser Update Delete

Son funciones lgicas que devuelven .T. or .F. Level: Sintaxis: Level(Atributo) Retoma True o False dependiendo del nivel en que se encuentre en la estructura el atributo especificado. Ejemplo: Call(Pxxx') if Insert .and. level(CliCod); Si se mencionara un atributo como parmetro no sera necesario especificar el nivel ya que se tomara el nivel del parmetro. Ejemplo: Call(Pxxx, CliCod') if Insert ; After: Sintaxis: After(<Event>) Donde <Event> puede ser: <Att> | <Action> | Level(<Att>) | Tm | Confirm After(Attribute): Ejemplo: A=B*C if After(C); Ejecuta la regla despus de aceptar el valor del atributo C.

46
La condicin After(Att) tiene el mismo efecto que la condicin Level(Att) en el entorno AS/400, ya que la transmisin es a pantalla completa y no atributo a atributo como en PC. Insert, Update, Delete: Para condicionar el modo de disparo After(Confirm): Dispara la regla despus de haber confirmado los datos del nivel asedado pero antes de haber realizado la actualizacin. After(lnsert) After(Delete) After(Update) Se dispara despus de haber insertado, actualizado o eliminado el registro de la tabla base del nivel. Ejemplo: La siguiente transaccin llama a un procedimiento que realiza la impresin de los datos de un cliente. El procedimiento setear el atributo CliSts, para indicar que se realiz la impresin. Transaccin Clientes: CliCod* Cdigo de Cliente CliNom Nombre de Cliente Cliss Status cliente Llamadas al Procedimiento: es necesario precisar en que momento se debe disparar el llamado al procedimiento. Llamadas Incorrectas: Caso 1: Call('pficha', CliCod) if Insert .and. After(Confirm); El cliente no existe, por lo que falla la lectura. Caso 2: Call(pficha', CliCod) if Update .and. After(Confirm); El cliente ya existe, pero an no se han grabado las modificaciones. Llamadas Correctas: call('pficha', CliCod) if After(lnsert); call('pficha', CliCod) if After(Update); call('pficha', CliCod) if After(Tm); El cliente ya existe o ya se han grabado las modificaciones. After(Tm): Dispara la regla despus de procesar todos los datos de la transaccin, es decir, el primer nivel y todos los subordinados. En el AS/400 la regla es disparada despus del commit.

47
Reglas que ocurren en el mismo evento: Son disparadas en el orden en que fueron definidas Ejemplo: call(' ') if After(Tm); call(' ') if After(Tm); Ejemplo: Call(pgmname, CliCod, &flag) if After(Confirm); Error( ) if After(Confinn) .and. &flag = N; Para CALLs, ERRORs, y MSGs, cuando se marca el evento de disparo, si dos Reglas ocurren en el mismo evento y no dependen entre s, vale el orden en el cual se definieron. Ejemplo 1: Se ejecuta un Call y luego el otro Ejemplo 2: Se quiere llamar a un procedimiento que realiza determinada validacin, y que retorna en la variable &flag, el resultado (S o N). En caso de que el resultado sea negativo se quiere mostrar un mensaje de error. call(pgmname, CliCod, &flag) if After(Confirm);

error(' ') if After(Confirm) .and. &flag = 'N';

Importante: Si se invierte el orden de estas reglas, y la validacin resulta negativa, el error no se dispara. Si en vez de ser un call fuera un udp donde el campo de salida fuera &flag, s se disparara. Ejemplo de transaccin de dos niveles: Level CabFac Reglas stand-alone Trasmit Screen Evaluacin de reglas y frmulas segn rbol Confrm Screen Reglas after(confirm) Insert/Updatc/DeIcte Reglas after(insert/update/delete) Level LinFac Trasmit Screen Evaluacin de reglas y frmulas segn rbol Confinn Screen after(confirm) .and. level( <att de 2do. Nivel>) Insert/Update/Delete Reglas after(insert/update/delete) .and. level(<att de 2do. Nivel>) EndLevel after( level (<att de 2do. Nivel>)) Commit Evaluacin de reglas after (tm) EndLevel

Eventos en las Transacciones:

48

El cdigo permanece ocioso hasta que ocurre un evento al cual est relacionado Evento = Accin reconocida por un objeto y a la cual se le puede asociar un cdigo ejecutable Programacin Dirigida por Eventos: En las transacciones se permite la Programacin Dirigida por Eventos, que es un estilo de programacin en el que existe cdigo que permanece ocioso, hasta que es llamado para responder a eventos, provocados en nuestro caso por el usuario, o por el sistema. Los eventos son acciones que pueden suceder o no. Nosotros tendremos un cdigo asociado a cada evento posible, el cual se disparar slo si el evento se produce. Por ejemplo, puede haber un cdigo asociado al evento de presionar una tecla (Por ejemplo <Enter>), que se activar cuando el usuario decida presionar esa teda. La programacin dentro del evento sigue un estilo procedural. Eventos explcitos en las Transacciones: Evento Start Evento User-Event Evento AfterTrn Evento Exit Start: Es un evento del sistema y se da al comienzo del programa. Es normalmente usado para asignar valores a variables. User Defined Event: Es un evento definido por el usuario, que es activado una vez que se selecciona una opcin del men o se presiona una tecla de funcin/botn. After Tm: Es un evento del sistema y es activado una vez que la transaccin ha terminado. Es similar a la regla AFTER(TRN) usada en las transacciones. Exit: Es un evento del sistema y es activado cuando el usuario abandona el programa. Evento Start: Sintaxis: Event Start EndEvent Se ejecuta al principio del programa. Ejemplo: Guardar el inicio de ejecucin del programa Event Start &entrada=Time() EndEvent Generalmente es utilizado para la asignacin de variables y parmetros que interesa evaluar una sola vez en la ejecucin del programa.

49
Ejemplo: 1.Event Start &Mes1= 'Enero' EndEvent En el Evento Start de la transaccin de Facturas: Event Start call(PFindCli,&today, CliCod) EndEvent
Se instancia el Cliente. Se accede slo a las Facturas de ese Cliente.

2. -

Si en el Evento Start de una transaccin hay un call, los atributos que estn en el call tienen el mismo comportamiento que si se recibieran como parmetros. Es decir, que funcionan tambin como filtro (se instancia). En el ejemplo 2, al pasar como parmetro al CliCod se pueden ver slo las Facturas del CliCod pasado como parmetro. Queda instanciado el Cliente. Eventos del Usuario: Sintaxis: Event 'User-event-name' <Key> Level <att> Endevent Ejemplo: Event 'Deuda Cliente' 2 Level FacId if .not. null(CliId) call(wdeucli, CliId) endif Endevent Se ejecuta cuando el usuario presiona la tecla de funcin asociada o el botn correspondiente. Level <att> - El evento se activa slo si se encuentra en el nivel definido por el atributo. Evento After Trn: Sintaxis: Event After tm EndEvent Ejemplo: Event After tm Retum EndEvent

50
Equivalente a la funcin After(tm), pero permite agrupar todas las acciones que se deseen evaluar en el after(tm) sin tener que condicionarlas por separado (rules).

Ejemplo: Event After tm retum Endevent Abandonar el programa una vez que se ejecut un ciclo completo de la transaccin.

Evento Exit: Sintaxis: Event Exit .. EndEvent Se activa cuando el usuario abandona el programa. Ejemplo: Llamar a un procedimiento que graba la hora de entrada y salida del programa para cada usuario en una tabla de control. Event Exit &user = userid() &salida = Time() call(pcontrol', &entrada, &salida, &user) EndEvent Rules / Eventos: En caso de conflicto de evaluacin entre reglas y eventos de una transaccin, la regla se evala primero. Eventos: Event After tm . return End event Rules: call(tvenfac,FctCod) if after(tm);

sta convencin toma efecto cuando se presenta un conflicto en el momento de evaluacin de las reglas y eventos. Slo el evento after trn presenta ese caso. El evento Start no entra en conflicto con las reglas llamadas stand-alone ya que conceptualmente su evaluacin son en diferentes momentos. Las reglas stand-alone se evalan en el primer nivel antes del despliego de la pantalla. El evento Start se evala al comenzar el programa. Ejemplos de uso de Eventos en las Transacciones: 1. Desplegar el nombre de la organizacin en la pantalla al comienzo de la transaccin:

51
Event Start &0rgnom = udp(PNombre, Orgcod) Endevent 2. Imprimir una factura al presionar F7 o presionar el botn correspondiente. Event 'Imprimir Factura 7 call(RPFac, FacNro) Endevent 3. Podemos querer retomar al programa llamador una vez que la transaccin haya sido ingresada: Event After tm Retum Endevent 4. Para contar la cantidad de veces que una transaccin ha sido invocada durante una sesin, podemos programar los siguientes eventos: Event Start &Veces = 0 Endevent Event After tm &Veces = &Veces + 1 Endevent

Event Exit &Msg = 'El nmero de transacciones grabadas:' + str(&Veces) msg(&Msg) Endevent

5. Por ejemplo, supongamos que en la transaccin de facturas queremos dar la opcin de visualizar otras compras del cliente. Definimos entonces un evento del usuario: Event "Ver otras compras" 4 Call(wVerComp, CliCod) Endevent Cuando el usuario presione la tecla F4, llamaremos al work panel VerCompras' que mostrar las otras compras del cliente. Consideraciones: No se permite asignar valor a los atributos. Start-Exit Sin tabla base User Event-After(tm)> Con tabla Base Restricciones: No se permiten comandos asociados a otros eventos existentes en los work panels (load, refresh, etc.).

52

A parte de estas restricciones, hay que tener en cuenta que los momentos de evaluacin no estn asociados a modos de evaluacin activos por lo que no son vlidas tampoco las funciones asociadas a los modos activos como Insert, Update , Delete y After(Event). Para condicionar el disparo de eventos a los modos de ejecucin activos debemos utilizarlos en combinacin con reglas. Recomendaciones: Controlar mediante variables seteadas en las reglas que los eventos de usuario hagan calls en situaciones vlidas. Los eventos de usuario pueden evaluarse en cualquier momento, sin tener en cuenta el modo en que est la transaccin. Los atributos pasados como parmetros en los calls que se ejecutan en los eventos, son de entrada/salida, por lo tanto pueden cambiar su valor instancindose con el valor devuelto por el programa llamado. REPORTES Y PROCEDIMIENTOS: Reportes y Procedimientos: Reportes: Procesos no interactivos de consulta de la base de datos. Es decir, procesos no interactivos de extraccin de datos. Usualmente un reporte es un listado que se enva a la impresora, aunque tambin puede ser visualizado por pantalla. Procedimientos: Procesos no interactivos de actualizacin de la base de datos y subrutinas de uso general. Podemos decir que son un superset de los reportes, ya que pueden hacer todo lo que estos hacen y adems actualizar la base de datos. Caractersticas: Definicin Procedural: A diferencia de las transacciones donde las especificaciones se realizan en forma declarativa y GeneXus resuelve en el momento de generar el programa la secuencia de ejecucin, en los reportes las especificaciones son realizadas en forma procedural. Definicin sobre la Base de Conocimiento: La gran potencia del lenguaje de reportes/procedimientos es que las definiciones se hacen sobre la Base de Conocimiento y no directamente sobre el modelo fsico. Esto nos permite utilizar automticamente todo el conocimiento ya incorporado o generado por GeneXus a partir de las especificaciones realizadas. Por ejemplo el concepto de tabla extendida, que es posible porque GeneXus conoce las relaciones entre las tablas de la Base de Datos. Otro ejemplo claro, es el caso de los atributos frmulas, donde aprovecharemos que GeneXus sabe como calcular el valor para este atributo. Independencia de la Base de Datos, definicin a nivel de atributos: La definicin de Reportes y Procedimientos se hace a nivel de atributos, en ningn momento decimos qu tablas se deben recorrer ni qu ndices se deben utilizar, sino que esto es determinado por GeneXus en base a las especificaciones realizadas.

53
De esta manera logramos una real independencia de la base de datos, ya que en cualquier cambio en las tablas ser manejado automticamente por GeneXus. Comando For Each: Sintaxis: For Each [Order] [ Atr.. .Atr] Where <Condition> . Where <Condition> Defned by <Attribute List> . Endfor Toda la definicin del acceso a la base de datos y la estructura del reporte o procedimiento se realizan slo con este comando. El acceso a la base de datos queda especificado por los atributos que son utilizados dentro de un grupo FOR EACH - ENDFOR. Order: Lista de atributos indicando el orden de recorrida de la tabla base. Slo pueden mencionarse atributos almacenados en la tabla base. El Order es opcional, en caso de no especificarse se asume el orden de la clave primaria de la tabla base (si es que el for each no est anidado a otro for each). Eleccin del ndice: GeneXus elige automticamente el ndice a utilizar para satisfacer el orden, en caso de que no exista ninguno se crea uno en forma temporal. Where: Establecen condiciones de filtro en la recorrida de la informacin. Se pueden mencionar atributos de la tabla base y/o de la tabla extendida. Defned by: En el caso de que no se mencione ningn atributo secundario dentro del For Each, debe utilizarse esta clusula (mencionando algn atributo secundario de la tabla base que se desea recorrer) para que GeneXus pueda determinar la tabla base a utilizar. Debe quedar claro que el/los atributos mencionados en el defined by " participan" en la determinacin de la tabla base, as como tambin participan los atributos mencionados en todo el For Each. Lo que ocurre es que si se utiliza cuando realmente es necesario, entonces dichos atributos son los que determinan la tabla base. Inferencia de las tablas utilizadas en el For Each: Determinadas automticamente a travs de los atributos del grupo For Each (Order , where, defined by y cuerpo del For Each). GeneXus despus de definir los atributos que participan determina una Tabla Base y su Tabla Extendida. A partir de esto define la navegacin. GeneXus infiere la tabla base del for each, por los atributos mencionados en el order, where, defined by y en el cuerpo del for each.

Tomemos como ejemplo un reporte con la siguiente definicin:

54

En base a la definicin realizada para el reporte, GeneXus genera el programa correspondiente determinando automticamente lo siguiente: 1. Que las tablas que el programa debe utilizar en el reporte son Client y Depart. 2. Que la tabla que debe recorrerse es Client. 3. Que debe accederse a la tabla Depart para complementar la informacin (obtener DptNom). 4. Que el orden de recorrido es CliCod y que el ndice que debe usarse es el ndice IClient. Todo esto en base a una especificacin que slo incluir los atributos a listar. 1. Cmo pudo GeneXus determinar qu tablas se utilizarn en el reporte ? Para esto se debe determinar en que tablas estn los atributos que se han mencionado dentro del comando FOR EACH. Con la base de datos en 3era Forma Normal podemos definir dos conceptos, atributos primarios y secundarios: Atributo Primario: Es aquel atributo que es parte de la clave primaria de alguna tabla del modelo. El atributo puede pertenecer a varias tablas, como un atributo comn o como parte de la clave. Por ejemplo DptCod que es un atributo primario, est en las tablas de Client y Depart. Atributo Secundario: Es aquel atributo que no es parte de la clave primaria de ninguna tabla del modelo. El atributo puede pertenecer solamente a una tabla del modelo. Por ejemplo los atributos secundarios CliNom, CliDir solo estn almacenados en la tabla Client y DeptoNom solo est almacenado en la tabla Depart. Por esta razn, se puede determinar en que tabla est un atributo si es un atributo secundario. Dado que en el FOR EACH hemos mencionado atributos secundarios de dos tablas Client y Depart, stas son las que deben usarse en el reporte, con lo cual hemos respondido la interrogante planteada. 2. Cmo pudo GeneXus determinar qu tabla debe recorrer y qu otras tablas debe acceder para complementar la informacin ?

55
GeneXus ha determinado que debe recorre la tabla Client y acceder a la tabla Depart para complementar la informacin, lo que se informa en el diagrama de navegacin del reporte.

Client (CliCod) Depart (DptoCod) Esto se puede realizar porque GeneXus, utilizando la base de conocimientos, puede saber cuales son las relaciones que existen entre las tablas de la base de datos. Estamos en definitiva utilizando nuevamente los conceptos de tabla base y tabla extendida. El comando FOR EACH define una tabla base y una tabla extendida; en el ejemplo diremos que la tabla de Client es la Tabla Base del FOR EACH y Depart pertenece a la Tabla Extendida de dicha tabla base. La tabla base es en definitiva la que se recorre y la tabla extendida a la que se puede acceder para obtener otra informacin. Repasemos los conceptos de tabla base y tabla extendida: Toda tabla del modelo (tabla base), tiene informacin que le permite acceder a todas las tablas del modelo con las cuales est relacionada. La Tabla Base define su Tabla Extendida con todas las tablas que estn en una relacin de cardinalidad N para 1 con dicha tabla. Es decir que para cada instancia de la tabla base existe una nica instancia de cada tabla de la tabla extendida. Aplicando estos conceptos al ejemplo, vemos que la tabla de Clientes est en una relacin de N para 1 con la tabla de Departamentos: Clientes Departamentos

Es decir que para cada instancia de la tabla de Clientes (Tabla Base) existe solo una instancia correspondiente en la tabla de Departamentos, por lo que dicha tabla pertenece a su extendida. Por el contrario, si consideramos como tabla base a la de Departamentos, para cada instancia de esta tabla existen posiblemente varios Clientes (N) asociados. Entonces la tabla de Clientes no pertenece a la extendida de Departamentos. Es claro entonces que si mencionamos atributos de la tabla de Clientes y de la tabla de Departamentos y tomando en cuenta la relacin existente entre estas, (N para 1), la tabla elegida como tabla base ser Clientes. GeneXus puede determinar esto automticamente porque conoce la relacin entre las tablas, y puede entonces adems saber cuales son las navegaciones vlidas entre estas. 3. Qu orden y qu ndices deben utilizarse? El reporte se har ordenado por Cdigo de Cliente (CliCod) utilizando el ndice IClient. FOR EACH Client Order: CliCod ndex: IClient En la definicin del listado se asume que ser ordenado por la clave primaria de la tabla elegida como tabla base del FOR EACH.

56
GeneXus conoce los ndices de las tablas de la Base de Datos, y entonces puede elegir el ndice a utilizar para satisfacer este orden. Es posible listar en un orden diferente utilizando la palabra clave Order del FOR EACH.

When None: Ejecutar determinado cdigo, cuando en un For Each no se encuentra ningn registro. Sintaxis: For each //clientes Where (condiciones de filtro) (proceso el cliente) When none Msg("ningn cliente cumple condiciones") Endfor El Msg se ejecuta slo cuando no se entra en el For Each. Tambin se aplica a For Each [Selected] Line, XFor Each y XFor First, los cuales veremos ms adelante. Importante: Si se incluyen For Eachs dentro del When None no se infieren Joins ni filtros de ningn tipo con respecto al For each que contiene el When None ya que son considerados dos For Each paralelos. Report Wizard: Permite disear el layout de un reporte (o procedimiento) de una forma mucho ms fcil. Se define a partir de una estructura de datos muy similar a las transacciones. El diseo del layout consiste en dos pasos: 1.- Requiere de una estructura de datos en la cual hay que incluir atributos definidos en las transacciones. Dicha estructura es muy similar a la usada en las transacciones, sin embargo, los parntesis se usan para indicar niveles de For Each (en vez de niveles de una transaccin) y el asterisco (*) se usa para indicar el orden deseado (y no para indicar la unicidad como en las transacciones). Las reglas que son usadas para definir la estructura de una transaccin tambin se aplican al describir la estructura del layout.

57
Una vez que se defini correctamente la estructura, se presiona el botn de "Next" para pasar al siguiente paso. 2.- Permite definir otras caractersticas del layout. Se permite elegir los fonts para representar los atributos o textos, tambin se permite definir si los cabezales de los atributos para cada uno de los niveles se despliegan horizontalmente o verticalmente. Presionando el botn de "Finish se graban las definiciones para el paso actual y se sale del dilogo del Report Wizard. El Wizard permite que los niveles tengan o no orden. El atributo que indica el orden no tiene porqu ser el primero del nivel. Una vez que todas las opciones del Wizard fueron aceptadas, se genera el layout del reporte, el cul puede ser modificado como cualquier otro reporte. Tambin es posible editar el Wizard mediante la opcin: Edit / Report/Proc. Wizard.

Los For Each se pueden definir en forma paralela o anidada. En el ejemplo hemos definido dos for eachs paralelos. El primero recorrer todas las facturas y el segundo todos los recibos. For Each anidados: Tres Casos: Tabla Base de los For Each distintas pero relacionadas por uno o varios atributos. Tabla Base de los For Each distintas y no existe ningn atributo relacin entre las tablas extendidas de los For Each. Tabla Base de los For Each es la misma: Corte de Control. La tabla base queda determinada estudiando los atributos utilizados en el cuerpo del For Each en el caso de los For Each principales (no anidados). Para el caso de los For Each subordinados la tabla base queda establecida por los atributos utilizados en el cuerpo del For Each siempre y cuando estos atributos no estn contenidos en la tabla extendida del For Each principal. Si el conjunto de atributos utilizados en el For Each estn contenidos en la extendida ya calculada, el for each anidado tendr la misma tabla base del for

58
Each principal. Este caso se distingue en el diagrama de navegacin utilizando BREAK en lugar de For Each para todo grupo For Each subordinado que no defina una nueva tabla base. For Each Anidados (Caso 1):

Cuando se definen For Each anidados GeneXus intentar establecer que atributos en comn tienen ambas tablas extendidas (dndole prioridad a los atributos de la tabla base), y definir que estos atributos actuarn como condiciones de filtro en la recorrida de la tabla anidada. En este ejemplo, la tabla base del primer for each es la de clientes, y la del segundo, la de facturas. Ambas tablas estn relacionadas por el atributo CliCod. FOR EACH Client Order: CliCod Index: I00101 Navigation filters: Start from: First record Loop while: Not end of table Client (CliCod) FOR EACH Factur Order: CliCod Index: I00402 Navigation filters: Start from: CliCod = CliCod Loop while: CliCod = CliCod Factur (FacNro) ENDFOR END FOR For Each anidados (Caso 2): Cuando tenemos que la tabla base de los For eachs son distintas y no existe ningn atributo que las relacione, el resultado que obtenemos es el Producto Cartesiano de dichas tablas.

59
Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorre toda la tabla asociada al For Each anidado. Corte de Control (Caso 3): Procesar informacin por grupos. Ejemplo: Procesar facturas por cliente. Cada vez que cambia el cliente se define un nuevo grupo. For Each Orden CliCod (tabla Factura) orden - determina For Each corte de control (tabla Factura) EndFor EndFor Defined by, Print if detail

Corte de Control: La resolucin de este reporte puede hacerse accediendo nicamente a las facturas, recorriendo la tabla ordenada por cliente. En este caso imprimiramos solo aquellos clientes que tienen facturas. De todas maneras es necesario utilizar dos for eachs, ya que se necesita una instancia de corte, es decir un momento en el que se cambia de cliente y se puede operar en consecuencia, por ejemplo imprimir el total facturado al cliente. Lo interesante del caso dos for eachs tendrn como tabla base la tabla de facturas. Para lograr esto se puede utilizar la clusula DEFINED BY del For each o el comando PRINT IF DETAIL. En el ejemplo podramos mencionar un atributo de la tabla de facturas en el Defined by , con lo que estaramos diciendole explcitamente a GeneXus que utilizara esta tabla. Si utilizamos Print if detail debemos definirlo en el primer For Each. Se debe definir adems en el orden de recorrida del primer for each (clusula ORDER), los atributos por los que se quiere realizar el corte (en el ejemplo CLICOD). Este es un requerimiento debido a que GeneXus no podra saber cual es el criterio de agrupacin que queremos ya que en una misma tabla pueden ser varios, por ejemplo podramos querer realizar el corte de control por Fecha de factura, totalizando el total facturado cada da. Debido a esto es que la definicin de la clusula Order es necesaria. Para resumir, un corte de control queda definido de la siguiente manera: Existen dos grupos FOR EACH anidados sobre la misma Tabla Base, los atributos de corte quedan definidos por el conjunto de atributos especificados en el comando ORDER. Para hacer un corte de control, necesitamos hacer una navegacin de Facturas por Fecha. Cuando ejecutemos este reporte, generar un ndice temporal por fecha, sobre la tabla Facturas. La navegacin de un corte de control es la siguiente: FOR EACH Factur Order: CliCod Navigation filters: Start from: First record

60
Loop while: Not end of table Factur (FacNro) Client (CliCod) BREAK Factur Order: CliCod, FacNro Navigation filters: Loop while: CliCod = CliCod FacNro = FacNro Factur (FacNro) END BREAK END FOR La particularidad de esto es que el segundo For each se muestra como un BREAK. Filtros en la navegacin: Where Condition Parm(Atr... Atr) - Atributos recibidos como parmetros

Como filtrar la informacin a recuperar de la base de datos: Muchas veces es necesario filtrar la informacin a incluir en el reporte, por ejemplo supongamos que el reporte deber listar slo aquellos clientes cuyo cdigo est comprendido en un rango determinado. Para resolver esto, tenemos dos opciones: * El uso de condiciones (tem Conditions) * El uso de la clusula where en el FOR EACH La nica diferencia entre usar Conditions o la clusula Where, es que la primera es global para todos los FOR EACH que definamos en el layout y la segunda se cumple slo para el FOR EACH donde fue definida. La performance es la misma en ambos casos. Debemos escoger una de las dos opciones. La regla PARM( ): La utilizacin de atributos en la regla PARM( ) determina una condicin por igual global para todo el reporte o procedimiento. Ejemplo: PARM(CliCod). For Each [CliCod] [CliNom] Endfor El reporte slo podr acceder al cliente cuyo cdigo sea igual al recibido como parmetro.

61
Diseo de la salida:

MT [nlnea]: nlneas es el nmero de lnea en el que se quiere empezar a imprimir el listado. En caso de no especificarse un valor se asume el valor por defecto que es 0. MB [nlnea]: nlneas es el nmero de lneas que se desea dejar como margen inferior. En caso de no especificarse un valor se asume el valor por defecto que es 6. PL [nlnea]: Setea el largo de pgina. El nmero de lneas que ser impreso es el nmero especificado menos el margen de abajo (valor por defecto es 6). Ejemplo: PL 66 Setea el largo de pgina a 66 lneas, aunque slo 60 lneas sern impresas en el form, con un margen inferior de 6 lneas. CP [nlnea]: Si queda en la pgina actual un nmero de lneas mayor o igual al nmero especificado, contina imprimiendo en la misma pgina. De lo contrario, pasa a imprimir en la prxima pgina (fuerza a un salto de pgina). Lineno [nlnea]: Define el nmero de lnea donde va a ser impresa la siguiente lnea. Si el nmero de lnea actual es mayor al nmero especificado, entonces, la lnea ser impresa en la prxima pgina. Eject: Fuerza a un salto de pgina. Noskip: Tiene que estar inmediatamente despus de un printblock. Si el comando se encuentra entre dos lneas, este comando las imprimir en la misma lnea. Report Viewer: Permite: - Imprimir - Visualizar el reporte mientras se est generando - Paginado

62
- Zoom - Salvado a un archivo - Find En las preference del modelo se indica si se desea o no utilizar el report viewer. Los listados se pueden salvar a archivos, almacenndose en archivos de extensin *.gxr. Para visualizar reportes anteriores se debe invocar al Report Viewer para poder desde ste hacer un File/Open del archivo que contiene el reporte listado anteriormente. El Report Viewer se abre automticamente cuando se ejecuta cualquier reporte, o se puede ejecutarlo Standalone ejecutando el utilitario GxRView. PROCEDIMEINTOS: Insercin de registros: Ejemplo: Insercin en tabla de resumen de ventas anuales Tabla: CliCod* VtaAno* VtaTot New CliCod = &CIiCod VtaAno = &Ano VtaTot = &Total When Duplicate For each VtaTot = VtaTot + &Total Endfor EndNew New: Permite dar altas en una tabla de la base de datos. Siempre se ejecuta por clave primaria. Cuando hacemos una insercin en una tabla, GeneXus controla que no hayan claves duplicadas. Si quisiramos aplicar un tratamiento especial para estos casos, podemos usar el comando When Duplcate para decir que accin tomar cuando se detecta que el valor de la clave en un alta ya existe en la tabla correspondiente. Actualizacin: For Each Atr = <Exp> ............ Endfor

Actualiza atributo de la tabla extendida

La actualizacin se realiza en el EndFor. Los atributos actualizables dentro de un grupo For Each, son todos los pertenecientes a la tabla extendida. La actualizacin fsica se realiza cuando se encuentra el EndFor del grupo For Each correspondiente.

63

Delete: For Each defined By FacFch Delete slo Tabla Base endFor La ejecucin real del comando se produce cuando se encuentra el Delete y no cuando se llega al EndFor. La eliminacin de registros de la tabla base dentro de un grupo For Each se hace mediante el comando DELETE. Restricciones: No se realiza control de integridad referencial No Actualiza atributos definidos como redundantes En los procedimientos, el control de Integridad Referencial queda a cargo del diseador, lo que no ocurre en las transacciones. Las frmulas redundantes no se actualizan, hay que calcularlas y actualizarlas en forma manual. Consideraciones: Si no incluimos la clave primaria en el New, ese New se realiza con valor nulo de clave. Si no incluimos atributos secundarios pueden pasar dos cosas: 1. Estos quedan nulos, en caso de no estar anidado el New 2. Si el New est dentro de un For Each con la misma tabla base del New, los atributos instanciados por el For Each y no mencionados en el New son inferidos para la insercin del registro. WORK PANELS: Work Panels: Definir consultas interactivas a la base de datos. Es muy flexible por lo que se presta para mltiples usos.

Es especialmente til para usuarios que usan el computador para tomar decisiones Diferentes tipos de Paneles: - Entry Panel - Display Panel - Single Choice Selection List - Mltiple Choice Selection List - Action List

64
Las normas Common User Acces de IBM definen diversos tipos de pantallas, estandarizando los dilogos con el usuario. Entry Panel - Panel de Entrada (Paneles de Entrada):

Son paneles de entrada/salida. A travs de ellos se aceptan y se despliegan valores. Por ejemplo, un panel de entrada puede ser una pantalla previa a una impresin, donde se piden los parmetros necesarios para la misma y luego se llama a un Report. Display Panel - Panel de Salida (Paneles de Despliegue):

Son un caso particular de Paneles de Entrada, donde los datos pueden ser solamente exhibidos. Un panel de despliegue puede ser una pantalla plana o puede mostrar una cantidad variable de datos. Esto ltimo, consiste en mostrar varias lneas por pantalla permitiendo que el usuario se desplace hacia arriba y hacia abajo (scrolling). Seleccin nica/Seleccin Mltiple/Listas de Accin:

65

Listas de Seleccin de opcin nica: Una lista de seleccin de opcin nica contiene un grupo de opciones de las que los usuarios pueden seleccionar solamente una. La forma de hacer la seleccin es teclear algn valor en la lnea a ser seleccionada. Una accin puede ser entonces ejecutada sobre el contenido de la lnea seleccionada. Listas de Seleccin de opcin mltiple: Una lista de seleccin de opcin mltiple contiene un grupo de posibilidades de las que los usuarios pueden seleccionar cualquier nmero de ellas. Una lista de este tipo permite que una accin (solamente una) sea ejecutada en varias lneas simultneamente. Lista de Accin: Se pueden elegir acciones diferentes a aplicar a cada una de las lneas. Comando For Each Line: Sintaxis: For Each Line ........ EndFor

Recorre todas las lneas del dubfile

En caso de querer recorrer slo las lneas del subfle que fueron seleccionadas: For Each Selected Line . EndFor El comando For Each Line permite recorrer el Subfile (no la base de datos). Para cada una de las lneas del subfile, se ejecuta el cuerpo del For Each Line. El comando For Each Selected Line permite recorrer slo las lneas que fueron seleccionadas del Subfle. Los generadores no visuales slo permiten seleccin nica. En Visual FoxPro, no es posible seleccionar varias lneas en los grids a diferencia de Visual Basic (es una limitacin de VFP, no del generador). Programacin dirigida por Eventos: El cdigo del programa permanece ocioso hasta que se invoca su ejecucin mediante acciones tomadas por el operador del programa frente a la pantalla. Ejemplo: Event Enter Cdigo en respuesta a pulsar la tecla Enter EndEvent

66
La forma de programar los paneles de trabajo est inspirada en la programacin de los ambientes grficos, especialmente en la llamada Programacin Dirigida por Eventos (Event Driven Programming). Por Programacin Dirigida por Eventos se entiende un estilo de programacin en el cual las aplicaciones contienen cdigo que permanece ocioso hasta que es llamado para responder eventos provocados por el usuario o por el sistema. Los Work-PaneIs se definirn entonces de una manera menos procedural que en la programacin clsica, y orientada a eventos. Los eventos son acciones que pueden suceder o no. Tendremos un cdigo asociado a cada evento posible, el cual se disparar slo si l evento se produce. Eventos: Start Refresh Load Enter User-defined Exit Evento Start: Es un evento del sistema, ocurre cuando se comienza a ejecutar el work panel. Es usado comnmente para asignar valores a variables, generalmente para dar valores por defecto a las variables del rea fija de la pantalla. 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 botn refresh cuyo efecto es cargar nuevamente el subfle. Comando Refresh: En algunos casos, desde otro evento tambin puede ser necesario cargar nuevamente el subfile. Por ejemplo cuando en un evento se llama a una transaccin que actualiza los datos (Ejemplo "Ingresar" (F6)) que se estn desplegando en el subfile, lo que se hace entonces es ejecutar el comando refresh luego del call a la transaccin. Tambin se necesita hacer un refresh cuando una variable que aparece en las Conditions es modificada por el usuario. Estas variables determinan qu datos se cargarn en el subfile, si una condicin cambia, el subfle debe ser cargado nuevamente. Evento Load: Es un evento del sistema que ocurre cuando un subfile est siendo cargado. Para cada registro que se cargar en l, se disparar este evento. Este evento es usado generalmente para cargar variables en el subfile. Los valores de estas variables pueden ser calculados o ledos de la base de datos usando el comando For Each. Se puede hacer referencia a cualquier atributo que pertenezca a la tabla extendida asociada al panel de trabajo. Evento Enter: Este evento ocurre cuando el usuario presiona Enter. Evento Exit: Este evento ocurre despus que el usuario presion la tecla de salida (ESC o F12), o el comando "return" es ejecutado en cualquier evento. User Defned Event: Se pueden definir eventos del usuario, los que pueden estar asociados a una tecla de funcin o a un botn. De esta manera el evento ocurre cuando el operador presiona la tecla de funcin o el botn asociado al evento.

67

Reglas ms importantes: Order Noaccept Search Hidden Workfile_lines Order: Define cul es el orden de los datos en el subfile. Es equivalente a la clusula ORDER del For Each y se aplica todo lo dicho en la seccin de Reportes sobre el tema (incluida la creacin de ndices temporales). Por ejemplo, si quisiramos ver los clientes ordenados por nombre: Order(CliNom); Noaccept: A diferencia de las Transacciones, en los paneles de trabajo ningn 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 lnea determinada del mismo, en forma directa, sin tener que avanzar pgina por pgina. Por ejemplo, para buscar un cliente por su nombre se debe definir la regla: Search(CliNom >= &Nom); Hidden: En los paneles, GeneXus infiere automticamente cuales son los atributos y variables que debe incluir en el subfile. Esta regla es usada para indicarle explcitamente a GeneXus cuales atributos o variables debe incluir en el subfile sin estar presentes en el mismo. Se usa cundo por razones de presentacin, no es conveniente mostrar un atributo en el rea de subfile de la pantalla, pero se quiere capturar su valor cuando se haga el load de la misma.

68
Workfile_lines (<MaxLine>): Dado que los subfiles se cargan en archivos temporales y que no existe un lmite en la cantidad de lneas a cargar en ellos en PC o LAN , puede traer problemas si la tabla base asociada tiene muchos registros ya que el archivo temporal tendra todos los registros de la tabla base. Usando esta regla, se menciona en MaxLine la mxima cantidad de lneas que se permite cargar en el subfile. Si el lmite especificado se excede, se despliega el siguiente mensaje Nmero de lneas excede xxxx ". Propiedades ms importantes: Loading Load Records Load at Startup Automatic Refresh Refresh Timeout (FoxPro only)

Load Records: Los posibles valores son 'Load on request' o 'Load all records'. Load on request: A medida que se va paginando va cargando los registros del subfile ('Carga a pedido'). Load all records: Carga todos los registros. Load at Startup: Los valores posibles son 'Yes' o 'No'. Yes: Inmediatamente despus de ejecutar el Workpanel se carga el subfile. No: No carga el subfile de un panel hasta que no se ingresen los valores de la parte fija del WorkPanel. Automatic Refresh: Esta property es especialmente til en el caso de un subfile con slo variables, cuando uno desea que se haga automticamente un refresh cada vez que uno de los valores de la parte fija son modificados. Los valores posibles 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. Refresh Timeout: Esta property es para que se haga un refresh del subfilo automticamente si el usuario no efectu ninguna operacin en el lapso de tiempo especificado. No hay valores predefinidos. Debe especificarse un valor en segundos (lapso de tiempo). Work-Panel con o sin Tabla Base ? Los atributos que determinan la tabla base y su extendida son los definidos en: Panel Reglas Hidden y Order Eventos (fuera de comandos For Each) Work Panel sin tabla base comando LOAD

Work -Panel con tabla base: En la navegacin:

69
For Each [Tabla Base] Order: Atributos del ndice por clave Primaria (si no se incluy regla order) Index: Clave primaria (si no se incluy regla Order) // Otros For Eachs definidos en los eventos Endfor Work -Panel sin tabla base: No se mencionan atributos en: Panel Reglas Hidden( ) y Order( ) Eventos En este caso se genera slo un Evento Load, y es en l donde se deben cargar los datos en el subfile, haciendo for each a la (s) tabla(s) deseadas cargando las variables del form. Dilogo Modal/No Modal: Property Modal dialog - En transacciones y work panels (llamados). Opciones: - Yes if parameters specified - Yes - No Slo generadores Visuales. La property Modal Dialog permite elegir si el dilogo ser modal o no modal para ese objeto. Las opciones de esta property son: Yes if parameters specified: Es la opcin por defecto. Significa que si el objeto tiene parmetros, el dilogo ser modal y si no tiene el dilogo ser no modal. Yes: Dialogo modal. No: Dialogo no modal SUBTIPOS:

70
Hay que definir el banco origen y destino en la misma transaccin. Esto no es correcto pues tengo que poner atributos con el mismo nombre en la misma transaccin. Para estos casos GeneXus provee los Subtipos, los cuales permiten definir que dos atributos que se llaman diferente, corresponden al mismo concepto.

Hay que definir atributos con distinto nombre y que tengan una dependencia funcional. Los atributos que se encuentran en una relacin Subtipo/Supertipo siempre comparten la misma definicin. Se realizan los controles de integridad referencial. La tabla extendida que se obtiene con la definicin del subtipo, es la misma que se obtendra en el caso que se utilizara directamente el supertipo.

71

Todava queda algo por determinar. Tenemos dos bancos y dos nombres pero en ningn lugar indicamos el nombre a que banco corresponde. Es ac donde aparece la necesidad de definir grupos. Decimos que el Cdigo de Banco Origen y el Nombre pertenecen al mismo Grupo. Algunas Consideraciones: El subtipo y supertipo sern definidos del mismo tipo, GeneXus lo determina as y cuando se quiere definir un subtipo este "hereda" la definicin del supertipo. No incluir subtipo y supertipo en la misma transaccin, ni tampoco en la misma tabla extendida. No se pueden actualizar los subtipos inferidos (Add, Subtract). No se pueden definir redundantes los subtipos inferidos. Por ejemplo: TraBcoOriNom DATA VIEWS: DataViews - Archivos Externos: Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran Archivos pertenecientes a la Base de Conocimiento. Propiedades: Definicin Global Uniformizacin de la nomenclatura Para trabajar con Archivos Extemos en GeneXus tenemos dos posibilidades: Sin tabla Asociada Con tabla Asociada

72

Los Data Views de GeneXus permiten manejar Archivos Externos como si fueran archivos pertenecientes a la Base de Conocimiento. En el Data View se puede indicar que se manejar una transaccin interna asociada, o no. Data View con transaccin interna asociada: Supongamos que desde una Base de Conocimiento se desea manejar el archivo externo clientes.dbf cuyos campos son: - Cdigo* - Nombre - Dir - Tel 1) Se debe crear una transaccin de clientes definiendo los atributos que se deseen manejar de la tabla externa. Estos atributos internos deben coincidir en lo que se refiere a tipos y tamaos con los campos externos, pero los nombres pueden ser redefinidos respetando la nomenclatura GIK. 2) Se debe crear un Data View e indicar en l, cual es la transaccin interna asociada. Asimismo se deben indicar las correspondencias entre los atributos internos y los campos externos. Tambin se debe ingresar en el Data View, informacin relacionada al Archivo Externo como ser la plataforma y ubicacin (esto debe ser indicado tanto en el caso que el Data View tenga una transaccin interna asociada, o no). 3) Los objetos GeneXus deben definirse haciendo referencia a los atributos internos de los clientes, sin embargo los programas son generados utilizando los campos externos en forma transparente. Nota: Si bien se define una transaccin de clientes, esta no provoca la creacin de una tabla fsica por estar asociada a un DataView. Esta transaccin se especifica y genera como cualquier objeto de la Base de Conocimiento y en ejecucin, accede en forma interactiva a los registros de la tabla externa en forma transparente. Data View sin transaccin interna asociada: En este caso, se debe crear un Data View, sin crear previamente una transaccin interna. La forma de acceder al Archivo Externo es nicamente mediante la definicin de procesos batch utilizando los External File Commands: XFOR EACH, XNEW, etc. Definicin de un Data View:

Assoc. table: En este punto se debe seleccionar la tabla interna asociada al Data View.

73
Composition: Aqu se deben indicar las correspondencias entre los atributos internos y los campos externos. [Nombre Interno] [Nombre Interno] [Nombre Interno] [Nombre Externo] [Nombre Externo] [Nombre Externo]

Cuando no se menciona el Nombre Externo es porque coincide con el Nombre Interno. En el ejemplo, el nombre y la direccin del cliente en el Archivo Externo se llaman CliNom y CliDir respectivamente. Indices: En esta lista, se deben definir los ndices internos que GeneXus usar en la aplicacin. Plataform Specific Information: Aqu se debe completar informacin del archivo externo (como ser la plataforma y ubicacin).

Indices:

74
Name: Nombre del ndice que GeneXus usar en la aplicacin. Unique o Duplcate: Si permite tener o no llave duplicada. Compositions: Es la lista "ordenada" de campos que componen al ndice. Los atributos mencionados ac deben ser parte de la Composition del Data View. Platform Specific Information / Add:

Las propiedades del Data View pueden definirse para cada plataforma o por modelo. Esto nos brinda la posibilidad de especificar diferentes ubicaciones del mismo Data View dentro de la misma plataforma pero para diferentes modelos. Por ejemplo, si se quiere darle diferente ubicacin para el modelo de Prototipo Fox y para el modelo de Produccin Fox, debe seleccionarse DBFCDX(model2) y DBFCDX(model 3) indicando la ubicacin para cada uno de los modelos. En cambio, si se quiere la misma ubicacin para todos los modelos Fox debe seleccionarse la plataforma DBFCDX. Platform Specific Information / Edit:

75
Estas propiedades varan dependiendo de la plataforma seleccionada. En este caso, por ejemplo, el archivo externo es un archivo de texto y por tanto las propiedades son referenciales a un archivo de este tipo. Associated Table:

Data View con Tabla Interna Asociada: Se trata al archivo externo como una tabla ms del modelo. Se pueden utilizar los mismos comandos utilizados para acceder a las Tablas Internas (For Each, etc.) Se deben mencionar los atributos internos y Genexus al generar los programas, utilizar los campos externos de forma transparente.

Existe una relacin de uno a uno entre los atributos de la Tabla Interna del Data View y los del Archivo Externo.

76

Los atributos definidos para la Tabla Interna y para el Data View. Estos atributos no pueden ser asociados.

Si la Tabla Interna tiene ms atributos que el Archivo Externo no es vlida la asociacin.

En el ejemplo, se pide tener tambin como datos del cliente el E-Mail y la direccin.

77
Asociacin Dinmica: Las definiciones del Archivo Externo e ndices asociados coinciden con las definiciones de la Tabla Interna y sus ndices (tanto en nombres como en la composicin). En este caso coincide todo. Si ocurre esto no hay que detallar composicin ni de ndices del Data View. Lo nico que hay que hacer es asociar el Data View a la tabla externa (Platform Specific Information). Tener en cuenta que el ndice y archivo externo deben estar ubicados en el mismo directorio.

Reorganizaciones Data Views: 1. EXISTE TABLA ASOCIADA Si cambia la estructura de la tabla asociada, el cambio es detectado en el Anlisis de Impacto. No se generan programas de reorganizacin. 2. NO EXISTE TABLA ASOCIADA No aparece en el anlisis de impacto. EFICIENCIA Y PERFORMANCE DE LAS APLICACIONES:

Puntos a Considerar: Optimizacin de la Entrada-Salida Uso de Calls Open y Close de archivos Uso de ndices Temporales Optimizacin de Entrada-Salida: Dado que el acceso a las tablas es costoso, vamos a ver cmo minimizarlo.

78
Uso de Calls: Vamos a ver cundo debemos empezar a preocupamos por el uso de este comando. Open y Close de archivos: Cunto y cmo influyen las operaciones de apertura y cierre de archivos en el tiempo de respuesta de nuestra aplicacin. Uso de ndices temporales: Evaluacin del costo de creacin de ndices temporales vs. el costo de mantenimiento de ndices permanentes.

Normalmente los programas procesan registros agrupando aquellos que tengan ciertas caractersticas comunes, por ejemplo, todas las facturas de un determinado cliente, o las ventas de una clase de artculos. Estas caractersticas comunes, se establecen a travs de condiciones que determinan un filtro sobre los registros. Tales condiciones se especifican en GeneXus de diversas formas; as pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en una formula Aggregate/Select, parmetros, etc. Ejemplo: De todos los Clientes, quiero imprimir los datos de aquellos cuyo cdigo este en un rango determinado. El tiempo necesario para realizar el proceso con los registros que cumplen las condiciones, determina el grado de "Optimizacin" que tiene la estrategia de acceso elegida. Decimos que una estrategia de acceso esta ms "optimizada" que otra, cuando es necesario un menor tiempo para leer todos los registros que cumplen las condiciones establecidas. La Optimizacin consiste en posicionarse lo ms cerca posible del primer registro del grupo que cumple las condiciones y desde all leer secuencialmente hasta el ltimo que las cumpla. Lo que se establece en definitiva, es un intervalo que cubre todos los registros que cumplen las condiciones. En este intervalo no necesariamente todos los registros cumplen la condicin. En estos casos, la mejor estrategia consiste en tener el menor intervalo tal que cubra a todos los registros que

79
cumplirn la condicin. Igualmente las lecturas se realizarn para todos los registros de este intervalo, pero solamente se considerarn aquellos que cumplan con las condiciones. Definicin de Filtros: Clusula Where en For Each Conditions en Prcs, Rpts, Wkps. Parm( ) en Trns, Prcs, Rpts, Wkps

Where: La clusula "Where" permite filtrar registros en la navegacin de un determinado grupo FOR EACH. Por ejemplo: Para establecer los filtros descritos anteriormente, utilizaramos la siguiente especificacin: FOR EACH WHERE CliCiu = 'Montevideo' .AND. CliCod >= 1 .AND. CliCod<= 100 ENDFOR Conditions: Las "Conditions" sirven para establecer un filtro en forma global, es decir que solamente se podr acceder a los registros que cumplan con esta condicin. Cuando se establece una condicin sobre atributos, afecta a todos los grupos FOR EACH que contengan ese atributo. Reports, Work-panel y Procedures poseen esta posibilidad. Se preveen la implementacin a nivel de Transacciones en prximas versiones. Parmetros: Es otra forma de establecer una condicin en forma global, pero solamente por igualdad. Cuando se recibe un parmetro en un atributo, obtenemos una especificacin equivalente a una condicin, por ejemplo: Tenemos un procedimiento que tiene la siguiente regla: Parm(ChCod); Esta regla es equivalente a tener: parm(&Cliente), y la condicin: CliCod = &Cliente; Definicin de la estrategia de acceso: 1.2.3.4.Se define el orden en que se recorrer el archivo. Se elige el punto de comienzo (Starting point). Elegir la posicin final (End Point). Leer secuencialmente los registros entre el punto inicial y el punto final, seleccionando los registros que cumplen las condiciones y descartando los restantes.

Definicin de la estrategia de acceso con GeneXus: Para definir una buena estrategia de acceso, GeneXus cuenta con una inteligencia razonable. A continuacin se explica cmo se decide la estrategia a partir de las especificaciones realizadas. Se determinar, estableciendo ( de acuerdo a las condiciones y el orden en que deban considerarse los registros), una posicin inicial y una posicin final en el archivo, leyendo en forma secuencial en este intervalo.

80
Se realizar entonces lo siguiente: 1. Determinar el orden de recorrida del archivo. 2. Fijar la posicin de comienzo (Start). Posicionarse lo ms cerca posible del primer registro que cumple las condiciones. 3. Leer secuencialmente, descartando los registros que no cumplan las condiciones, hasta alcanzar la posicin de fin. 4. Fijar la posicin de fin (End). Se dice de aquellas condiciones, tales que a partir del primer registro que no las cumple, no existen ms registros que s la cumplan. Orden de Recorrida: Importancia del Orden en que se leen los registros. Ejemplo: Condiciones de Filtro compatibles con el Orden For each Order CliCod Where CliCod >= &IniCod .and. CliCod &FinCod Endfor Cod 1 *2 *3 *4 5 Nombre Smith Jones Ball King Ander

Starting Point Ending Point

Read Read Read

&IniCod = 2 &FinCod = 4

El orden en que deban considerarse los registros, junto con las condiciones de "filtro" determinarn la mejor estrategia de acceso. El orden puede considerarse como una condicin previa, para la definicin de la Optimizacin de las condiciones de filtro. Es decir, que la estrategia de acceso se define, tomando en cuenta como primera cosa el orden que se haya definido. Ejemplo: Condiciones de Filtro no compatibles con el Orden

For each Order CliCod Where CliCod <= &IniCod .and. CliCod &FinCod Endfor Cod Nombre Starting Point Read Read Read Read Read Read &CodIni = 2 &CodFin = 4

*3 Ander 5 Ball 6 Churchill 1 King *4 Smith *2 William

Ending Point

81
Si no se define un Orden se elige el de la Primary Key Ejemplo: Nombre inicial: &IniNom Nombre final: &FinNom

For each Where Clinom >= &IniNom .and. Clinom <= &FinNom Endfor Orden elegido CliCod

Cuando no se define un orden: Se debe tener en cuenta que el no especificar un orden, no implica que GeneXus lo elegir de forma que optimice las condiciones definidas. Sino que se tomar el orden de la clave primaria y en base a este orden se optimizarn las condiciones que sean posibles. Excepcin: Existe un caso en el que se puede elegir un ndice diferente al de la clave primaria, y es en el de anidamiento de FOR EACHs, cuando existe una relacin entre atributos primarios de los mismos. En este caso el FOR EACH anidado elegir el orden de acuerdo a las condiciones de filtro establecidas por su relacin con FOR EACHs anteriores. Ejemplo: Clientes CliCod* CliNom TypCod Tipos TypCod* TypNom

Tenemos Clientes y Tipos de clientes, y queremos listar los tipos de clientes y los clientes de cada tipo, haremos la siguiente especificacin: For each [TypCod] [TypNom] For each [CliCod] [CliNom] Endfor Endfor Como primera cosa, GeneXus infiere que los clientes que queremos recorrer son aquellos del tipo (TypCod) que acabamos de considerar en el FOR EACH anterior. Es decir, que hay una condicin implcita que indica que: Tipos. TypCod =Cliente.TypCod Esto ocurre cuando se tienen FOR EACHs anidados, cuyas tablas bases tienen alguna relacin; GeneXus la encuentra y determina en forma automtica una condicinde filtro. Esta relacin slo puede establecerse entre atributos primarios (aquellos que forman parte de la clave primaria de alguna tabla), ya que es el nico caso en que un atributo puede estar en ms de una tabla. Esta condicin (Tipos.TypCod = Cliente.TypCod) establecida en el for each de clientes, slo es optimizable si el orden es TypCod. Pero decamos que el no especificar ningn orden implica que el orden a tomar es el de la clave primaria (CliCod), por lo que no sera posible entonces la optimizacin.Pero en este caso, como nica excepcin, se elige el orden que permita optimizar la condicin de filtro. Posicin de Comienzo: (Consideraciones para su definicin): Se consideran las condiciones compatibles con el orden y que sean por: Si el orden es ascendente Mayor (>) Mayor o Igual (>=)

82
Igual (=) Si el orden es descendente Menor (<) Menor o Igual (<=) Igual (=)

Las condiciones deben estar relacionadas por .And. Ejemplos: Orden: ABC Condiciones: A>= 5 .and. C > 3 Posicin de comienzo: A>=5 Orden: ABC Condiciones: A > 5 .and. B < 2 .AND. C>3 Posicin de comienzo: A > 5 La Posicin Final (Consideraciones para su definicin): Se consideran las condiciones por: Si el orden es ascendente Menor (<) Menor o Igual (<=) Igual (=) Si el orden es descendente Mayor (>) Mayor o Igual (>=) Igual (=) Las condiciones deben estar relacionadas por .And. Diagrama de Navegacin: Ejemplo: Diagrma de navegacin: For each CliCod Where CliCod >= &lniCli .AND. CliCod <= &EndCli [CliCod ] [CliNom ] Endfor FOR EACH clientes Order: CliCod Index: ICliente Navigaton filters: Start from: CliCod >= &IniCli Loop While CliCod <= &EndCli Constraints: CliCod >= &IniCli .AND. CliCod <= &EndCli CLIENTES (CliCod) END FOR

83
Ejemplo: Diagrma de navegacin: For each CliCod [CliCod ] [CliNom Endfor

FOR EACH clientes Order: CliCod Index: ICliente Navigaton filters: Start from: First record Loop While Not end of table CLIENTES (CliCod) END FOR Tambin influyen en la performance: Calls Apertura y Cierre de Archivos Uso de ndices Temporales Calls: En qu casos deberamos considerar el costo de la ejecucin de un Call? En la gran mayora de los casos no es necesario que nos preocupemos por esto. Sin embargo en algn caso eliminar "Calls" puede significar la diferencia entre una buena y una mala performance (ya que no tiene el mismo costo que hacerlo todo en un nico programa que en varios). Generalmente, stos comienzan a ser un problema cuando lo que se tiene no es una nica llamada a otro programa sino que son varias. En C/S, el tiempo de un call no es considerable ya que se van abriendo cursores sin preocuparse de cerrarlos hasta el final de la ejecucin de la aplicacin o si no si se lleg al lmite de cursores para usar, los que ya fueron usados, son marcados como borrables, a fin de cerrarlos slo si es necesario, si se vuelven a utilizar la definicin ya est, por lo que el tiempo de creacin disminuye. En File/Server, se cierran o abren los ndices dependiendo de los ndices utilizados. En NTX e IDX, si es necesario usar un ndice que esta abierto, primero se cierra y luego se vuelve a abrir. Si es CDX, no cierra el ndice sino que se reposiciona usando el mismo.

Ejemplo: Para cada cuenta, que cumpla las condiciones se llama a otro programa. Supongamos que las cuentas en las condiciones establecidas son 10.000, entonces se realizarn 10.000 "Calls", lo que seguramente tendr una costo importante en el tiempo total del proceso. For each Cuenta Where Cuenta > &cta Call('Pvalida, ...) Endfor En el AS/400 las funciones resueltas con Calls en los programas generados son: Time( ), Today( ) (se ejecuta una vez por programa), Cdow( ), Cmonth( ), Userid( ), UsercIs( ), Wrkstn( ). Los calls en XBASE no tienen en s mismos un gran costo, pero pueden generar cierres y reaperturas de tablas que s importan. Se implementaron dos esquemas distintos de calls (entendiendo por Call: el call propiamente dicho y las UDP y UDF ), los que dependen del tipo de ndice que se est utilizando.

84
Indices NTX/IDX/NDX a) Cuando el Objeto llamado no utiliza ninguna tabla abierta por el objeto llamador: En este caso el objeto llamador (X) no cierra ninguna de las tablas que utiliza para realizar el llamado (call) , y el objeto llamado (Y) abre y cierra nicamente las tablas que utiliza. b) Cuando el Objeto llamado (Obj.Y), utiliza alguna tabla abierta por el objeto llamador. En las llamadas (calls) a otros objetos, el programa llamado cierra las tablas que necesita, que hayan sido abiertas por el programa llamador y las abre con los ndices que deba utilizar. Antes de retomar, el programa llamado cierra todas las tablas que us. El programa llamador, despus de retomar del programa llamado, abre aquellas tablas que necesita y fueron cerradas por el programa llamado. Resumiendo: El llamado siempre cierra lo que usa y el llamador se tiene que preocupar de reabrir lo que corresponda, el peor caso es cuando los dos usan las mismas tablas y el mejor es cuando usan todas distintas. a) PgmaX Open A, B, C Call Y Close A, B, C Open B Close A, B, C Indices CDX En este caso, en los objetos llamados, no se cierran las tablas que haban sido abiertas en los objetos llamadores y solamente reabren los ndices de la forma que los necesita. PgmaX Open A, B, C ....... Call Y Restaura todo a como estaba antes del call ....... Cise A, B, C PgmaY Open D, E Reposiciona Indices B, C Close D, E Pama Y OpenD, E .... Close D, E b) Pgma X OpenA, B, C Call Y Pgm Y OpenD, E Close B y Open B . Close B, D, E

ndices Temporales: En Client/Server los ndices temporales se construyen ms rpidamente que en File/Server, ya que solo se indexarn los registros que cumplan las condiciones y no requiere un uso exclusivo de la tabla. En File/Server, se construye el ndice para la ejecucin del programa y luego se borran. El tiempo de creacin es considerable dependiendo del nmero de registros de la tabla y de la cantidad y largo de los campos. En el AS/400 se usa la instruccin OPNQRYF para definir ndices temporales. Dependiendo de todo eso es que conviene o no crearse un ndice de usuario.

85
MULTIPLES FORMS: Mltiples Forms por Objeto: Poder tener N pantallas por objeto. Permitir dentro de una misma KB tener modelos en los que se genera para ambiente grfico y otros en los que se genera para ambiente caracteres. Form Classes:

Crate automatically in new objects: Significa que cada vez que se crea un nuevo objeto, automticamente se crea un form de esa clase en el mismo. Cuando se importa, se genera automticamente un form para cada clase que sea Autocreate. Puede haber una o ms classes Autocreate. Crate Reports and Procedures using "Form que se seleccione": Como en reports y procedures no hay multi-form, se elige entre el Graphic y Text. New Class: Classes definidas por el usuario que pueden ser tanto Graphic como Text. Mltiples Forms por Objeto: Form Classes - Graphic y Text (son del sistema) - Definidas por el usuario (modo texto o grfico) Cada objeto tiene forms que pertenecen a alguna de las form classes y cada Modelo tiene asociado una lista de Form Classes para cada generador del mismo. - Opcin: File/ Edit Model/ Model Forms Las Form Classes y sus propiedades son globales a la KB (File/Form Classes), pero se pueden editar desde cualquier modelo. A su vez, en cada modelo se puede definir una lista de form classes de preferencia (File/Edit Model/Model Forms) para cada generador del modelo.

86
El default de un form puede ser en base a otro form o en base al default de Genexus. Cundo decide GX el form a utilizar? En tiempo de Especificacin Apertura del objeto Apertura del objeto: para decidir cual mostrar en forma inicial. La lista de forms del modelo se tiene en cuenta en 2 casos: 1.- Al especificar un objeto, para decidir cul form considerar para cada objeto, se toma la primer form class de la lista del modelo y se busca si existe en el objeto un form de esa clase. Si no existe, se busca de la form class que sigue en la lista y as hasta encontrar o que se acabe la lista. Si se acaba la lista y no se encontr, entonces de acuerdo al generador (grfico o de caracteres) se busca un form que sea de ese tipo, si tampoco se encuentra entonces se especifica cualquiera y en el caso que haya que convertir, se convierte a texto. En cualquier caso, en el reporte de la especificacin aparece cul fue la form class que se eligi para cada objeto. 2.- Al abrir el objeto, para decidir cul mostrar en forma inicial STYLES: Propiedades de los Styles: Permiten la definicin de standards. La definicin es "por tipo" de objetos (transacciones, work paneis, etc). Objeto GeneXus no tenido en cuenta al normalizar. Los Styles son otro objeto GeneXus, su forma de definir es similar a la de los otros objetos, pero con la particularidad de que NO son tenidos en cuenta en la normalizacin o generacin de programas. Slo se utilizan para definir standards, sin la necesidad de tener que disear Form por Form. Pueden ser modificados, y automticamente se reactualizan los forms necesarios. Hay Styies para transacciones, work panels, etc., pero un style es de un solo tipo. Las excepciones a esta regla son los Styles de Work Panels que sirven tambin para Prompts y los Styles de Report y Procedure que pueden usarse para cualquiera de los dos. Nota: No existen Styles de Styles Definicin de un Style:

Object/New Object. Ejemplo de un Style de transaccin.

87

Style:

Se ven en los forms unas lneas que definen diferentes reas. Lo que est dentro del rectngulo es la denominada "Data rea" (rea de datos). El resto del form es la "Style rea". A su vez, la Style rea est dividida en 8 sectores (ver figura). Cuando el desarrollador empiece a usar styles las lineas de la data rea aparecern solas. De todas maneras tambin se pueden hacer aparecer con un botn de la toolbar. Los controles que estn completamente comprendidos en un sector conservan su posicin relativa a ste, cuando se mueven las lneas. Aquellos controles que pasan desde un lado de una lnea hacia el otro, conservan su posicin relativa a la lnea (se mueven junto con la lnea). Si un control pasa por encima de 2 lneas paralelas (o dicho de otra manera, comienza antes de la lnea de borde izquierdo de la data rea y termina despus de la lnea del borde derecho, o bien la misma situacin con respecto a los bordes superior e inferior), pueden suceder dos cosas: A) Es un control con "autoresize". En este caso, el control mantiene su posicin relativa a la primera de las lneas que cruza.

88
B) Es un control sin "autoresize". El control se agranda o se achica tanto como se separen o acerquen las lneas, manteniendo cada uno de los extremos del control su posicin relativa a la lnea ms cercana.

Tres Tipos de Controles: Controles que vienen de la default Data rea Los que vienen del Style Controles del Usuario - Los que agrega el usuario al objeto. - Los que vienen de la data rea del Style. Los controles en la Data rea del style se pasan al objeto slo en caso de inicializacin (cuando el objeto es creado basado en el style y no en futuras reaplicaciones) y una vez en el objeto es considerado como un control de usuario dentro de ste. Creacin de un objeto basado en un Style: Al momento de crear el objeto, en el Information/StyIe se elige el Style deseado. Relacin entre las partes del objeto y del Style: - Form y Properties: Relacin dinmica - Otras partes del objeto: Relacin esttica Dinamismo con las properties - Los objetos heredan las propiedades del style asociado - El dinamismo es "por property" Cuando se crea un objeto con un Style asociado, el objeto se inicializa con todas las partes del Style (a excepcin del Information, obviamente). Excepto para el Form y las properties, la relacin entre las partes del objeto y del Style es esttica (si se cambia el Style no se cambia el objeto). Pero tanto para el Form como para las properties puede ser dinmica (que por ejemplo, cuando se cambie el Form del Style se cambie el form del objeto). En el caso de las properties, el dinamismo se mantiene en forma independiente para cada property. Cuando el objeto es creado sin especificar un Style asociado, GeneXus considera de todas maneras para el form la asociacin a un Form Style Default. Es decir que aunque el objeto no tenga Style asociado, a los efectos del form es como si estuviera asociado a un Style Default. Cuando se crea un objeto, se tiene Syle dinmico, pero dinamismo con la default data rea slo si el objeto es una transaccin. En las prximas transparencias veremos cmo es que se pierde el dinamismo. El estado de dinamismo se puede ver por el color con el que estn dibujadas las lneas. Si son rojas, est dinmico. Si no est dinmico, son azules.

89

Las lneas de la data rea estn en azul indicando que se perdi el dinamismo con la default data rea. Las lineas de la style rea estn en rojo indicando que existe dinamismo entre la style rea de la transaccin de clientes y la styie rea del style. NOTA: Se puede perder el dinamismo con la style rea del Style y seguir teniendo dinamismo con las properties del Style (siendo esto ltimo "por property"; es decir, teniendo dinamismo con algunas properties y no con todas). Cmo asociar Styles a objetos existentes: Opciones - Information/StyIe - Reapply Form Style Cuando se crea un objeto nuevo con un Style asociado, el objeto es inicializado con todas las partes del Style. Cuando el objeto ya existe, y se le asocia un Style, lo nico que hereda de ste es el Form y las Properties (slo las properties que tienen en el objeto los valores por default), siendo el dinamismo de las properties "por property" (se respetan las otras partes del objeto: Event, Rules, etc.). En otras palabras, es til asociar un Styie a un objeto existente cuando se quiere utilizar slo los Form del Style y las properties del Style en el objeto. Para asociar un Style (o cambiar el Style asociado) a un objeto ya existente se debe editar la "Information" del mismo, seleccionando alli el Style deseado. Para aplicar el Style a cualquiera de los forms del objeto se usa el men Edit / Reapply Form Style. Antes de aplicar el Style, hay que tener en cuenta que aquellos controles que no provenan del Style asociado anteriormente (controles del usuario), permanecern en el form del objeto, con lo que pueden ocurrir superposiciones. Qu pasa con el dinamismo ? Cuando se pierde? - Cuando se modifican los controles que vienen de la DDA los controles que vienen de la "styie rea" del Style

90
el seteo de una property Opciones: - Edit \ Default Data rea - Edit \ Reapply Styie Form Si se modifica un control que figura en el form como resultado del clculo de la Default Data rea (control que viene de la DDA), se pierde el dinamismo en sta (por ej.: si en una transaccin se modific uno de los controles correspondientes a los atributos de la estructura, al agregar nuevos atributos en la misma no aparecern automticamente en la Data rea). Anlogamente, si se modifica cualquiera de los controles que vienen de la styie rea del Style, se pierde el dinamismo con el Style. Si se modifica el valor de una property en el objeto, entonces se pierde el dinamismo con "esa property" del style. No se pierde ninguno de los dinamismos al agregar nuevos controles (ya sea en la Data rea o en el Style rea) del objeto que se est diseando. Estos controles se consideran "de usuario". Tampoco se pierde ninguno de los dinamismos al modificar o borrar cualquiera de los controles "de usuario". Una vez que se pierde el dinamismo con la Data rea o con el Styie, se puede recuperar utilizando las opciones de men Edit - Default Data rea y Edit - Reapply Form Style, respectivamente. Cambio en el tamao de la Data rea: Para agrandar o achicar la data rea, slo sirve mover los bordes derecho y/o inferior. El form del Style tiene la capacidad de adaptarse al tamao de la Data rea del objeto en el que se lo utiliza. Cuando la Data rea se agranda (ya sea debido al calculo de Default Data rea o a la accin del usuario) el mecanismo de aplicacin dinmica del Style se encarga de agrandar tambin el frame, y mover hacia la derecha y hacia abajo los controles que estn a la derecha y abajo de la Data rea respectivamente. Similar comportamiento se observa al achicar la Data rea (se achica el frame y los controles se mueven hacia la izquierda y hacia arriba). El tamao de la data rea definido en el form del style (y por lo tanto tambin el tamao del frame) se considera como tamao mnimo de la data rea del form del objeto. Consideraciones para el diseo de Styles: Los controles que queden dentro de la Data rea del Style son considerados como "Controles del usuario". Definir fonns para diferentes form classes si los objetos que lo usan tienen mltiples forms. (Ej.: definir un form grfico y uno de texto en el style). Cuando se ponen Eventos y Rules incluir comentarios al principio sobre que cambios se deben realizar en el objeto.

Cuando se ponen Evento y Rules, incluir comentarios al principio sobre qu cambios se deben realizar en el objeto. Por ejemplo, en las rules de un Style para transacciones poner: //sustituir "clave" por el nombre del atributo clave noaccept(clave)

91
Master Style: Objetivo: Style default Se define por modelo Por "tipo de objeto" salvo: - Prompt - Workpanel - Report/procedure - report/procedure definidos en forma independiente para cada modelo dentro de la KB. - File/Edit Model/Master Styles Master Style: Existe la posibilidad de declarar, para cada tipo de objeto, cul de los styles existentes en el modelo se desea que sea considerado como Master Style (es decir, cul se desea utilizar en lugar del "default style"). No es que se tenga que "crear un Master Style" sino que entre aquellos que ya existen, se puede elegir uno y declararlo como Master. Esta declaracin es de carcter opcional: es posible no declarar a ninguno como Master y simplemente funcionar todo como hasta ahora (utilizando el "default style"). En File/Edit Model/Master Styles se designa el Master Style para cada tipo de objeto. En cada caso estn disponibles los styies existentes y la opcin "(None)". Si bien al momento de crear un objeto style, se puede elegir tanto crear un Report Style como un Procedure Style, el tipo del style que en definitiva se crea es siempre Procedure Style. Los Procedure Style pueden ser usados como style tanto para Reports como para Procedures. De la misma manera pueden ser elegidos tanto como para Master Style de Reports como para Master Style de Procedures. Por otro lado, los Work Panel Style pueden ser usados como style tanto para Work Paneis como para Prompts. Master Style: Precedencias: - Style asociado - Master Style - Default MENU BAR Y TOOL BAR: Tipo de objeto Men Bar: Para definicin de Men Bar y Tool Bar - Object/New Object/Menu Bar Add y Delete de tems - Edit/Insert y Edit/Delete respectivamente - Subitems - Personalizacin del tem Help/About Slo en generadores grfico: - VB, VFP - JAVA (en un futuro) Cada objeto GeneXus que tenga Form puede tener su propio Men Bar y Tool Bar. Para definirlos, se usa el tipo de objeto GeneXus Men Bar. Para agregar o borrar opciones (tems) del Men Bar, se utilizan las opciones Edit/Insert y Edit/Delete respectivamente.

92
La definicin de la Tool Bar es exactamente igual a la del Men Bar, slo que en los tems de la Tool Bar se debe definir tambin el bitmap correspondiente. El tem Help/About llama a un work panel GX_ABOUT. GeneXus por defecto ya provee este work panel, en caso de querer personalizarlo se debe crear un nuevo work panel con este mismo nombre con la informacin deseada. Tipo de objeto Men Bar: Definicin de Eventos: Cada tem sin subitems puede tener asociado un evento (Object/Events). Nombre del evento: palabra Men Bar + nombre del tem Son generales No se permiten atributos. En transacciones y work panels - Property Windows Interface/Menubar: *Default, *None, lista de Men Bars existentes. - Pueden programarse eventos para los tems del Men Bar. Son particulares Se permiten atributos. Los eventos definidos en el Men Bar son generales, por lo cual se ejecutarn en todos los objetos que utilicen el Men Bar. Por esta razn es que no se permite el uso de atributos en los mismos. Luego de definido un Men Bar, se debe indicar en que objetos se utilizar. Esto se indica con la property Windows Interface de las transacciones y work panels. En las transacciones y work panels que utilicen el Men Bar definido, se pueden programar eventos para los tems del Men Bar. Como estos eventos son particulares de cada objeto, s se pueden usar atributos. Si un mismo evento se programa en el Men Bar y en el objeto, se ejecuta el del objeto. PROPIEDADES, EVENTOS Y MTODOS ASOCIADOS A LOS CONTROLES: Propiedades de los Controles: Cada control en un Form tiene un 'nombre y 'propiedades' asociadas. Insert/Property: despliega la lista de propiedades vlidas para cada control. Segn el tipo de control, las properties que tiene asociadas. Slo en generadores grficos: - VB, VFP - JAVA (en un futuro) Algunos controles tienen un nombre por defecto, pero hay otros que no; por lo cual si se les quiere aplicar alguna property hay que asociarles un nombre ya que de lo contrario no aparecen en la columna Control al hacer Insert/Property. En el caso del Form el nombre del control (por defecto) es Form. Si se desea cambiar el ttulo de un Form, la forma es: Form.Caption = Datos del Cliente' + CliNom En el caso de un control tipo texto, se le debe dar un nombre. El 'nombre del control para atributos/variables es el nombre del atributo/variable. NOTA: Si una variable es un vector, debe indicarse un nombre a cada posicin del vector para diferenciarlas.

93
Dilogo: Select Property Se accede a travs de la opcin Insert/Property cuando se editan: - Rules, Eventos, Subrutinas, etc en transacciones, work panels y web panels No disponibles en reports y procedures

Form: Permite seleccionar para que tipo de form (Graphic, Text o de Usuario) se le asignar una propiedad a un control. Control: Muestra la lista de controles que hay en el form que se est diseando y que tienen un nombre asociado. Property: Despliega la lista de propiedades que se pueden aplicar al control seleccionado y en la segunda columna se despliegan los tipos de cada property. El Help trae el Help de la property seleccionada Eventos en Controles: Insert/Events Permite asociar Eventos a cada Control. - DbIClick - Click - RightButton - IsValid - GotFocus - OnLineActivate DbIClick: El cdigo asociado a dicho evento se ejecuta al hacer "doble click" sobre el campo. Click: El cdigo asociado a dicho evento se ejecuta al hacer "click" sobre el campo. Right Button: Se dispara cuando se presiona el botn derecho del mouse. IsValid: Se dispara cuando se hace la validacin del control. GotFocus: Se dispara al entrar al campo despus de validar el campo anterior. Evento OnLineActivate: Evento asociado al control "subfile" Se dispara cuando se activa una lnea en el subfile:

94
- al clickear una lnea con el mouse - moverse a travs de la grilla con el teclado - cuando se hace refresh de la grilla. Los valores son los de la lnea "nueva" Los for each incluidos en este evento se anidan a la tabla base del workpanel. Disponible en transacciones y work panels. OnLineActivate: Es un evento asociado al tipo de control subfile. Los For Eachs que se incluyan en dicho evento estarn anidados a la tabla base del work panel, es decir, se comportan igual a los For Eachs del evento Enter. Eventos en Controles:

Form: Permite seleccionar para que tipo de form se le asociar un evento a un control. Control: Muestra la lista de controles que hay en el form que se est diseando. Event: Despliega la lista de eventos que se pueden aplicar al control seleccionado. Mtodos: Se aplican a los controles. Sintaxis: - <Nombre del Control>.<Method> ([<Parms>]) Segn el tipo de control (edit, check box, etc) son los mtodos que se pueden asociar. Se accede a travs de la opcin Insert/Methods cuando se editan: - Rules, Eventos, Subrutinas en transacciones, work panels y web panels. Slo en generadores grfico: VB, VFP, JAVA (en un futuro) - A excepcin del mtodo SetFocus que ser implementado en todos los generadores. La forma de trabajar es similar a la de Properties y Eventos. NOTA: Los generadores texto ignoran los mtodos en tiempo de especificacin.

95
OBJETOS MAIN: Objetos Main: GeneXus genera ejecutables por cada objeto Main.

Cualquier objeto se puede definir como el principal de un ejecutable. Esto, se define en el tab Options del Information del objeto que quiero definir como ejecutable. El ejecutable contiene al objeto en s y todos los que este llama. Llamadas a objetos Main: Cuando desde un objeto se llama a otro objeto que es Main: - GeneXus genera un cali a un ejecutable (en lugar de un call comn) - Son compilables Qu ocurre si un objeto que no es Main pasa a serlo? Ejemplo: - TrnA Wpanel B Call(PImpClis) Call(PImpClis) - PImpClis no es main: GeneXus gener entonces en los programas asociados a la Trn A y Wpanel B un call al programa PImpCIis. El Proc ImpCIis pasa a ser Main: - En los programas asociados a la Trn A y Wpanel B GeneXus debera cambiar el call al programa PImpCIis por un call a un ejecutable "ImpCIis", con lo que deberamos regenerar estos objetos. Para evitar la regeneracin de todos los objetos llamadores: GeneXus usa un concepto llamado STUBS Stubs: Cuando el objeto ImpCIis pasa a ser Main, GeneXus en lugar de generar un nico programa asociado al objeto, realiza lo siguiente: - Genera el programa PimpClis que slo contiene el Call al Ejecutable correspondiente.

96
- Genera otro programa que es el que contiene la lgica del objeto ImpCIis y ser el principal del ejecutable. Esto permite no tener que regenerar todos los objetos que llaman al objeto ImpCIis. Al programa que contiene slo el llamado al ejecutable se le denomina STUB. Tenemos entonces 2 programas generados, asociados a un mismo objeto GX: GeneXus necesita internamente nombrarlos diferentes. - Para la denominacin del programa STUB se siguen las convenciones de siempre (P=Procs, W=Work Panels etc.) - Para la denominacin del programa que sera el principal del ejecutable (el que contiene realmente el cdigo) se usan las siguientes convenciones: Transaccin N Work Panel U Report O Procedure A Men L Web Panel H Siguiendo con el ejemplo, para el objeto ImpCIis, GX generar 2 programas: PImpCIis.xxx y AImpCIis.xxx (xxx= extensin del generador corresp.) y el ejecutable se llamar AImpCIis.exe Web Panel: Permite construir pginas WEB dinmicas que interactan con la base de datos. C/SQL - Con todos los DBMS, excepto AS/400 Visual Basic - Access RPG/400 -AS/400 Los web panels pueden generarse tanto con Visual Basic como con C/SQL. Por lo tanto, pueden ejecutarse en un servidor Windows NT (VB, C/SQL) o en servidores UNIX (usando C/SQL). En caso de generar con RPG, el servidor de Internet debe ser al AS/400. Pueden usar todas las bases de datos soportadas. Restriccin: Con el generador C/SQL no puede usarse el dbms AS/400.

97
EJERCICIOS PRCTICOS: Ejercicios de TRANSACCIONES: En los ejercicios de transacciones, se muestra una imagen de cada form. Las estructuras de las transacciones debern incluir los atributos que aparecen en los forms, pero podr ser necesario incluir otros atributos. Recordar que GeneXus normaliza la base de datos, y que las estructuras de las transacciones deben incluir todos los atributos que son utilizados en ellas, incluyendo reglas y eventos. Esto no es necesario para la definicin de frmulas en las que hay que tener en cuenta el concepto de tabla extendida. Pases:

Field Map: PaisCod Identificador de Pas PaisNom Nombre del Pas Reglas: 1. No se permiten pases sin nombre
error( ) if null ( paisnom)

Char. 4 Char. 30

Clientes:

98
Field Map: Clild CliNom EliDir CliTel PaisCod PaisNom CliSexo CliSaldo CliTotCmp CliTotPag

Identificador de Cliente Nombre Cliente Direccin Telefono Identificador de Pas Nombre del Pas Sexo Saldo del cliente Total de Compras Total de Pagos

Num. 4.0 Char. 20 Char. 20 Num. 6.0 Char. 4.0 Char. 30 Char 1 Num. 7.2 Num 7.2 Num 7.2

ZZZ9

ZZZZZZ9

Definir los dominios: Nombre Direccin Telfono Definir el siguiente Control: Sexo - Radio Button Reglas: 1. No se permiten clientes sin nombre: err(ASG) if null ( ) 2. Avisar, en caso de que no se ingrese la direccin: err(ASG) if null (

Frmulas: 1. El saldo del cliente, se calcula como la diferencia entre compras y pagos. Utilizar el botn derecho sobre el atributo en la estructura de la transaccin para la definicin de la frmula. Sugerencias para la definicin de transacciones: Utilizar el Diagrama de Transacciones (Opcin-.Tools/Diagrams/Transactions) Utilizar el Diagrama de Tablas (Opcin: Tools/Diagrams/Tables) Utilizar la opcin: Tools/Browsers. Utilizar la insercin de reglas, funciones, etc. (Opcin: Insert/Rules, Insert/Functions.etc.) Productos: Field Map: ProdId ProdDsc ProdStkMin ProdStkAct ProdFchLta ProdPrecLta Reglas: Cdigo del Producto Descripcin del Producto Stock mnimo Stock Actual del Producto Fecha de Lista del Producto Precio Unitario Char Char Num Num Date Num 5 15 4.0 4.0 8 7.2

1. No aceptar el stock del producto si se esta modificando un articulo ya existente, pero permitir ingresar el stock cuando se inserta un nuevo artculo (en insert). 2. No permitir ingresar un stock nulo. Crear el prototipo de la aplicacin: Recordar que con el botn derecho (seleccionando de la lista de objetos) podemos especificar. Facturas:

99

Field Map: FacId FacFch FacTpo CliId CliNom FacLinNro ProdId ProdDsc FacLinCnt FacProdPre FacLinImp FacTotal Generalidades:

Identificador de Factura Fecha de factura Tipo de la factura (Crdito o Contado) Identificador de Cliente Nombre del Cliente Nro. de Lnea Cdigo del Producto Descripcin del Producto Cantidad de la Linea Precio del Producto en la Factura Importe de linea Total de Factura

Num. 6.0 Date 8 Char 1 Num. 4.0 Char 20 Num 2.0 Char 5 Char 15 Num 4.0 Num 7.2 Num 7.2 Num 7.2

1. Definir el atributo FacTpo como un Combo Box 2. Definir el atributo FacTotal con CourierNew de 12 en color Rojo. Reglas: 1. Numerar las lneas de la factura en forma automtica (Regla Serial).

2. Hacer que la fecha de la factura sea la del da por defecto. 3. Actualizar el total de compras del cliente si la factura es de tipo Crdito

100
4. Evitar que se ingresen mas de 10 lneas en la factura (ver frmula 4). 5. No permitir ingresar fechas nulas, ni mayor a la del da.

6. Actualizar el stock del producto 7. Controlar que el stock del producto no sea menor que cero. 8. Advertir cuando se sobrepasa el stock mnimo del producto Frmulas: 1. Encontrar el precio del producto de acuerdo a la fecha de la factura (FacProdPre). 2. Calcular el importe de cada lnea de la factura (FacLinImp). 3. Calcular el total de la factura (FacTotal). 4. Contar la cantidad de lneas ingresadas. Probar las siguientes facilidades: Drag and Drop de controles entre forms de transacciones. Utilizar el List Datbase (Opcin: Tools/List Datbase) Utilizar List Attributes (Opcin: Tools/List Attributes) Ejercicios de Reportes y Procedimientos: Listado de clientes ordenado por nombre en un rango de nombres definido por el usuario. Los datos que se desean listar para cada Cliente son: Nombre, Direccin y Telfono. Listado de la factura al finalizar el ingreso de la misma en la transaccin de facturas. Listado de ventas por cliente, incluyendo slo los clientes que tienen facturas (Corte de Control). Cliente: CliXXX Nro. Factura 000001 000002 Total de ventas: $2524 Cliente: CliYYY Nro. Factura 000010 000011 Total de ventas: $1000 Procedimiento para generar una nueva lista de precios en los productos. El procedimiento pedir dos parmetros: Fecha del aumento Porcentaje de aumento La nueva lista de precios para cada producto tendr la fecha ingresada como parmetro y el precio que resulte de aplicar el porcentaje de aumento al ultimo precio de cada producto cuya fecha sea menor a la ingresada por parmetro. Fecha 01/01/98 010298 Importe $700 $300 Fecha 01/01/98 010298 Importe $1024 $1500

101

Numerar automticamente la Factura. Para ello necesitaremos tener una estructura auxiliar donde guardar el ltimo nmero de Factura. Utilizar una udp para realizar la numeracin de la Factura. Ejercicios de Work-PaneIs: Crear un folder y agrupar en ste, los Work-PaneIs Trabajar con Clientes: Se trata de un Work-Panel que muestra los clientes en forma de lista, y permite las siguientes opciones: Visualizar slo los clientes que estn en el rango que el usuario determine. Posicionamiento por Nombre de Cliente dentro de los clientes en el rango (Regla Search). Dar Altas, Bajas y Modificaciones a clientes, es decir que desde este Work Panel deben haber tres botones los cuales deben llamar a la transaccin de Clientes (pasando como parmetro el modo correspondiente) para poder realizar dichas operaciones. Dar la posibilidad de insertar un cliente tanto al presionar el botn como al presionar la tecla de funcin F6. permitir visualizar la lista de Facturas de un cliente (botn de Facturas). Ver en prxima hoja "Visualizar facturas de un cliente". Utilizar de Tools/ Browsers la opcin Callees para poder visualizar a que programas llama esteWorkPanel (rbol de llamadas). Visualizar facturas de un cliente: Se desea que este Work Panel despliegue la lista de facturas ordenada por fecha del documento del cliente recibido como parmetro. Los datos que se desea desplegar en pantalla en la parte fija del Work Panel son Identificador y Nombre del Cliente recibido como parmetro, y en el subfile: Nro. De Factura, Fecha y Total de Factura. Incluir en este Work Panel un bitmap con el logo de la empresa, el archivo de extensin BMP sacarlo del directorio de windows. Desde este Work Panel se desea tener un botn al cual presionndolo se llame a otro Work Panel que permita Visualizar todos los datos de la factura que se seleccione. Modificar el Prompt de Productos (generado por defecto): El Prompt de Productos es un Work-Panel (generado automticamente por GeneXus, de nombre GX00NN) que puede ser llamado desde la transaccin de facturas (presionando F4 estando posicionado en el cdigo de producto o con el botn de prompt) y permitir seleccionar un determinado producto. Lo que se pide es tener la posibilidad de dar un alta (llamar a la transaccin de productos) desde dicho Work Panel.

102
Ejercicios de Styles: Definir un Style para transacciones que contenga los botones Confirm, Close, Delete, Help, First, Previo, Next, Last y Select (los bitmaps se encuentran en u:\bitmaps)

Asociarle este styie a todas las transacciones (excepto a las que son llamadas de un work panel "TRABAJAR CON...") Men Bar: Crear un Men Bar que contenga un tem llamado "LISTADOS". Colgar de dicho tem, la opcin "Listado de Facturas". Seleccionando esta opcin se debe invocar a un reporte que liste todas las facturas. Asociarle este Men Bar a la TRN de Clientes y customizar el tem de "Listado de Facturas". Es decir que en la TRN de Clientes se llamar a un listado que listar todas las Facturas del cliente con que se esta trabajando.