Curso GeneXus Parte 1

Curso GeneXus
Parte I
Copyright (c) ARTech Noviembre 2000
TABLA DE CONTENIDO
CAPACITACION GENEXUS ....................................................... 4
INTRODUCCION TEORICA ..................................................... 10
.............................................................................................................
METODOLOGIA TRADICIONAL .............................................. 14
METODOLOGIA GENEXUS........................................................ 19
.............................................................................................................
DISEO DE TRANSACCIONES................................................ 41
NOMENCLATURA GIK .............................................................. 47
TIPOS DE DATOS ....................................................................... 49
COMANDOS DE ASIGNACIN .................................................. 51
DOMINIOS ................................................................................... 52
TAB CONTROL ........................................................................... 55
INTEGRIDAD REFERENCIAL ................................................. 59
CONCEPTO DE TABLA EXTENDIDA .................................... 62
ATRIBUTOS FORMULAS ......................................................... 66
CARACTERISTICAS .................................................................... 67
CLASIFICACION .......................................................................... 68
FORMULAS HORIZONTALES ................................................... 69
FORMULAS VERTICALES.......................................................... 72
FORMULAS AGGREGATE / SELECT ........................................ 75
COMUNICACION ENTRE OBJETOS..................................... 98
REGLAS Y COMANDOS............................................................ 100
SUBRUTINAS ............................................................................. 107
ARBOL DE EVALUACION Y EVENTOS .............................. 110
ARBOL DE EVALUACION ........................................................ 111
EVENTOS EN TRANSACCIONES ............................................ 119
REPORTES YPROCEDIMIENTOS ........................................ 131
COMANDO FOR EACH ............................................................ 134
INFERENCIA DE TABLAS ....................................................... 135
REPORT WIZARD ...................................................................... 141
DISTINTOS CASOS DE FOR EACH ........................................ 142
REPORT VIEWER ....................................................................... 150
PROCEDIMIENTOS ................................................................... 151
RESTRICCIONES ........................................................................ 155
WORK PANELS ...................................................................... 156

DIFERENTES TIPOS DE PANELES ....................................... 158
COMANDO FOR EACH LINE ................................................. 162
EVENTOS ................................................................................. 164
REGLAS MAS IMPORTANTES ............................................. 166
PROPIEDADES MAS IMPORTANTES ................................... 167
SUBTIPOS ............................................................................... 170
KNOWDLEGE MANAGER .................................................. 175
BUSINESS OBJECTS ............................................................ 178
OBJECTOS PRIVADOS ....................................................... 187
EFICIENCIA Y PERFORMANCE ....................................... 191
DEFINICION DE FILTROS .................................................... 194
ORDEN DE RECORRIDA ....................................................... 196
MULTIPLES FORMS.............................................................. 208
STYLES ..................................................................................... 213
MENU BAR Y TOOL BAR ..................................................... 226
PROPIEDADES, EVENTOS Y METODOS
ASOCIADOS A LOS CONTROLES ...................................... 229
OBJETOS MAIN ...................................................................... 238
DATA VIEWS ......................................................................... 244
WEB PANEL............................................................................. 262
Capacitacin GeneXus
CURSO GENEXUS PARTE I
Es indispensable para comenzar a desarrollar Aplicaciones GeneXus.
Objetivo : Capacitar a los usuarios para conseguir el cambio de mentalidad que GeneXus requiere
y dar elementos bsicos para el diseo de Aplicaciones.
Alcance : Conceptos fundamentales y elementos bsicos. No se abordan todos los temas, algunos
de ellos son abordados en el Curso Genexus Parte II.
Orientado: A Usuarios que van a desarrollar directamente Aplicaciones usando GeneXus y
lderes de Proyecto.
Etapas: Este curso consta de 3 etapas:Autoestudio , Curso Terico/ Prctico y Taller.
Aprobacin: Este curso es evaluado por los instructores de Artech . La evaluacin consiste en la
defensa del Taller realizado y el resultado de dicha evaluacin (Aprobacin /No aprobacin)
es comunicado a la Empresa.
Habilitado a: El alumno que aprueba dicho curso queda habilitado a desarrollar aplicaciones de
pequeo y mediano porte, sin embargo es necesario el apoyo que se brinda en el WorkShop.
Duracin: 76 horas distribuidas en cuatro semanas.
CURSO GENEXUS PARTE II

Objetivo: Alcanzar la capacitacin completa para desarrollar Aplicaciones GeneXus.
Pensamos que despus del curso se levanta la productividad substancialmente alcanzando en
poco tiempo el nivel mximo.
Alcance: Se tratan algunos temas que no se vieron en el Curso Genexus Parte I y se
profundiza en temas avanzados.
Orientado a: Usuarios que van a desarrollar directamente aplicaciones usando GeneXus y
lderes de Proyecto.
Duracin: 16 horas distribuidas en cuatro das.
WORKSHOP
Objetivo: Apoyo inicial a la primera aplicacin real que desarrolla el cliente. El Workshop
cumple las siguientes funciones fundamentales: a) Realizar un anlisis inicial junto al cliente
que redunde en una planificacin para la correcta insercin de GeneXus en la empresa b)
Apoyar tcnicamente el comienzo del desarrollo con la herramienta de cuyo resultado
depende en gran parte el futuro desempeo y satisfaccin del cliente. c) Tener un
seguimiento del Cliente en la etapa inicial para asegurarnos que obtiene la productividad
esperada y corregir posibles desvos en la etapa inicial.
Condiciones previas: Tener aprobado el Curso Genexus.
Orientado a: Usuarios que van a desarrollar directamente aplicaciones usando GeneXus y
lderes de Proyecto.
Duracin: 20 horas de consultora en el Cliente.
Comienzo: Es conveniente comenzarlo apenas finalizado el Curso GeneXus . Debe
comenzar antes de los 60 das de finalizado dicho curso, sino se pierde el derecho a
realizarlo.
DESARROLLO DE APLICACIONES CLIENT/SERVER

Objetivo: Dar los elementos necesarios para poder generar aplicaciones en una arquitectura
Cliente/ Servidor.
Condiciones previas: Tener aprobado el Curso GeneXus.
Alcance: Porqu una Arquitectura Client/Server? , Consideraciones generales de las
Arquitecturas C/S , Diseo de una aplicacin Client/Server , Optimizacin y Performance de las
aplicaciones , Multi-tier Architecture.
Orientado a: Gerentes de proyecto y tcnicos de la empresa, ya que les brindar la posibilidad
no solo de conocer a fondo esta Arquitectura y sus posibilidades, sino tambin les dar el
conocimiento para desarrollar aplicaciones sobre las mismas .
Duracin:24 horas distribuidas en 6 das.
CURSO JAVA
Objetivo: Dar los elementos necesarios para poder generar aplicaciones Java en una
arquitectura Cliente/Servidor de 2 y mltiples capas para correr tanto en una Intranet como en
Internet.
Condiciones previas: Tener aprobado los cursos GeneXus y Client/Server
Alcance: Informacin general sobre lenguaje Java, Informacin general sobre Generador Java,
Software necesario, Configuracin del Modelo, Distribucin de aplicaciones para su puesta en
produccin, Ejecucin en mltiples capas, Pool de conexiones, Lightweight Directory Access
Protocol (LDAP)
Orientado a: Gerentes de Proyecto y Tcnicos de la empresa.
Duracin: 12 horas (terico/prctico) distribuidas en 3 das.
DESARROLLO DE APLICACIONES PARA INTERNET

Objetivo: Dar los elementos necesarios para poder generar aplicaciones a ser utilizadas en
Internet. Integrar las operaciones de Internet con la Base de Datos Coorporativa.
Condiciones previas: Tener aprobado el Curso GeneXus.
Duracin: 24 horas distribuidas en 6 das.
CURSO DATA WAREHOUSING

Objetivo: Durante aos hemos desarrollado sistemas operacionales y con ellos hemos resuelto
muy bien las funciones operacionales de nuestras organizaciones (fbricas de datos). Como
consecuencia de esto, en nuestras bases de datos hemos recopilado una gran cantidad de datos
y con ellas hemos ofrecido un buen nivel de informacin a nivel de gestin. Sin embargo, no
hemos podido usar esos datos para proveer informacin a los niveles ms altos de nuestras
organizaciones, ni hacerlo con el dinamismo necesario. Este fenmeno es conocido como 'data
in jails' (los datos existen, pero estn 'enjaulados'). Los niveles de direccin y estratgicos son
los que actualmente se encuentran ms carentes de informacin. Necesitamos proveer
informacin de buena calidad, oportuna y en forma dinmica para el apoyo a la toma de
decisiones.
En la ltima dcada surgen, bajo el nombre DATA WAREHOUSING, ciertas tcnicas,
metodologas y teconologas con el fin de resolver esta problemtica.
ARTech ha y est trabajando en la investigacin y desarrollo de tecnologa para facilitar el
desarrollo de Soluciones de Data Warehousing.
Hemos acumulado conocimiento sobre este tema en base a material existente y a nuestra propia
experiencia en proyectos de este tipo y formalizado el mismo; llegando a construir una
metodologa sencilla y desarrollando tecnologa para apoyar todas las etapas de la solucin.
El objetivo de este curso es : conocer la teora de Data Warehousing, cuales son las
componentes de la solucin, tcnicas y metodologas aplicadas, tecnologa asociada a cada
componente, y ver como la tecnologa GeneXus nos apoya en cada etapa del proceso de
construccin de la solucin.
ALCANCE : Los punto principales que se tratan en el curso son los siguientes: Conocimiento
de los diferentes aspectos de la problemtica, Esquema general de la solucin Data
Warehousing, Componentes de la solucin, Etapas en el desarrollo de un proyecto, Estudio
detallado de las metodologas aplicadas en cada etapa y Tecnologa asociada a cada
componente. En forma paralela al curso terico se irn estudiando casos prcticos y los
participantes irn aplicando sobre stos las metodologas aprendidas. Finalmente el participante
realizar el diseo y parte de la implementacin de un caso prctico con la tecnologa GeneXus
- Data Warehousing.
ORIENTADO A: El Curso est orientado principalmente a Gerentes de Informtica, Lderes
de Proyectos y Desarrolladores. A los Lderes de proyectos y Desarrolladores se les pide tener
aprobado el Curso GeneXus. A los Gerentes de Informtica se les recomienda realizar
previamente las dos primeras semanas del curso GeneXus.
DURACIN: 32 horas distribuidas en 8 das.
CURSO WORKFLOW
Objetivo: Uno de los problemas que se encuentra habitualmente en el desarrollo de
aplicaciones para empresas, es que las tareas o procesos que se desarrollan en el entorno laboral
de las mismas quedan inmersos en el cdigo de la aplicacin que resuelve la problemtica de la
empresa. Est claro que la gran mayora de los usuarios no tienen conocimiento de estas tareas,
las mismas estn ocultas a sus ojos y se realizan automticamente. El hecho de realizar cambios
en dichas tareas o procesos resulta muy costoso, y es muy factible que dichos cambios redunden
en realizar nuevamente la aplicacin.
Una buena solucin al problema anterior es separar los procedimientos y asociarlos a los flujos
de trabajo realizados dentro de la empresa. Vemos entonces, que el Workflow se relaciona con
la automatizacin de los procedimientos donde los documentos, la informacin o tareas son
pasadas entre los participantes del sistema de acuerdo a un conjunto de reglas previamente
establecidas. El fin de lo anterior es llegar a culminar una meta comn impuesta por la empresa.
El Workflow nos da las facilidades para modelar los procesos de empresa, permitindonos de
esta forma hacer un anlisis y diseo mas profundo de los mismos. Vemos entonces al
Workflow no solo como una tecnologa que nos facilita el cambio, sino tambin, como una
tecnologa que nos da un marco de referencia para el anlisis y diseo previo a la implantacin
de un sistema que implica la interaccin de diversos procesos.
ARTech ha estado trabajando en la investigacin y desarrollo de tecnologa de Workflow para
incorporarla al desarrollo de los Sistemas de Informacin. Esto surgi al detectarse que en
varios proyectos realizados nos enfrentbamos a problemas que se podan resolver de una forma
ms natural con este tipo de tecnologa. As en una primera instancia surgi una solucin de
Workflow especfica para resolver la problemtica de un proyecto y hoy en da se dispone de
una solucin integral para desarrollos con GeneXus que est siendo utilizada en varios
proyectos. El objetivo de este curso es: conocer los conceptos ms importantes de la teora de
Workflow, cuales son las componentes de la solucin, tecnologa asociada a cada componente,
y ver como se integra esta tecnologa al desarrollo de sistemas con GeneXus.
Alcance: Los puntos principales que se tratan en el curso son los siguientes: Conceptos
Tericos de Workflow, estudio de la herramienta de definicin de procesos (GeneXus Process
Modeler), estudio del Workflow en ejecucin (Inbox y Motor de Workflow), estudio de las
Workflow APIs, y el estudio de la integracin de la solucin de Workflow con el desarrollo de
los sistemas con GeneXus. En forma paralela al curso terico se ir estudiando casos prcticos y
los participantes irn aplicando sobre stos las metodologas aprendidas. Finalmente el
participante realizar el diseo y la implementacin de un caso prctico con la tecnologa
GeneXus-Workflow.
Orientado a: El Curso est orientado principalmente a Gerentes de Informtica, Lderes de
Proyectos y Desarrolladores. A los Lderes de proyectos y Desarrolladores se les pide tener
aprobado el Curso GeneXus. A los Gerentes de Informtica se les recomienda realizar
previamente las dos primeras semanas del curso GeneXus.
Duracin: 16 horas distribuidas en 4 das.
RECOMENDACIN:
A continuacin detallamos una propuesta de capacitacin para cada uno de los Roles que se
llevan a cabo dentro del rea de informtica.Reconocemos que muchas veces estos roles son
cumplidos por la misma persona o por varias , para lo cual debern considerarse las funciones
ms que las personas.
DESARROLLADOR GENEXUS: Persona directamente involucrada en el Desarrollo de
Aplicaciones
GERENTE y/o LDER DE PROYECTO : Persona que coordina el desarrollo de un grupo de
desarrolladores y eventualmente desarrolla aplicaciones.
GERENTE DE INFORMATICA: Persona encargada del sector informtico de la Empresa.
DESAROLLADOR
- CURSO GENEXUS - Al comienzo
- WORKSHOP - Inmediatamente despes de finalizado el Curso Genexus
- CLIENT/SERVER - Despus del Curso Genexus (si corresponde)
- DESARROLLO DE APLICACIONES PARA INTERNET - Despus del Curso Genexus (si corresponde)
-WORKFLOW - Despus del Curso Genexus (si corresponde)
-CURSO PARA GERENTES DE PROYECTOS - Tres meses despus de aprobado el Curso Genexus
GERENTE y/o LDER DE PROYECTO
- CURSO GENEXUS - Al comienzo
- CURSO PARA GERENTES DE PROYECTOS - Inmediatamente despus del Curso Genexus
- CLIENT/SERVER - Despus del Curso Genexus (si corresponde)
- DESARROLLO DE APLICACIONES PARA INTERNET - Despus del Curso Genexus (si corresponde)
- WORKFLOW - Despus del Curso Genexus (si corresponde)
GERENTE DE INFORMTICA
- TEORICO DEL CURSO GENEXUS PARTE 1- Al comienzo
- CURSO PARA GERENTES DE PROYECTOS- Despus del terico del Curso Genexus Parte1
Introduccin
Terica
10
REALIDAD
Herramientas y Metodologas
?
BASE
DE
DATOS
PROGRAMAS
Desarrollo
y
Mantenimiento
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 herrramientas y metodologas.
Con GeneXus se desarrollan aplicaciones aplicando una metodologa que tiene un
enfoque muy diferente al de las metodologas mas comunmente utilizadas.
Aprender a utilizarlo adecuadamente va ms alla de conocer el lenguaje de
especificacin y lo ms importante es el aprendizaje de una nueva metodologa de
desarrollo.
11
Modelado de la realidad
a partir de las Visiones de Usuarios
Satisface
MODELO DE
LA REALIDAD
Ingenieria Inversa
BASE
DE
DATOS
PROGRAMAS
VISIONES
DE
USUARIOS
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 Ingenieria 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.
12
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.
13
Metodologa Tradicional
14
REALIDAD
ANALISIS
DE
DATOS
BASE
DE
DATOS
ANALISIS
FUNCIONAL
GENERACION/
INTERPRETACION
ESPECIFICACION
FUNCIONAL
PROGRAMAS
PROGRAMACION
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.
15
En caso de que desearamos 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 mas
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
metologa que hagan posible la realizacin de esta tarea.
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 soportarlo, 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 funciones 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.
16
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 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.
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, TELON, 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.
17
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:
Baja productividad en el desarrollo
Buen aumento de productividad en el desarrollo sobre L3G.
Generadores
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.
18
Metodologa
Los fundadores de ARTech han desarrollado una amplia actividad de consultora

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.
19
REALIDAD
DESCRIPCION
DE OBJETOS
Desarrollo con
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.
20
REALIDAD
DESCRIPCION
DE OBJETOS
BASE
DE
DATOS
BASE DE
CONOCIMIENTO
Desarrollo con
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.
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.
21
REALIDAD
ANALISIS
DE
DATOS
DESCRIPCION
DE OBJETOS
BASE
DE
DATOS
ANALISIS
FUNCIONAL
BASE DE
CONOCIMIENTO
Comparacin de
Metodologas
GENERACION/
INTERPRETACION
ESPECIFICACION
FUNCIONAL
PROGRAMAS
PROGRAMACION
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.
22
Descripcin de Objetos
Transacciones
(TRNs)
Reportes
(RPTs)
Procedimientos
(PROCs)
Work Panels
(WKPs)
Menues
(MNUs)
La primer 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 ej. Clientes, Proveedores, Artculos).
A partir de las transacciones Genexus infiere el diseo de la base de datos.
PROCEDIMIENTOS
Procesos no interactivos de actualizacin de la base de datos (procesos batch).
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.
MENUES
Objetos organizadores del resto.
23
Sistematizacin del conocimiento
Transacciones
(TRNs)
Reportes
(RPTs)
Procedimientos
(PROCs)
Work Panels
(WKPs)
Menues
(MNUs)
Base
Basede
deConocimiento
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.
24
Inferencia de la Base de Datos

Transacciones
(TRNs)
Reportes
(RPTs)
Procedimientos
(PROCs)
Work Panels
(WKPs)
Menues
(MNUs)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
A partir del conocimiento especificado a travs de las transacciones, GENEXUS

disea el modelo de datos normalizado (en 3a. forma normal).
25
Creacin de la Base de Datos

Transacciones
(TRNs)
Reportes
(RPTs)
Procedimientos
(PROCs)
Work Panels
(WKPs)
Menues
(MNUs)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Programas
Generacin
BD
GENEXUS genera automticamente los programas necesarios para crear la base de

datos, y la crea mediante ellos.
26
Generacin de los Programas de la

Aplicacin
Transacciones
(TRNs)
Reportes
(RPTs)
Procedimientos
(PROCs)
Work Panels
(WKPs)
Menues
(MNUs)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Programas de Aplicacion
(TRN, RPT, PROC, WKP y MNU)
GENEXUS genera automticamente, a partir de la Base de Conocimiento, los

programas de la aplicacin.
27
Resultado final en la Etapa de Desarrollo

Transacciones
(TRNs)
Reportes
(RPTs)
Procedimientos
(PROCs)
Work Panels
(WKPs)
Menues
(MNUs)
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Aplicaciones
En este estado , la aplicacin est pronta.
28
Las Visiones de los Usuarios Cambian

Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Menues
Base
Basede
deConocimiento
Conocimiento
Base
de
Datos
Nueva
Base
de
Datos
Como se ha dicho, durante el ciclo de vida de la aplicacin, existen muchas

modificaciones.
Ante cambios en las visiones de usuarios, GENEXUS disea la nueva base
de datos.
29
Anlisis de Impacto Totalmente Automtico

Nuevas
Transacciones
Nuevos
Reportes
Anlisis
de
impacto
Base
de
Datos
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Menues
Base
Basede
deConocimiento
Conocimiento
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.
30
Generacin de Programas de Reorganizacin

de la Base de Datos
Nuevas
Transacciones
Nuevos
Reportes
Programas
de
Reorganiz.
Base
de
Datos
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Menues
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
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 consiste entonces, en ejecutar esos programas.
En realidad es de esperar que tengan muchas tablas comunes, que no se
modificarn en la reorganizacin.
31
Anlisis Automtico del Impacto de los

cambios sobre los Programas
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
Nuevos
Menues
Anlisis
de
impacto
Nuevos
32
Generacin Automtica de Nuevos

programas
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
Nuevos
Menues
Generacin
de nuevos
Programas
Nuevos
GENEXUS genera /regenera automticamente los programas

necesarios.
33
Nueva Realidad , con los cambios en la

Aplicacin
Nuevas
Transacciones
Nuevos
Reportes
Nuevos
Procedimientos
Nuevos
Work Panels
Nuevos
Menues
Base
Basede
deConocimiento
Conocimiento
Nueva
Base
de
Datos
Nuevos
Aplicaciones
Ahora se tienen las nuevas aplicaciones. El ciclo de mantenimiento est

completo.
34
Mltiples Plataformas de ejecucin a partir de una nica

especificacin
ARQUITECTURAS CENTRALIZADAS
Plataforma
AS/400
Lenguaje Generado
COBOL/400, RPG/400
ARQUITECTURAS FILE SERVER

Plataforma
DOS
WINDOWS
Lenguaje Generado
Foxpro, Clipper
Foxpro for Windows
Visual Basic
Visual Fox
DBF
DBF
ACCESS
DBF
ARQUITECTURA CLIENT/SERVER
Cliente
Database Server
Plataformas (Ejs.)
FOXPRO WIN, VB, VFP, JAVA ORACLE
Unix, NT
MS SQL SERVER
Alfa, WINDOWS NT y 95
INFORMIX
Unix, NT
DB2 Common Servers
RS6000, OS2
DB2/400
AS400
35
Metodologa Incremental
Consiste en construir una aplicacin mediante aproximaciones
sucesivas.
DEFINICION
INICIAL
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.
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.
36
Ciclos Diseo-Prototipo y
Diseo-Produccin
Diseo
Prototipo
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 DiseoProduccin, 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.
37
Prototipacin Integral en PC
MODELO DE
LA REALIDAD
Construccin
Automtica
Usuario probando todos los detalles
de la aplicacin
BASE
DE
DATOS
PROGRAMAS
La construccin automtica del soporte computacional nos dar la gran

posiblidad 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.
38
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 de sistemas es, habitualmente,una tarea que insume
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.
39
Warnier-Orr
Comienzo
Emisin de
la Factura
Emisin del
cabezal
Comienzo
Emisin de
una Factura
(cuerpo)
Fin
Nro de Factura
Nro de Cliente
Nombre Cliente
Fecha Factura
Proceso de
emisin de
lneas
Emisin de
una lnea
Fin
Fin
Cdigo Producto
Nombre Producto
Precio Producto
Cantidad Producto
Importe Producto
Ahora vamos a concentrarnos en cul es la forma prctica utilizada por

GeneXus, para la captura de la realidad de la que tanto hablamos.
Jean Dominique Warnier 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:
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.
Analicemos por ejemplo un proceso de emisin de las Facturas de una
empresa:
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 includo 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.
40
DISEO DE
TRANSACCIONES
41
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
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.
42
Definicin del diseo de Base de Datos en 3era Forma Normal

para soportar las transaccciones definidas.
TRN. FACTURA
FacNro*
CliCod
CliNom
FacFch
(ProdCod*
ProdNom
ProdPre
FacLinCnt
FacLinImp)
TABLAS
Factura
FacNro*
CliCod
CliNom
FacFch
Factura1
FacNro*
ProdCod*
ProdNom
ProdPre
FacLinCnt
FacLinImp
Veamos el proceso de obtencin de una base de datos en 3era. 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 ----> CliCod
FacNro ----> CliNom
FacNro ----> 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.
FacNro, ProdCod ----> ProdNom
FacNro, ProdCod ----> ProdPre
FacNro, ProdCod ----> FacLinCnt
FacNro, ProdCod ----> FacLinImp
Que definirn una tabla con el siguiente diseo
FacNro *
ProdCod*
ProdNom
ProdPre
FacLinCnt
FacLinImp
43
Definicin de las transacciones Clientes y Productos

Clientes
CliCod*
CliNom
Trn. Clientes
CliCod*
CliNom
Trn. Productos
ProdCod*
ProdNom
ProdPre
Producto
ProdCod*
ProdNom
ProdPre
Factura
FacNro*
CliCod
CliNom
FacFch
Factura1
FacNro*
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 ----> CliNom
ProdCod ----> ProdNom, ProdPre
La siguiente dependencia funcional
FacNro ----> CliNom
se ha vuelto transitiva a partir de la existencia de las dep. func.
FacNro ----> CliCod
CliCod ----> CliNom
Por lo que deber modificarse la tabla Factura.
Anlogamente con la tabla Factura1 y las dependencias funcionales
FacNro, ProdCod ----> ProdNom, ProdPre
ProdCod
----> ProdNom, ProdPre
44
GeneXus establece las relaciones por los nombres.

Todo lo que es conceptualmente lo mismo, debe tener el mismo nombre.
Transacciones:
Factura
FacNro*
CliCod
CliNom
..........
Factura
FacNro*
CliFacCod
Cliente
SI
CliCod*
CliNom
...........
Cliente
NO
CliCod *
Conceptos diferentes no deben tener el mismo nombre.

Ventas
Compras
FctVtaNro*
Fecha
CliCod
FctCmpNro*
Fecha
PrvCod
CliNom
NO
PrvNom
45
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
46
Nomenclatura GIK - Nombre del Atributo
Complemento
(texto libre)
Calificador (1 a 3)
Calificador (1 a 3)
Categora Semntica (1 a 3)
Objeto ( 1 a 6 )
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.
Calificador, Puede existir uno o dos calificadores.
47
Ejemplo de Nomenclatura GIK

Objetos
Categorias
Calificador
Cli
Cod
Cli
Nom
Cli
Fch
Ini
Cli
Fch
Fin
FacVta
Nro
FacCmp
Nro
48
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 .
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.
49
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.
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.
50
Comandos de asignacin
+=
-=
*=
/=
Sintaxis: <Variable_o_Atributo> <Comando> <Expresin>
Ejemplo: &I += 1 (equivalente a &I = &I + 1)
51
Dominios
Cuando debemos usar dominios?
Atributos con la misma definicin
No existe relacin entre ellos
Ejemplo: Direccin Char 30
Direccin del Cliente
Direccin del Banco
Dominio
Atributos
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 cliente 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 pemiten un mayor nivel de abstraccin en la
definicin de la aplicacin.
52
Reglas
Se utilizan para definir el comportamiento de las
transacciones.
Algunas reglas
Default, Error, Ask, Msg, Asignacin, Add, Subtract, etc.
Default(FacFch, &today);
Error(No se permiten clientes sin nombre)
if null(CliNom);
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:
Default - 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:
Error(No se permiten clientes sin nombre)if null(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.
Asignacion - Dentro de las reglas de la transaccion se permiten definir asignaciones a atributos,
dicha asignacion implica una actualizacion en la tabla base del nivel o en alguna de las tablas que
pertenecen a la tabla extendida del nivel.
Una asignacion en las reglas es LOCAL (vale solo para la transaccion 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).
53
Toolbar de Controles
Para el diseo de Pantallas
Atributo / Variable
Texto
Lnea
Recuadro
Subfile
Botn
Bitmap
Tab Control
Print Block
Se utiliza para disear la pantalla (form) en forma grfica. Mientras se est

diseando un form (de TRNs, WKPs o Reports) est disponible la tool bar de
Controles que contiene los tipos de controles que se pueden agregar al form
que se est editando.
5412
16
Tab Control
Permite definir varios controles dentro de un Tab
Control.
Tiene una o varias pginas.
Default: Dos pginas
Agregar o eliminar pginas:
Botn derecho sobre el Tab Control
Pgina
Ttulo
Area til
Check Box de Hide Tabs ==> Para diseo de Wizards
Slo para los generadores visuales.
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. Util para la definicin
de Wizards.
55
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/Foxpro/Visual FoxPro y se requiere como mnimo la versin 3.10.505.
5662
Generacin de
HELP Tipo Windows
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.
5763
Pasemos a Prototipo...
Al definir un modelo, es necesario ingresar cierta informacin. La informacin

solicitada es la siguiente:
Name: Nombre del modelo que se esta creando
Type: Tipo de modelo (Prototipo, Produccin, Backup)
Language: Idioma (Ingls, Espaol, Portugues, Italiano)
Generador: Plataforma en la cual se desea que sean generados los programas (tanto
los programas de creacin/reorganizacin de la base de datos, como los programas de
aplicacin).
DBMS: Sistema Manejador de Base de Datos
Target Path: Directorio en el cual quedaran los programas generados (este directorio
ser creado bajo el directorio de la Base de Conocimiento).
El botn Preferences permite configurar ciertas propiedades para el modelo
(dependiendo del generador elegido, algunas propiedades a configurar seran distintas).
El botn DBMS Options permite configurar la informacin requerida para el acceso a
la Base de Datos (por ejemplo, Data Source, etc.).
El botn Execution permite configurar ciertas propiedades de ejecucin (por ejemplo,
donde se encuentra instalado el intrprete).
58
INTEGRIDAD
REFERENCIAL
59
Diagrama de Bachman
Catego
Depart
CatCod*
CatNom
DtoCod*
DtoNom
Client
CliCod*
CliNom
CatCod
DtoCod
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.
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 neceario 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 registros correspondientes en la tabla subordinada (Client).
60
Definicin de Indices
Tabla
Catego
Depart
Client
Tipo
Indice
Composicin
PK
PK
PK
FK
FK
CatCod
DtoCod
CliCod
DtoCod
CatCod
Definicin de Indices
Para hacer eficientes 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.
Indice 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 tablas
subordinadas (Client), exista 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.
Indice Extranjero (FK):
Los ndices extranjeros son utilizados para hacer eficientes los controles de integridad intertablas. Tambin son definidos automticamente. Cuando se elimina un registro en una tabla
superordinada (Catego), no deben existir registros correspondientes en la tabla subordinada
(Client).
Indice 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. 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.
61
CONCEPTO DE TABLA
EXTENDIDA
62
Tabla Extendida
Definicin
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 inconv3eniente 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.
63
Tabla Base y Tabla Extendida
FACTURA
FacNro*
FacFch
CliCod
FACTURA1
FacNro*
ProdCod*
FacLinCnt
CLIENTE
CATEGORIA
CatCod*
CatDto
CliCod*
CliNom
CatCod
PRODUCTO
ProdCod*
ProdNom
ProdPre
64
Tabla Base:
Tabla extendida:
Categora
Cliente
Categora
Cliente
Categora
Factura
Cliente
Categora
Factura1
Producto
Factura
Cliente
Categora
Producto
Factura
Factura1
Producto
65
ATRIBUTOS FORMULAS
66
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 sintxis 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.
67
Clasificacin
Horizontales
Una o varias expresiones aritmticas condicionales.
Verticales
SUM
COUNT
Aggregate / Select
Select
Max, Min, Find
Aggregate
Sum, Count
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.
68
Fmulas Horizontales
Atributo = <Expresin> if <Condicin>;

<Expresin> if <Condicin>;
:
<Expresin> Otherwise;
<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 fmula 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.
69
Fmulas Horizontales
Ejemplo:
TRANSACCION
TABLA
CliCod*
CliCod*
CliNom
CliNom
CliTotCmp
CliTotCmp
CliTotPgo
CliTotPgo
CliSdo = CliTotCmp- CliTotPgo
Un atributo puede definirse como fmula 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 objeto 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.
70
Importe de la Lnea de la Factura

FACTURA
FacCod*
FacFch
CliCod
CLIENTE
CATEGORIA
CatCod*
CatDto
CliCod*
CliNom
CatCod
FACTURA1
PRODUCTO
ProdCod*
ProdNom
ProdPre
FacCod*
ProdCod*
FacLinCnt
FacLinImp = FacLinCnt * ProdPre
if FacLinCnt <= 100;
(FacLinCnt * ProdPre * 0.9) if FacLinCnt >100;
En el ejemplo, definimos al importe del producto en la factura (FacLinImp)

como una frmula horizontal, por lo cual dicho atributo no est almacencado
en la tabla Factura1.
71
Frmulas Verticales
SUM - COUNT
Sintxis:
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.
Estas frmulas se utilizan cuando el valor de un atributo se obtiene sumando o
contando filas de una tabla que est directamente subordinada (es decir, cuando
las filas pertenecen a una tabla que 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 este almacenada, puede ocasionar en algunos casos,
problemas de performance debido al tiempo que puede demorar el reclculo.
Esto depender de la cantidad de registros que se sumen / cuenten.
Para evitar este inconveniente, Genexus provee la posibilidad de definir a la
frmula vertical 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.
72
Frmulas Verticales
SUM - COUNT
Clculo del subtotal de la Factura
Factura:
FacNro*
FacFch
CliCod
FacSubTot = SUM(FacLinImp)
Factura1:
FacNro*
ProdCod*
FacLinCnt
FacLinImp = FacLinCnt * ProdPre
Factura
1
Factura1
FacSubTot y FacLinImp no estn almacenados.

Equivalencia entre SUM redundante y regla ADD
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 est 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.
73
Frmulas Verticales
Slo se puede definir entre atributos de tablas directamente
subordinadas
N
FACTURA
FacSubTot = SUM(FacLinImp)
1
FacLinImp
SUM (att)
CLIENTE
SUM(att)
No permitido
FACTURA1
Puede ser Frmula
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.
74
Frmulas Aggregate/Select
Son frmulas que permiten buscar, sumar, contar
atributos que cumplan determinadas condiciones, en
cualquier tabla del modelo.
Aggregate
Sum
Count
Select
Max
Min
Find
Frmulas Aggregate
Sum
.- Suma condicionalmente atributos de cualquier tabla del modelo
Count .- Cuenta condicionalmente filas de cualquier tabla del modelo
Frmulas Select
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
75
Frmulas Aggregate/Select
Sintxis
atrib = Sum | Count (<att>, <cond. bsq.>, <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 )
Max ( atributo a maximizar, condiciones de maximizacin, valor por defecto en
caso de no encontrar quien cumpla con las condiciones, valor de retorno en caso
de encontrar)
Find (atributo a buscar, condiciones de bsqueda, valor por defecto en caso de no
encontrar quien cumpla con las condiciones)
76
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 retorno 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
Para distinguirlas en los listados
Verticales - SUM y COUNT todas las letras en maysculas
Aggregate - Sum y Count slo la primer 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 Aggregate:
Total de productos con descuento en la factura:
Factura
FacNro*
FacFch
CliCod
FacTotArtDscto = Count(ProdCod, FacDscto > 0)
77
Factura1
FacNro*
ProdCod*
FacLinCnt
FacDscto
FacLinImp
FacNro ProdCod FacDscto
1
10
20
FacTotArtDscto = 2
78
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.
Sintxis:
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 dolar del da.
La tabla de cotizaciones no tiene ninguna relacin con la de documentos.
Documentos
Cotizaciones
DocNro*
MonCod*
DocFch
MonFch*
DocImp
MonCot
DocImpDolar = DocImp / DocCotDolar

DocCotDolar = Find(MonCot, MonCod = U$S .and. MonFch = DocFch)
79
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.
Sintxis:
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.
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
Cotizaciones
DocNro*
MonCod*
DocFch
MonFch*
DocImp
MonCot
DocImpDolar
DocCotDolar
80
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:
DocCotDolar = Max(MonFch, MonCod = U$S .and. MonFch <= DocFch, ,
MonCot)
Fecha del Documento 15/01/94, le corresponde la cotizacin del da 13/01/94.
MonFch
MonCot
10/01/94
100
11/01/94
110
12/01/94
112
13/01/94
115
16/01/94
117
81
Min
Atributo = Min(<Atributo a Minimizar>, <Condicin de minimizacin>, <Valor por
defecto>, <Atributo a Devolver>) IF <Condicin de disparo>
Esta funcin determina el mnino 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.
Documentos
Cotizaciones
DocNro*
MonCod*
DocFch
MonFch*
DocImp
MonCot

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
82
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
Cotizaciones
(Tabla de partida)
(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 cuentan o suman los valores que estan en "memoria,
es decir, no recorren la tabla subordinada de nuevo, en caso de insertar, actualizar o
eliminar una lnea.
Las frmulas Aggregate/Select en cambio, recorren cada vez los registros para hacer el
reclculo.
Las frmulas Verticales pueden almacenarse en forma redundante y GeneXus se
encargar de mantenerlas actualizadas.
83
USO DE LA FORMULA 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)
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 )
84
USO DE LA FORMULA MAX( ).

FacProdPre = Max(ProdFch, ProdFch <= FacFch, 0, ProdPre)
Fecha de Factura: 10/10/93

Precio correspondiente: 220
Cdigo de Producto
1021
1021
1021
1021
1022
1022
1022
1022
Fecha Aumento Precio

10/08/89
20/11/90
03/10/92
15/10/95
10/08/89
20/11/90
03/10/92
15/10/95
Valor del Producto

200
210
220
230
100
110
120
180
Atributo a Maximizar..... ProdFch

Condicin....................... Factura1.ProdCod = Producto1.ProdCod (cond. implcita).
El mximo valor de ProdFch <= FacFch (cond. explcita).
Atributo a devolver........ ProdPre
Valor por defecto.............0 , si no se encuentra ningn registro que cumpla la
condicin.
85
Ejemplo
Transaccin de Cotizaciones
MonId*
CotMes*
MonDsc
(CotDia*
CotImp)
Transaccin de Asientos
AsiNro*
AsiFch
AsiMes
AsiDia
(AsiIdLin*
MonId
AsiImpME
AsiImpNS
AsiTipDH
CtaId
AsiFndCot)
Hacer lo siguiente:
A. Buscar la cotizacin de la moneda para la
fecha del Asiento.
B. En caso de que no exista, dar un aviso y
buscar la ltima ingresada anterior a la fecha
del asiento.
86
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)
if MonId<>NS;
1 otherwise;
87
B.
Transaccin de Asientos :
AsiNro*
AsiFch
AsiMes =Month(AsiFch)
AsiDia =Day(AsiFch)
(AsiIdLin*
MonId
AsiImpME
AsiImpNS = AsiImpME*AsiFndCot if AsiFndCot<>0;
AsiImpME*AsiMaxCot if AsiMaxCot<>0;
1 otherwise;
AsiTipDH
CtaId
AsiFndCot a=Find(CotImp, CotMes=AsiMes .and. CotDia = AsiDia)
if MonId <> 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;
88
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.
89
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).
90
En el ejemplo:
Transaccin de Cotizaciones:
MonId*
CotMes*
Given : MonId
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)
if MonId <> NS;
1 otherwise;
En la frmula AsiFndCot, est implcita la condicin de que

Asiento1.MonId = Cotizac1.MonId
Esto se refleja en la navegacin como Given: MonId
91
3.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 Retorno
De otra forma:
<Atr.Frm.> - Frmula Invlida
Es importante aclarar que los atributos involucrados en la frmula Aggregate

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.
92
Ejemplo de determinacin de la tabla sobre

la cual buscar:
X = Find( A , B = C .and. D = 4 .and. E = F , 0 )
Atributos de la tabla extendida de X
93
Ejemplo de determinacin de la tabla sobre

la cual buscar:
Deben pertenecer fsicamente a una misma tabla
X = Find( A , B = C .and. D = 4 .and. E = F , 0 )
Atributos de la tabla extendida de X
94
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
FacLinImp
FacSubTot
= frmula MAX
= FacLinCnt * FacProdPre
= 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
95
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
RengImpNS
RengImp
RengTipDH
CtaCod )
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 estan en
"memoria". Las aggregate/select no.
96
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 estan 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 FISICAMENTE en la tabla de llegada
5. Las frmulas agg/sel no se pueden definir como redundantes. Las verticales s.
97
COMUNICACION
ENTRE OBJETOS
98
Objetos GeneXus
TRN
RPT
PROC
MENU
WKP
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.
99
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 retornar 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 pueden hacer.
Esta diferencia existe SOLAMENTE en el generador Fxp 2.6 y 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.
100
Cul es la convencin usuada para el nombre de los

objetos GeneXus en las llamadas?
Objeto
Prefijo
Transaccin
T
Procedimiento
P
Reportes
R
Work Panel
W
Men
M
Web Panels
El nombre se trunca a:
7 caracteres
7
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.
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(RImpFac, FacNro) if insert .and. after(TRN);
donde ImpFac es el nombre del Report que imprime la factura recibida como
parmetro.
101
Call
Sintxis
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 Call 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 call 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 workpanels) se va a ejecutar proceduralmente en el lugar donde fue escrito.
102
Call - Regla Parm

La regla PARM tiene como funcin declarar los parmetros en
el objeto llamado.
Sintxis: Parm(atributo/variable);
Ejemplo: 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.
103
Udp
Sintxis
En reglas de Transacciones
<Att|&var> = Udp(nom-prog,par1,...,parn) if (condicin);
En Frmulas:
<Att> = Udp(nom-prog,par1,...,parn) if (condicin);
En el layout de los reportes, y en los eventos de Work Panels
o Transacciones:
<&var> = Udp(nom-prog,par1,...,parn)
En el program source de un procedimiento:
if (condicin)
<Att|&var> = Udp(nom-prog,par1,...,parn)
endif
La Udp ejecuta el objeto o programa nom-prog que retornar un valor que

ser asignado a un atributo o a una variable dependiendo del caso.
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.
104
Udp - Regla Parm

El ltimo parmetro en la regla parm es el valor de
retorno.
Ejemplo:
parsal = udp(PAltaCli, par1, , parn)
En las Rules de PAltaCli poner:
parm(par1, ..., parn, parsal );
Al igual que en los programas llamados con call, en los programas llamados por
UDPs se deben 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 retorno).
Ejemplo:
Tenemos un procedimiento que calcula la calificacin de un funcionario
FunValCalificacion = Udp(PCalif ,FunId, FunFchIngreso );
En el procedimiento PCalif, tenemos las 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.
El ltimo parmetro especificado en la regla parm, cuando se est invocando al
objeto con UDP es de salida. El protocolo para el resto de los parmetros
depende de la implementacin, NO se debe esperar que sean de entrada/salida.
105
Ejemplo:
FacImpDesc = udp(Pcaldto, 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 retornar un valor. Este valor que retornan es el
ltimo parmetro en la regla parm del objeto llamado y no debe ser
especifificado 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
categoria del cliente.
Nota: El valor de retorno de una UDP / UDF de Genexus, es asignado a la
variable o atributo en cuestin, pero dicho atributo o variable no es pasado como
parmetro de ida.
Ejemplo:
&A = 1
&A = UDP(PXXX)
En este ejemplo, el procedimiento XXX devuelve &A , pero no se puede asumir

o esperar que reciba como parametro &A=1 , de hecho el valor de &A al
ejecutarse el procedimiento tiene valor nulo.
106
SUBRUTINAS
107
Comando SUB
Sintxis :
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 Panels, Reportes y Procedures.
108
Comando DO
Sintxis :
Do 'RoutineName'
Ejecuta la rutina RoutineName.
Disponible en Transacciones, Work Panels,
Reportes y Procedures.
109
ARBOL DE EVALUACION Y
EVENTOS
110
R.
F.
F.
F.
F.
Arbol de evaluacin
Add(FctTot, CliTotCmp) ;
FctTot = FctSubTot - FctDto + FctFleVal
FctDto = FctSubTot * CatDto
FctFleVal = MAX( FctFleFch, FctFleFch <= FctFch, ...
FctSubTot = SUM ( FctImp)
CliTotCmp
FctTot
F. FacImp = FacCnt * ArtPrc
R. Subtract(FctCnt, ArtStk) ;
R. Error( Stock Insuficiente) if ArtStk < 0 ;
FctDto
error (No hay Stock)
ArtStk
FctCnt
FctFleVal
FctSubTot
CatDto
FctImp
FctFch
ArtPrc
Arbol 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 Sub-Total, 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.
111
Es importante mencionar que cuando se encuentra un error se desarma el Arbol

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)
112
Alteraciones del orden de disparo

de las Reglas
Error
PrvCod*
FctNro*
Total
Calculado
...
FctTotIng
Total ingresado
( ArtCod*
Fact Impt
FctCnt
FctPrc
FctImp = FctPrc * FctCnt)
...
FctTotCalc = SUM (FctImp)
Total calculado
Total
Ingresado
Error('El total ingresado no coincide con el total calculado') if

(FctTotCalc <> FctTotIng) .and. after(level(ArtCod));
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 arbol 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 <> 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 lineas (a la salida
del nivel).
113
Entonces le marco el evento de disparo After(level(ArtCod))

Error('El total ingresado no coincide con el total calculado') if
FctTotIng) .and. after(level(ArtCod));
(FctTotCalc <>
Es importante mencionar que cuando se encuentra un error se desarma el Arbol 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.
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('El total de la factura no coincide con el ingresado') if

FctTotCalc;
FctTotIng <>
// CORRECTO
Error('El total de la factura no coincide con el ingresado') if FctTotIng <> FctTotCalc

.and. after(level(ArtCod));
114
Funciones booleanas que permiten cambiar el momento

de disparo de una regla
Level( Atributo)
Insert
After( Atributo )
Update
After(Insert)
Delete
After(Update)
After(Delete)
After(Confirm)
After(Level(Atributo))
After(Trn)
Son funciones lgicas que devuelven .T. or .F.

Level
Sintxis: Level(Atributo)
Retorna 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 tomaria el nivel del parmetro.
Ejemplo: Call(Pxxx, CliCod) if Insert ;
After
Sintxis: After(<Event>)
Donde <Event> puede ser :
<Att> | <Action> | Level(<Att>) | Trn | Confirm
After(Attribute)
Ejemplo: A = B * C if After(C);
Ejecuta la regla despus de aceptar el valor del atributo C.
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.
115
Insert, Update, Delete

Para condicionar el modo de disparo
After(Confirm)
Dispara la regla despus de haber confirmado los datos del nivel asociado pero antes de
haber realizado la actualizacin.
After(Insert)
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
CliSts
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(Insert) ;
call('pficha', CliCod) if After(Update);
call('pficha', CliCod) if After(Trn);
El cliente ya existe o ya se han grabado las modificaciones.
After(Trn)
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.
116
Reglas que ocurren en el mismo evento

Son disparadas en el orden en que fueron definidas
Ejemplo
call(' ') if After(Trn);
call(' ') if After(Trn);
Ejemplo
call('pgmname', CliCod, &flag) if After(Confirm);
error('
') if After(Confirm) .and. &flag = 'N ;
Para CALLs, ERRORs, y MSGs, 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';
v
Importante:
En los calls los parmetros son de ida/vuelta del punto de vista del lenguaje, pero
del punto de vista del especificador son slamente de ida. Es decir, para
determinar el rbol de evaluacin de reglas y frmulas, Genexus considera a los
parmetros de los calls como de ida.
En el ejemplo 2, si se escribieran las reglas en orden inverso, Genexus en el rbol
de evaluacin de eventos, las considerara en dicho rden (no determinara que la
regla error vaya despus del call, porque los parmetros del call son considerados
de ida).
117
En otras palabras, si se escribieran las reglas del ejemplo 2 en orden inverso, y la

&flag resultara negativa, el error no se disparara.
Si en lugar de utilizar CALL utilizramos UDP (siendo &flag el campo de salida)
el error se disparara despus del UDP, sea cual sea el orden de definicin, ya que
&flag sera claramente el output de la UDP.
118
Ejemplo de transaccion de dos niveles

Level CabFac
.....................................> reglas stand-alone
Trasmit Screen
....................................> evaluacin de reglas y frmulas segn rbol
Confirm Screen
....................................> reglas after(confirm)
Insert/Update/Delete
....................................> reglas after(insert/update/delete)

Level LinFac
Trasmit Screen
..........................> evaluacin de reglas y frmulas segn rbol
Confirm 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 (trn)
EndLevel
119
Eventos en las Transacciones

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 tecla.
La programacin dentro del evento sigue un estilo procedural.
120
Eventos explcitos en las

Transacciones
Evento Start
Evento User-Event
Evento After Trn
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 Trn: 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.
121
Evento Start
Sintxis:
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.
122
Evento Start
Ejemplos:
1.-
Event Start
&Mes1 = Enero
EndEvent
2.-
En el Evento Start de la transaccin de Facturas :

Event Start
call(PFindCli,&today, CliCod)
EndEvent
Parmetro de salida. Se instancia el Cliente. Se
accede slo a las Facturas de ese Cliente.
En el Evento Start no hay atributos disponibles como para ser evaluados y/o usados.
En el ejemplo 2, el parmetro CliCod es de salida, es decir vuelve cargado del
procedimiento. En este caso, queda instanciado el Cliente, o sea que acta como filtro.
En otras palabras, el comportamiento es el mismo que si se hubiera recibido en la
transaccin como parmetro al cdigo de cliente en el propio atributo (CliCod). Es
decir, parm(CliCod);
123
Eventos del Usuario

Sintxis:
Event User-event-name <Key>
Level <att>
Endevent
Ejemplo
Event Deuda Cliente 2
Level FacId
if .not. null(CliId)
call(wdeucli,CliId)
endif
Endevent
Este evento 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.
124
Evento After Trn

Event After trn
EndEvent
Ejemplo:
Event After trn
Return
EndEvent
Equivalente a la funcin After(trn), pero permite agrupar todas las acciones que se
deseen evaluar en el after(trn) sin tener que condicionarlas por separado (rules).
Ejemplo:
Event After trn
return
Endevent
Abandonar el programa una vez que se ejecut un ciclo completo de la transaccin.
125
Evento Exit
Event Exit
.
EndEvent
Se activa cuando el usuario abandona el
programa.
Ej: 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
En el Evento Exit no hay atributos disponibles como para ser evaluados y/o usados.
126
Rules / Eventos
En caso de conflicto de evaluacin entre reglas
y eventos de una transaccin, la regla se evala
primero.
Eventos:
Event After trn
.
return
End event
Rules:
call(tvenfac,FctCod) if after(trn);
Esta 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 despliege de la pantalla. El evento Start se evala al comenzar
el programa.
127
Ejemplos de uso de Eventos en las Transacciones

1. Desplegar el nombre de la organizacin en la pantalla al comienzo de la transaccin:
Event Start
&Orgnom = 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 retornar al programa llamador una vez que la transaccin haya sido
ingresada:
Event After trn
Return
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 trn
&Veces = &Veces + 1
Endevent
Event Exit
&Msg = 'El nmero de transacciones grabadas: + str(&Veces)
msg(&Msg)
Endevent
128
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.
129
Consideraciones
No se permite asignar valor a los atributos.
Start-Exit ---> Sin tabla base
User Event-After(trn) ---> Con tabla Base
Restricciones
No se permiten comandos asociados a otros eventos existentes en los work panels
(load, refresh,etc.).
Tener en cuenta que los momentos de evaluacin no estn asociados a modos de
evaluacin activos, por lo que no son vlidas las funciones como Insert, Update ,
Delete, After(Event), etc.
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.
130
REPORTES
Y
PROCEDIMIENTOS
131
Reportes y Procedimientos
Reportes
Procesos no interactivos de consulta de la base
de datos.
Procedimientos
Procesos no interactivos de actualizacin de la
base de datos.
Reportes
Definen 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
Definen 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.
132
Caractersticas
Definicin procedural
Definicin sobre la Base de Conocimiento
Independencia de la Base de Datos
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 protencia 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.
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.
133
Comando For Each

Sintaxis:
For Each [Order] [ Atr...Atr]
Where <Condition>
...
Where <Condition>
Defined 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.
Usando el FOR EACH se define la informacin que se va a leer de la base de datos, pero la forma de
hacerlo se basa en nombrar los atributos a utilizar y NUNCA se especifican nombres de tablas ni
nombres de ndices. Con este comando se define QUE atributos se necesitan y en qu ORDEN se
quieren recuperar, y GeneXus se encarga de encontrar COMO hacerlo.
El acceso a la base de datos queda especificado por los atributos que son utilizados dentro de un grupo
FOR EACH - ENDFOR. Para ese conjunto de atributos GeneXus buscar la tabla extendida que los
contenga (el concepto de tabla extendida es muy importante en este comando y sugerimos repasar su
definicin).
Order: Lista de atributos que indican 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, se crea el ndice 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.
Defined by: Al mencionar en esta clusula algn atributo secundario de la tabla que se desea recorrer,
dicho(s) atributo(s) participar(n) en la eleccin de la tabla base del For Each. 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 dems atributos mencionados en todo el For Each. Los atributos
mencionados en esta clusula no tienen ms peso que los otros atributos del For each. El objetivo de
esta clusula es permitir mencionar cierto(s) atributo(s) en el cuerpo del For each (sin actuar como
filtros, ni ordenar por ellos, ni imprimirlos) sino que slo se desea(n) referenciar en el For Each para
que participe(n) en la determinacin de la tabla base.
134
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:
En base a la definicin realizada para el reporte, GeneXus determina automticamente lo siguiente:

1. Que las tablas que se deben 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 recorrida es CliCod y que el ndice que debe usarse es el Indice IClient
Todo esto en base a una especificacin que slo inclua los atributos a listar.
135
1. Cmo pudo GeneXus determinar qu tablas se utilizan en el reporte ?

Para esto se debe determinar en qu 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 almacendos
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 ?
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 conocimiento, 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.
136
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 <<----------------> Departametnos
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.
137
3. Qu orden y qu ndices deben utilizarse?

El reporte saldr ordenado por Cdigo de Cliente ( CliCod ) utilizando el Indice
IClient.
FOR EACH Client
Order : CliCod
Index : 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.
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 clusula Order del FOR EACH.
138
Ejemplo :Tabla Base y Tabla Extendida

FACTURA
FacNro*
FacFch
CliCod
FACTURA1
FacNro*
ProdCod*
FacLinCnt
CLIENTE
CATEGORIA
CatCod*
CatDto
CliCod*
CliNom
CatCod
PRODUCTO
ProdCod*
ProdNom
ProdPre
139
When None
Ejecutar determinado cdigo, cuando en un For
Each no se encuentra ningn registro.
Sintxis
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 .
140
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.
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). 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 y se sale del
dilogo del Report Wizard.
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.
El Wizard permite que los niveles tengan o no orden . El atributo que indica el orden
no tiene por qu ser el primero del nivel.
141
For Each paralelos

For Each // Facturas
EndFor
For Each // Recibos
EndFor
Navegaciones totalmente independientes.
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.
142
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
esten 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 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.
143
For Each anidados

Caso 1 : Tablas extendidas de los For Each
distintas pero relacionadas por uno o ms
atributos
For Each
[CliCod] [CliNom]
For Each
[FacNro] [FacTot]
Endfor
Endfor
Atributo relacin: CliCod
Cliente
CliCod
Facturas
Se instancia el orden CliCod en el For Each

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 )
END FOR
END FOR
144
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.
Producto Cartesiano: Para cada registro de la tabla base del primer For Each se recorre
toda la tabla asociada al For Each anidado.
145
Corte de Control
Caso 3 :
Procesar informacin por grupos.
Ej: Procesar facturas por cliente. Cada vez que cambia
el cliente se define un nuevo grupo.
For Each Orden CliCod
orden - determina
(tabla Factura)
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.
146
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
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.
147
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 (Item 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.
148
Diseo de la salida
MT
Header
...
End
PL
CP [nlinea]
Lineno [nlinea]
Eject
Noskip
Footer
MB :
End
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). Ej: 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.
149
Report Viewer
Permite:
Imprimir
Visualizar el reporte mientras se est generando
Paginado
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, almacenandose 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.
150
PROCEDIMIENTOS
151
Insercin de registros
Ejemplo:
Insercin en tabla de resumen de
ventas anuales
Tabla:
CliCod*
VtaAno*
VtaTot
New
CliCod = &CliCod
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 quisieramos aplicar un tratamiento especial para estos casos, podemos
usar el comando When Duplicate para decir que accin tomar cuando se detecta que el
valor de la clave en un alta ya existe en la tabla correspondiente.
152
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.
153
Delete
For Each
defined By FacFch
Delete
endFor
slo Tabla Base
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.
154
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

programador, 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, los atributos instanciados por el For
Each y no mencionados en el New son inferidos para la insercin del registro.
155
WORK PANELS
156
Work Panels
Definir consultas interactivas a la base de
datos.
Es muy flexible por lo que se presta para
mltiples usos.
157
Diferentes tipos de Paneles

-
Entry Panel
Display Panel
Single Choice Selection List
Multiple Choice Selection List
Action List
Las normas Common User Acces de IBM definen diversos tipos de pantallas,
estandarizando los dilogos con el usuario.
158
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.
159
Display Panel - Panel de Salida
Paneles de Despliegue
En estos paneles, 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).
160
Seleccin Unica/Seleccin Mltiple/Listas de Accin
Area Fija
Subfile
Teclas de
Eventos y
funcin
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 simultaneamente.
Lista de Accin
Se pueden elegrir acciones diferentes a aplicar a cada una de las lneas.
161
Comando For Each Line

Sintxis:
For Each Line
..
EndFor
Recorre todas las lineas

del subfile
En caso de querer recorrer slo las lineas del subfile

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 lineas del subfile, se ejecuta el cuerpo del For Each Line.
El comando For Each Selected Line permite recorrer slo las lineas que fueron
seleccionadas del Subfile.
Los generadores no visuales slo permiten seleccin nica.
En Visual FoxPro, no es posible seleccionar varias lineas en los grids a diferencia de
Visual Basic (es una limitacin de VFP, no del generador).
162
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
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-Panels 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 el evento se produce.
163
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 comunmente 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 subfile.
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 subfile 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 leidos 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 Defined 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.
164
Estructura de los eventos

Comienzo
Evento Start
Evento Refresh
Evento Load
Mostrar datos en
pantalla
Evento Enter
Evento 'User Defined'
Evento Exit
Fin
165
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 quisieramos 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: Esta regla es usada para indicarle a GeneXus cuales atributos o variables deben
incluirse en el subfile sin estar presentes en el mismo. Se usa cuando 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.
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 expecificado se
excede, se despliega el siguiente mensaje Number of lines exceeded xxxx .
166
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 del 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 subfile
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).
167
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:
For Each [ Tabla Base ]
Order: Atributos del indice 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.
168
Dilogo Modal/No Modal

Property Modal dialog
En transacciones y work panels (llamados).
Opciones:
Yes if parameters specified
Yes
No
Slo generadores Visuales.
Esta propiedad permite indicar para cada objeto, si utilizar dilogo modal o
no modal.
Dilogo modal significa que mientras el objeto llamado no se cierre, el
objeto llamador se mantiendr inactivo.
Dilogo no modal en cambio, significa que ambos objetos (llamador y
llamado) pueden estar activos al mismo tiempo, es decir que se puede alternar
entre uno y otro, trabajando con ambos simultneamente.
Los valores posibles de esta propiedad son:
Yes if parameters specified: Es la opcin por defecto. Significa que si el
objeto recibe parmetros, el dilogo
ser modal, mientras que si no
recibe parmetros el dilogo sera no-modal.
Yes: Dialogo modal.
No: Dialogo no modal.
169
SUBTIPOS
170
Subtipos
Ejemplo: Transferencias entre Bancos.
Atributos similares que cumplen roles diferentes.
Transaccin de Bancos:
BcoCod*
BcoNom
Cdigo de Banco
Nombre de Banco
Transaccin de Transferencia :
TrnNro*
TrnFch
Problema
BcoCod
Atributos
BcoNom
con el
BcoCod
mismo
BcoNom
nombre
TrnImp
Nmero de transaccin
Fecha
Banco Origen
Nombre del Banco Origen
Banco Destino
Nombre del Banco Destino
Importe
En el ejemplo, se necesita 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.
171
Transferencia:
TrnNro*
TrnFch
Subtipos
Bancos:
BcoCod*
BcoNom
TrnBcoOriCod
TrnBcoOriNom
TrnBcoDestCod
TrnBcoDestNom
Subtipo
TrnBcoOriCod
TrnBcoOriNom
Supertipo
BcoCod
BcoNom
TrnBcoDestCod
TrnBcoDestNom
BcoCod
BcoNom
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.
172
Subtipos: Grupos
Almacenado
TrnBcoOriCod
Inferido
TrnBcoOriNom
Grupo
TrnBcoOri
Almacenado TrnBcoDestCod
Inferido
Grupo
TrnBcoDest
TrnBcoDestNom
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.
173
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).
Los subtipos no se pueden definir redundantes
174
KNOWLEDGE
MANAGER
175
Distribucin
Se genera el archivo Respaldo.xpw en la raiz de la KB
176
Consolidacin
Pide el path del archivo .xpw a ser consolidado
177
BUSINESS
OBJECTS
178
Qu es un Business Object ?
Representacin de un objeto de la realidad:
producto, persona, factura, moneda, pais
Para su definicin se toman en cuenta: atributos
que definen al objeto, operaciones que le son
relevantes, cmo se relaciona con otros objetos.
Un Business Object es la representacin de un objeto de la realidad. Para su definicin se

toman en cuenta: qu atributos lo definen, qu operaciones le son relevantes y cmo se
relaciona con otros objetos.
Algunos ejemplos concretos de Business Objects son: producto, persona, factura, moneda,
pais.
Un Business Object es un objeto comunmente usado por distintos tipos de aplicaciones
(ejemplo de BO: persona) o por aplicaciones desarrolladas para un rea especfica (ejemplo de
BO: moneda).
Un Business Object no debe estar directamente "ligado" a ninguna aplicacin en particular, de
esta manera se asegura su portabilidad.
Cada Business Object es autocontenido, es decir, su definicin no depende de otros objetos,
sin embargo esta implementado de tal manera de que pueda interactuar con otros Business
Objects.
179
Cmo representar un Business

Object con Genexus?
Cada BO GeneXus es un folder que contiene
todos objetos necesarios para definir el
comportamiento y el uso de dicho BO:
Transacciones que definen objetos bsicos
zWork Panels de trabajo
zReportes
zProcedimientos que implementen operaciones
relevantes
z
180
Business Object GeneXus

Ejemplo: Business Object Paises
Cada BO es un folder que contiene todos objetos GeneXus necesarios para definir el
comportamiento y el uso de dicho BO.
181
Caractersticas de un BO
Independiente
zNo ligado a ninguna aplicacin
zStandard y simple
zFcilmente adaptable
zDocumentado
zBien testeado
z
182
Cundo usar BO?

Al crear nuevas aplicaciones
Al agregar nuevas funcionalidades a una

aplicacin existente
183
Ventajas de su uso
Reusabilidad :
aumenta productividad
disminuye esfuerzo de desarrollo
Proveer soluciones rpidamente

zFacilitar la ampliacin de las funcionalidades de
una aplicacin
zCompartir conocimiento
z
184
Algunos BO Genexus
Paises
zProductos
zPersonas
zMonedas
zTipos de IVA
zNumeradores
z
Disponibles en el Web Site de Artech
185
Distribucin de los BO
Exportar el folder que contiene el BO
Envar exportacin (xpw) por mail a webmaster@artech.com.uy
Datos importantes que deben ser incluidos en la documentacin

enviada:
Breve descripcion del BO (objetos

(objetos que lo componen y su funcionalidad)
funcionalidad)
Documentaci
ocumentacin adicional que se desee adjuntar.
adjuntar.
Autor
Fecha de ltima actualizaci
actualizacin
Versi
ersin de GeneXus con que se implement
implement
ARTech pondr disponible el BO en su Web Site.
186
OBJETOS PRIVADOS
187
Objetos Privados
Objetivo: proteger el conocimiento
Normalmente en una KB hay objetos que son el ncleo y que tienen

realmente el conocimiento que hace a la solucin y hay objetos
secundarios, que le dan forma a esa solucin.
A partir de la versin GeneXus 7.0 aparecen los objetos privados. El

objetivo de esta nueva caracterstica es facilitar el negocio del
conocimiento, permitiendo a quien lo licencia reservarse el control
exclusivo de ciertos objetos (llamados privados) que considere
necesario.
La idea es que el propietario de una KB, al momento de exportar

conocimiento (mediante el Knowledge Manager) seleccione aquellos
objetos que quiera privatizar, llamados objetos privados, los cuales no
podrn ser modificados por el comprador. Aquellos objetos que no se
privaticen seguirn siendo pblicos.
Se entiendo por objetos todos los objetos GeneXus como ser

Transacciones, Work Panel, Reportes, Procedimientos, etc., pero no
Tablas, ndices, Grupos, etc.
188
Objetos Privados
Al momento de distribuir, si existe algn
objeto privado se ingresar:
Copyright by: Derechos de autor del dueo del
objeto.
Buyer: Casa de software a la cual se esta
licenciando.
Purpose: Texto general.
Objetos Pblicos
Un objeto podr ser pblico sin restriccin alguna, en cuyo caso puede seguir
siendo utilizado libremente. En este caso no es necesario hacer nada con el
objeto.
Objetos Privados
En el caso de que el propietario del objeto decida definirlo como privado,
nicamente en la KB origen se podr acceder libremente y modificarlo. Los
dems usuarios (aquellos que licencien conocimiento de aquel) slo podrn
editar sus pantallas, ver el cabezal del mismo (Information) y generarlo.
Para definir un objeto como privado, se debe ir a Object/Information, en la
solapa Advanced, dnde se debe marcar el check Private Object.
Slo se puede marcar un objeto como Privado en diseo. En prototipo y
produccin no est habilitada esa facilidad ya que se heredar en la siguiente
actualizacin de ese modelo (impacto).
Esto slo indica que el objeto ser Privado, pero no se har ningn proceso
con l, hasta el momento de su exportacin (distribucin).
189
Objetos Privados
Operativa de los objetos privados: son
generables y algunas partes visibles y/o
editables
Si al momento de exportar, se seleccion algn objeto, se habilitar un

nuevo botn, Copyrigth Notice, para ingresar la siguiente informacin:
Copyright by: Derechos de autor del dueo del objeto.

Buyer: Casa de software a la cual se esta licenciando.
Purpose: Texto general.
Esta informacin, en un XPW, es la misma para todos los objetos privados,

ya que se agrupa a una aplicacin.
Recin luego de ingresar esta informacin, el XPW ser encriptado en su

totalidad, incluso aquellos objetos pblicos que tambin se hayan
seleccionado.
Si no se indica la informacin de Copyright, se har una distribucin
normal y el XPW no quedar encriptado. Es decir que si bien pueden haber
objetos privados, para que efectivamente sean encriptados, se debe
ingresar la informacin de Copyrigth.
190
EFICIENCIA Y PERFORMANCE DE
LAS APLICACIONES
191
Puntos a Considerar
Optimizacin de la Entrada-Salida
Uso de Calls
Open y Close de archivos
Uso de Indices Temporales
Optimizacin de Entrada-Salida:
Dado que el acceso a las tablas es costoso, vamos a ver cmo minimizarlo.
Uso de Calls:
Veremos cundo debemos empezar a preocuparnos 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.
192
Optimizacin de Entrada-Salida
Definicin de Filtros
Peor Estrategia
Begin of File
Estrategia Optima
Begin of File
READ
READ
READ
READ
READ
READ
READ
< Start Point
READ
< End Point
READ
READ
READ
READ
READ
READ
READ
End of File
End of File
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; asi pueden ser por ejemplo WHEREs en un FOR EACH, condiciones en una
frmula Aggregate/Select, parametros , 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 mas cerca posible del primer registro del
grupo que cumple las condiciones y desde alli 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 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.
193
Definicin de Filtros
Clusula Where en For Each

Conditions en Prcs, Rpts, Wkps.
Parm() en Trns, Prcs, Rpts, Wkps
Where:
La clausula "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
W HERE 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 prevee 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: un procedimiento tiene la siguiente regla: Parm(CliCod);
Esta regla es equivalente a tener: parm(&Cliente);y la condicin:CliCod = &Cliente;
194
Definicin de la estrategia de acceso.

1ero.) Se define el orden en que se recorrer el
archivo
2do.) Se elige el punto de comienzo (Starting point)
3ero.) Elegir la posicin final ( End Point).
4to.) 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 contnuacin 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.
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.
195
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
<----- Starting Point Read
Ball
Read
King
<----- Ending Point Read
Ander
&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.
196
Orden de Recorrida
Importancia del Orden en que se leen los registros.
Ejemplo: Condiciones de Filtro no compatibles con el Orden
For each Order CliNom
Where CliCod >= &CodIni .and. CliCod <= &CodFin
...
Endfor
Cod Nombre
*3 Ander
<----- Starting Point
5 Ball
6 Churchill
1 King
*4 Smith
*2 William <----- Ending Point
Read
Read
Read
Read
Read
Read
&CodIni = 2
&CodFin = 4
197
Orden de Recorrida
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*
Tipos TypCod*
CliNom
TypNom
TypCod
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
198
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.
199
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 ( >=)
Igual (=)
Si el orden es descendente
Menor (<)
Menor o Igual (<=)
Igual(=)
Las condiciones deben estar relacionadas por .And.
200
Posicin de Comienzo
Ejemplos:
Orden: A B C
Condiciones : A>= 5 .and. C > 3
Posicin de comienzo: A>=5
Orden: A B C
Condiciones : A > 5 .and. B < 2 .AND. C > 3
Posicin de comienzo: A > 5
201
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.
202
Diagrama de Navegacin
For each CliCod
Where CliCod >= &IniCli .AND. CliCod <= &EndCli
[ CliCod
] [CliNom
]
Endfor
FOR EACH Clientes
Order : CliCod
Index : ICliente
Navigation filters:
Start from:
CliCod >= &IniCli
Loop While
CliCod <= &EndCli
Constraints:
CliCod >= &IniCli .AND. CliCod <= &EndCli
---->> CLIENTES ( CliCod )
END FOR
203
Diagrama de Navegacin
For each CliCod
[ CliCod
]
Endfor
[CliNom
FOR EACH Clientes

Order : CliCod
Index : ICliente
Navigation filters:
Start from:
First record
Loop while:
Not end of table
---->> CLIENTES ( CliCod )
END FOR
204
Tambin influyen en la performance:
Calls
Apertura y Cierre de Archivos
Uso de Indices 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 indices utilizados. En
NTX e IDX, si es necesario usar un indice que esta abierto, primero se cierra y luego se
vuelve a abrir. Si es CDX, no cierra el indice 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.
205
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(), Usercls(), 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
indice que se est utilizando.
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
retornar, el programa llamado cierra todas las tablas que us. El programa llamador, despus de
retornar 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)
Pgma X
Open A, B, C
Call Y
Pgma Y
Open D,E
....
b) Pgma X
Pgm Y
Open A, B, C
Open D, E
Call Y
Close B y Open B
Close D, E
....
Close A B C
Close B, D, E
Open B
Close A,B, C
206
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.
Pgma X
Pgma Y
Open A, B, C
Open D, E
Reposiciona Indices B,C
Call Y
....
Restaura todo a como
Close D, E
estaba antes del call

...
Close A, B, C
Indices Temporales:
En Client/Server los indices temporales se construyen ms rapidamente 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 indice 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.
207
MULTIPLES FORMS
208
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.
20945
41
42
Form Classes
Create 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.
Create 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.
210
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.
El default de un form puede ser en base a otro form o en base al default de
Genexus.
211
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
212
STYLES
213
Propiedades de los Styles

Permiten la definicin de standards.
La definicin es por tipo de objetos
(transacciones, work panels, 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 Styles 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
214
Definicin de un Style
Object/New Object.
Ejemplo de un Style de transaccin.
215
Style
Style Area
Data Area
Este espacio se puede

usar para poner
comentarios
Se ven en los forms unas lneas que definen diferentes reas. Lo que est dentro
del rectngulo es la denominada "Data Area" (rea de datos). El resto del form es
la "Style Area". A su vez, la Style Area est dividida en 8 sectores (ver figura).
Cuando el desarrollador empiece a usar styles las lineas de la data area
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 area 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.
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.
216
Tres Tipos de Controles

Controles que vienen de la default Data Area
Los que vienen del Style
Controles del Usuario
Los que agrega el usuario al objeto.
Los que vienen de la data area del Style.
Los controles en la Data Area 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.
217
Creacin de un objeto basado en un Style

Al momento de crear el objeto, en el
Information/Style se elige el Style deseado.
Relacin entre objeto y 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 area slo si el objeto es un 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.
218
Creacin de un objeto basado en un

Style
Las lneas de la data area estan en azul indicando que se perdi el dinamismo
con la default data area.
Las lineas de la style area estan en rojo indicando que existe dinamismo entre
la style area de la transaccin de clientes y la style area del style.
NOTA: Se puede perder el dinamismo con la style area 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).
219
Cmo asociar Styles

a objetos existentes
Opciones
Object/Information/Style
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 Style 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 menu 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.
220
Qu pasa con el dinamismo ?

Cuando se pierde ?
Cuando se modifican
los controles que vienen de la DDA
los controles que vienen de la style area del Style
el seteo de una property
Opciones:
Edit \ Default Data Area
Edit \ Reapply Style Form
Si se modifica un control que figura en el form como resultado del clculo de

la Default Data Area (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 Area). Anlogamente, si
se modifica cualquiera de los controles que vienen de la style area 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 Area o en el Style Area) 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 Area o con el Style, se puede
recuperar utilizando las opciones de menu Edit Default Data Area y Edit
Reapply Form Style, respectivamente.
221
Cambio en el tamao
de la Data area
Para agrandar o achicar la data area, slo sirve
mover los bordes derecho y/o inferior.
El form del Style tiene la capacidad de adaptarse al tamao de la Data Area del
objeto en el que se lo utiliza. Cuando la Data Area se agranda (ya sea debido al
calculo de Default Data Area o a la accion del usuario) el mecanismo de
aplicacion dinamica del Style se encarga de agrandar tambien el frame, y
mover hacia la derecha y hacia abajo los controles que estan a la derecha y
abajo de la Data Area respectivamente. Similar comportamiento se observa al
achicar la Data Area (se achica el frame y los controles se mueven hacia la
izquierda y hacia arriba).
El tamao de la data area definido en el form del style (y por lo tanto tambin
el tamao del frame) se considera como tamao mnimo de la data area del
form del objeto.
222
Consideraciones para
el diseo de Styles
Los controles que queden dentro de la Data Area del Style
son considerados como Controles del usuario.
Definir forms 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)
223
Master Style
Objetivo: Style default
Se define por modelo
Por tipo de objeto salvo:
Prompt - Workpanel
Report Procedure
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 caracter 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 styles 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 Panels como para
Prompts.
224
Master Style
Precedencia:
Style asociado
Master Style
Default
225
MENU BAR Y TOOL

BAR
226
Tipo de objeto Menu Bar

Para definicin de Menu Bar y Tool Bar
Object/New Object/Menu Bar
Add y Delete de Items

Edit/Insert y Edit/Delete respectivamente
Subitems
Personalizacin del item Help/About
Slo en generadores grfico:

VB, VFP, JAVA
Cada objeto GeneXus que tenga Form puede tener su propio Menu Bar y Tool Bar.
Para definirlos, se usa el tipo de objeto GeneXus Menu Bar.
Para agregar o borrar opciones (items) del Menu Bar, se utilizan las opciones
Edit/Insert y Edit/Delete respectivamente.
La definicin de la Tool Bar es exactamente igual a la del Menu Bar, slo que en los
items de la Tool Bar se debe definir tambin el bitmap correspondiente.
El item 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.
227
Tipo de objeto Menu Bar

Definicin de Eventos
Cada item sin subitems puede tener asociado un evento
(Object/Events).
Nombre del evento: Event Menubar.nombre del item
Son generales
No se permiten atributos.
En transacciones y work panels
Property Menubar : *Default, *None, Menu Bar existente
Pueden programarse eventos para los items de la
Menu Bar.
Son particulares
Se permiten atributos.
Los eventos definidos en el Menu Bar son generales, por lo cual se ejecutarn
en todos los objetos que utilicen el Menu Bar. Por esta razn es que no se
permite el uso de atributos en los mismos.
Luego de definido un Menu 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 Menu Bar definido, se
pueden programar eventos para los items del Menu Bar . Como estos eventos
son particulares de cada objeto, s se pueden usar atributos.
Si un mismo evento se programa en el Menu Bar y en el objeto, se ejecuta el
del objeto.
228
PROPIEDADES, EVENTOS
Y METODOS ASOCIADOS A LOS
CONTROLES
229
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
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.
230
Propiedades de los Controles

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.
231
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
232
Dilogo:
Select Property
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
233
EVENTOS EN CONTROLES
Insert/Events
Permite asociar Eventos a cada Control.
DblClick
Click
RightButton
IsValid
OnLineActivate
DblClick:
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.
234
Evento OnLineActivate
Evento asociado al control subfile
Se dispara cuando se activa una lnea en el subfile:
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.
235
Eventos en Controles
Form:
Permite seleccionar para que tipo de form se le asociar una 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.
236
METODOS
Se aplican a los controles.
Sintxis:
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
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.
237
OBJETOS MAIN
238
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.
239
Llamadas a objetos Main
Cuando desde un objeto se llama a otro objeto

que es Main:
GeneXus genera un call a un ejecutable (en lugar de un
call comn)
Son compilables
Cuando desde un objeto se llama a un Main, GeneXus genera un call a un

ejecutable.
240
Qu ocurre si un objeto que no es

Main pasa a serlo?
Ejemplo:
Trn A
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 PImpClis
El Proc ImpClis pasa a ser Main:

En los programas asociados a la Trn A y Wpanel B GeneXus
debera cambiar el call al programa PImpClis por un call a un
ejecutable ImpClis, con lo que deberamos regenerar estos
objetos.
Para evitar la regeneracin de todos los objetos llamadores:

GeneXus usa un concepto llamado STUBS
241
STUBS
Cuando el objeto ImpClis 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
Genera otro programa que es el que contiene la lgica del objeto
ImpClis y ser el principal del ejecutable.
Esto permite no tener que regenerar todos los objetos que llaman
al objeto ImpClis.
Al programa que contiene slo el llamado al ejecutable se le
denomina STUB.
242
STUBS
Tenemos entonces 2 programas generados, asociados a un mismo objeto GX.
Para la denominacin del programa STUB se siguen las convenciones de siempre
(P=Procs, W=Work Panels etc.)
Para la denominacin del programa que ser el principal del ejecutable (el que contiene
realmente el cdigo) se usan las siguientes convenciones:
Transaccin N
Work Panel
U
Report
O
Procedure
A
Menu
L
Web Panel
H
Siguiendo con el ejemplo, para el objeto ImpClis, GX generar 2 programas: PImpClis.xxx
y AImpClis.xxx (xxx= extensin del generador corresp.) y el ejecutable se llamar
AImpClis.exe
243
DATA VIEWS
244
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
245
DataViews - Archivos Externos

Para trabajar con Archivos Externos en GeneXus
tenemos dos posibilidades:
DATA VIEWS
Sin tabla Asociada
Con tabla Asociada
246
Data Views
GENEXUS
DA
DATA VIEW
DEFINITION
EXTERNAL
ENVIRONMENT
TABASE
INTERNAL
TABLE
EXTERNAL
FILE
SIN TABLA
ASOCIADA
EXTERNAL
FILE
CON TABLA
ASOCIADA
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:
- Codigo*
- 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.
247
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.
248
Definicin de un Data View
Assoc. table: En este punto se debe seleccionar la tabla interna asociada al Data
View.
Composition: Aqu se deben indicar las correspondencias entre los atributos internos
y los campos externos.
[Nombre Interno]
[Nombre Externo]
[Nombre Interno]
[Nombre Externo]
[Nombre Interno]
[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).
249
Composition
Ejemplo:
Dados los siguientes Archivos Externos:
CLIENTES
PRODUCTO
Codigo*
CliNom
CliDir
Codigo*
ProDsc
ProPre
Composition
CliCod 'Codigo'
CliNom
CliDir
Composition
ProCod 'Codigo'
ProDsc
ProPre
Se uniformiza la nomenclatura
250
Indices
Name: Nombre del ndice que GeneXus usar en la aplicacin.

Nota: Este es un nombre interno del ndice, es decir, no tiene por qu ser el nombre
del ndice fsico. Genexus hace un mapeo entre el nombre interno del ndice y el
nombre externo de acuerdo a la composicin del mismo.
Unique o Duplicate: Si permite tener o no llave duplicada.

Compositions: Es la lista ordenada de campos que componen al indice. Los
atributos mencionados ac deben ser parte de la Composition del Data View.
251
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.
252
Platform Specific Information /

Edit
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 referentes a un archivo de este tipo.
253
Associated Table
GENEXUS
DEVELOPMENT
ENVIRONMENT
DATA VIEW
DEFINITION
GENEXUS
MODEL
EXTERNAL
ENVIRONMENT
----INTERNAL
TABLE
INTERNAL
INDEX
EXTERNAL
FILE
-----
----------
------------------
EXTERNAL
INDEX
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.
254
Associated Table
Tabla Interna = Tabla Externa
------INTERNAL
TABLE
---
EXTERNAL
FILE
-------
Existe una relacin de uno a uno entre los atributos de la Tabla Interna del Data View
y los del Archivo Externo.
255
Associated Table
Tabla Interna < Tabla Externa
Not Accessed
--INTERNAL
TABLE
EXTERNAL
-----
FILE
---
Los atributos definidos para la Tabla Interna y para el Data View coinciden, pero el
Archivo Externo tiene atributos no declarados en el Data View. Estos atributos no
pueden ser accedidos.
256
Associated Table
Tabla Interna > Tabla Externa
GENEXUS
DATABASE
DATA VIEW
DEFINITION
EXTERNAL
ENVIRONMENT
---INTERNAL
FILE
NOT ALLOWED
EXTERNAL
FILE
--------
Si la Tabla Interna tiene ms atributos que el Archivo Externo no es vlida la

asociacin.
257
Associated Table
Tabla Interna > Tabla Externa
USO DE SUBTIPOS
GENEXUS
DATABASE
EXTERNAL
ENVIRONMENT
DATA VIEW
DEFINITION
----
CliCod*
CliNom
ALLOWED
INTERNAL
TABLE A
---
Codigo
Nombre
EXTERNAL
FILE
---Subtype
CliCodSub*
CliNom
CliDir
CliEMail
INTERNAL
TABLE B
En el ejemplo, se pide tener tambin como datos del Cliente el E-Mail y la direccin.
258
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.
259
Arbol de Definicin
Archivos
Externos
Data View
Definicin Global
CON
Tablas Asociadas
Asociacin
Dinmica
SIN
Tablas Asociadas
Asociacin
Definida
260
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.
261
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
Java
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.
262

Curso GeneXus Parte 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Curso GeneXus Parte 1

Uploaded by

Copyright:

Available Formats

Curso GeneXus

Copyright (c) ARTech Noviembre 2000

WORK PANELS ...................................................................... 156

CURSO GENEXUS PARTE II

DESARROLLO DE APLICACIONES CLIENT/SERVER

DESARROLLO DE APLICACIONES PARA INTERNET

CURSO DATA WAREHOUSING

Nuestra tarea como profesionales de la informtica es desarrollar y mantener

El primer problema al que nos enfrentamos en el desarrollo de aplicaciones es la

La primera tarea, generalmente, es el anlisis de datos.

En caso de que desearamos posteriormente realizar la integracin de esos mdulos es

Entre las alternativas ms usadas se destacan la programacin en lenguajes de 3a.

Podra argumentarse en contrario, como a menudo se ha hecho con las herramientas de

Los fundadores de ARTech han desarrollado una amplia actividad de consultora

Utilizando GENEXUS, la tarea bsica del analista es la descripcin de la realidad.

Al crear un nuevo sistema o proyecto Genexus, se crea una nueva Base de

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

Sistematizacin del conocimiento

Veamos ahora con ms detalle el proceso de desarrollo de una aplicacin con

Inferencia de la Base de Datos

A partir del conocimiento especificado a travs de las transacciones, GENEXUS

Creacin de la Base de Datos

GENEXUS genera automticamente los programas necesarios para crear la base de

Generacin de los Programas de la

GENEXUS genera automticamente, a partir de la Base de Conocimiento, los

Resultado final en la Etapa de Desarrollo

(TRN, RPT, PROC, WKP y MNU)

En este estado , la aplicacin est pronta.

Las Visiones de los Usuarios Cambian

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

Anlisis de Impacto Totalmente Automtico

Algunas veces, la nueva base de datos coincide con la anterior, en

Generacin de Programas de Reorganizacin

Si el analista ha dado el visto bueno a la reorganizacin, GENEXUS

Anlisis Automtico del Impacto de los

Generacin Automtica de Nuevos

GENEXUS genera /regenera automticamente los programas

Nueva Realidad , con los cambios en la

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

Mltiples Plataformas de ejecucin a partir de una nica

ARQUITECTURAS FILE SERVER

La construccin automtica de la Base de Datos y programas a partir de una

El trabajo consiste de dos ciclos: el Ciclo de Prototipacin y el Ciclo de

La construccin automtica del soporte computacional nos dar la gran

Toda comunicacin es suceptible de errores:

Ahora vamos a concentrarnos en cul es la forma prctica utilizada por

Notacin GeneXus para Transacciones

El siguiente paso es encontrar una forma de notacin adecuada para GeneXus.

Definicin del diseo de Base de Datos en 3era Forma Normal

Definicin de las transacciones Clientes y Productos

La definicin de dos nuevas transacciones: Clientes y Productos han determinado la

GeneXus establece las relaciones por los nombres.

Conceptos diferentes no deben tener el mismo nombre.

Es conveniente usar padrones para los

Nomenclatura GIK - Nombre del Atributo

ARTech ha definido un Standard para la nomenclatura de atributos, el GIK

Ejemplo de Nomenclatura GIK

El objetivo de los dominios es permitir usar definiciones de atributos

Pueden incluir: atributos, variables, constantes y

Se utiliza para disear la pantalla (form) en forma grfica. Mientras se est

Check Box de Hide Tabs ==> Para diseo de Wizards

Slo para los generadores visuales.

Disponible solamente en los generadores

Esto es para los generadores Windows.