manual de genexus[1]

7/31/2019 Manual de Genexus[1]

1/129

GENEXUS

Diseo de Aplicaciones

Copyright ARTech Consultores 1988-1999. All rights reserved.


2/129


3/129

TABLA DE CONTENIDO

INTRODUCCIN............................................................................................................ 1

DESARROLLO DE UNA APLICACIN ..................................................................... 3

SISTEMA DE COMPRAS PARA UNA CADENA DE FARMACIAS. ......................... 3

DEFINIR EL OBJETIVO ...................................................................................................... 3DEFINIR EL EQUIPO DE TRABAJO ...................................................................................... 4OBTENER UNA IMAGEN GLOBAL ...................................................................................... 4DEFINIR EL ALCANCE DE LA APLICACIN ......................................................................... 5MANTENER EL DISEO SIMPLE......................................................................................... 5ORIENTARSE A LOS DATOS .............................................................................................. 5

DISEO DE TRANSACCIONES................................................................................... 7

ESTRUCTURA DE UNA TRANSACCIN............................................................................... 9Atributos .......... ........... ........... .......... ........... .......... ........... .......... ........... .......... .......... 10

Dominios ......... ........... ........... .......... ........... .......... ........... .......... ........... .......... .......... 11

Atributos Clave.............. ........... ........... .......... ........... .......... ........... .......... ........... ...... 11

Relacin entre la estructura y el modelo de datos .......... .......... ........... .......... .......... 12

Tipos de controles .................................................................................................... 14

Definicin de la transaccin de pedidos ........... .......... ........... .......... ........... .......... ... 16

Niveles de una transaccin......... .......... ........... .......... ........... .......... ........... .......... ..... 18

Tipos de relacin entre los objetos........................................................................... 22

FORM DE UNA TRANSACCIN ........................................................................................ 23Dilogo full-screen............ ........... .......... ........... .......... ........... .......... ........... .......... ... 24

Dilogo campo a campo ....... .......... ........... .......... ........... .......... ........... .......... .......... 25

Barra o Botones de Men................ ........... .......... ........... .......... ........... .......... .......... 25

Atributos de entrada y atributos de salida ......... ........... .......... ........... .......... ........... . 26

Facilidad de Prompt................................................................................................. 26

Dilogo para transacciones con varios niveles ............ .......... ........... .......... ........... . 27

FORM EDITOR ............................................................................................................... 29Form Edition Controls ............................................................................................. 29

Paleta de herramientas ............................................................................................ 30

Uso de las Herramientas .......................................................................................... 31

Toolbar..................................................................................................................... 31

Propiedades de los controles ................................................................................... 32

Editor de Propiedades, Mtodos y Eventos............ .......... ........... .......... ........... ........ 35

FRMULAS .................................................................................................................... 36Frmulas Horizontales............................................................................................. 37

Frmulas Verticales ................................................................................................. 38

Frmulas y Redundancia ......................................................................................... 39


4/129

Frmulas de Frmulas ............................................................................................. 40REGLAS ......................................................................................................................... 41Default .......... .......... ........... ........... .......... ........... .......... ........... .......... ........... .......... ... 41

Error........ .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... ........ 41

Asignacin........... .......... ........... ........... .......... ........... .......... ........... .......... ........... ...... 41

Add y Subtract .......... ........... .......... ........... .......... ........... .......... ........... .......... ........... . 42

Serial ........................................................................................................................ 43

Orden de evaluacin ................................................................................................ 44

Call y funcin After .................................................................................................. 45

PROPIEDADES ................................................................................................................ 46

DISEO DE REPORTES.............................................................................................. 48

LAYOUT ........................................................................................................................ 48

Comando FOR EACH .............................................................................................. 51Reportes con varios FOR EACH.......... ........... .......... ........... .......... ........... .......... ..... 60

Otros comandos........................................................................................................ 67

CONDICIONES ................................................................................................................ 73REGLAS ......................................................................................................................... 74

Default .......... .......... ........... ........... .......... ........... .......... ........... .......... ........... .......... ... 74

Parm......................................................................................................................... 75

REPORT WIZARD ........................................................................................................... 76PROPERTIES................................................................................................................... 78

DISEO DE PROCEDIMIENTOS.............................................................................. 80

Modificacin de datos ........... .......... ........... .......... ........... .......... ........... .......... .......... 80

Eliminacin de datos ........... .......... ........... .......... ........... .......... ........... .......... ........... . 81

Creacin de datos..................................................................................................... 81CONTROLES DE INTEGRIDAD Y REDUNDANCIA............................................................... 82

DISEO DE PANELES DE TRABAJO ...................................................................... 83

EJEMPLO ....................................................................................................................... 84FORM DEL WORK PANEL............................................................................................... 86

Subfile....................................................................................................................... 87

EVENTOS....................................................................................................................... 89Evento Start ........... .......... ........... .......... ........... .......... ........... .......... ........... .......... ..... 90

Evento Enter.......... .......... ........... .......... ........... .......... ........... .......... ........... .......... ..... 90

Eventos definidos por el usuario (User Defined Events)............... .......... ........... ...... 91

Evento Refresh.......... ........... .......... ........... .......... ........... .......... ........... .......... ........... . 91

Carga de datos en el Panel de Trabajo.................................................................... 92

CONDICIONES ................................................................................................................ 93REGLAS ......................................................................................................................... 95Order........................................................................................................................ 95


5/129

Noaccept................ .......... ........... .......... ........... .......... ........... .......... ........... .......... ..... 95Search....................................................................................................................... 95

BITMAPS........................................................................................................................ 97Fixed Bitmaps........................................................................................................... 97

Dynamic Bitmaps ............ ........... .......... ........... .......... ........... .......... ........... .......... ..... 97

GRFICAS...................................................................................................................... 99PROPERTIES................................................................................................................. 103

Generar como una ventana Popup......................................................................... 103

DILOGOS OBJETO-ACCIN ........................................................................................ 104

DISEO DE MENES................................................................................................ 106

CALL BROWSER .......................................................................................................... 108

ANEXO A. MODELOS DE DATOS RELACIONALES.......... .......... ........... .......... . 110

Tablas..................................................................................................................... 110

Clave primaria y Claves candidatas ...................................................................... 111

Indices .......... .......... ........... ........... .......... ........... .......... ........... .......... ........... .......... . 112

Integridad Referencial................ .......... ........... .......... ........... .......... ........... .......... ... 112

Normalizacin .......... ........... .......... ........... .......... ........... .......... ........... .......... .......... 114

Tabla extendida...................................................................................................... 115

ANEXO B. FUNCIONES, REGLAS Y COMANDOS.............................................. 118


6/129

Todos los nombre de productos mencionados en este documento son marcas de susrespectivos dueos.

DISEO DE APLICACIONES CON GENEXUSCOPYRIGHT ARTech Consultores SRL. 1988 - 1999.Queda prohibida cualquier forma de reproduccin, transmisin o archivo en sistemasrecuperables, sea para uso privado o pblico por medios mecnicos, electrnicos,fotocopiadoras, grabaciones o cualquier otro, total o parcial, del presente ejemplar, con osin finalidad de lucro, sin autorizacin expresa de ARTech.


7/129

GENEXUS- DISEO DEAPLICACIONES

1

INTRODUCCIN

El presente documento es una introduccin al desarrollo de aplicaciones utilizandoGENEXUS. Est dirigido a profesionales de informtica que se inician en el uso deGENEXUS.GENEXUS es una herramienta para el desarrollo de aplicaciones. Su objetivo es ayudar alos analistas de sistemas a implementar aplicaciones en el menor tiempo y con la mejorcalidad posible.A grandes rasgos, el desarrollo de una aplicacin implica tareas de anlisis, diseo eimplementacin. La va de GENEXUS para alcanzar el objetivo anterior es liberar a laspersonas de las tareas automatizables (por ejemplo, la implementacin), permitiendolesas concentrarse en las tareas realmente difciles y no automatizables (anlisis y diseo).

Desde un punto de vista terico, GENEXUS es ms una metodologa de desarrollo deaplicaciones que una herramienta de software. Como metodologa, tiene algunos puntosde contacto con las metodologas tradicionales, pero tambin aporta enfoques bastantediferentes en otros.En comn con las metodologas tradicionales, se mantiene la importancia del anlisis ydiseo de la aplicacin sobre la implementacin. Quizs con GENEXUS este enfoque seresalta ms an, ya que el usuario de GENEXUS estar la mayor parte del tiemporealizando tareas de anlisis y GENEXUS, en s, tareas de implementacin (por ejemplo,normalizacin de la base de datos, generacin de programas, etc.).Por otro lado, algunos de los enfoques metodolgicos son bastante diferentes que loshabituales, como, por ejemplo, el comenzar el anlisis de la aplicacin por la interfase delmismo con el usuario, la casi nula referencia a la implementacin fsica del sistema, etc.Para presentar estos nuevos conceptos, y a los efectos de no realizar una presentacin

demasiado abstracta del tema, se ha elegido una aplicacin que se ir desarrollando atravs de los distintos captulos.El primer captulo presenta la aplicacin y los aspectos iniciales de un desarrollo conGENEXUS.El segundo captulo trata el diseo de Transacciones, el tercero de Reportes, el cuarto deProcedimientos, el quinto de Paneles de Trabajo y por ltimo se trata el diseo deMenes.Debido a que en todos los captulos se asume cierto conocimiento sobre Bases de DatosRelacionales, se ha incluido un anexo sobre el tema que describe los conceptos necesariospara este documento. Se recomienda su lectura antes de leer el segundo captulo.Por razones didcticas, en este documento no se tratan los siguientes temas:

Ciclo de vida de una aplicacin: Una aplicacin tiene un ciclo de vida, quecomienza cuando se planifica la misma y termina cuando la aplicacin sale deproduccin. GENEXUS acompaa todo este ciclo. Este tema es tratado en eldocumento Visin General, que recomendamos leer previamente.


8/129

GENEXUSDISEO DEAPLICACIONES

2

Uso deGENEXUS : Toda la informacin respecto a la operacin de GENEXUSen s (manejo de teclas, edicin de texto, etc.) se trata en el TutorialGENEXUS,que sugerimos repasar posteriormente.


9/129


3

DESARROLLO DE UNA APLICACIN

La mejor forma de aprender a utilizar GENEXUS es realizando aplicaciones con l. Laaplicacin que se ha elegido es una simplificacin de una aplicacin real.

SISTEMA DE COMPRAS PARA UNA CADENA DE FARMACIAS.

En una cadena de farmacias se desea implementar un sistema de compras que permita alos analistas de compras realizar dicha tarea con la mayor cantidad de informacinposible. La funcin de un analista de compras es decidir los pedidos que se debenefectuar a los proveedores de los distintos artculos.

Funcionamiento del sistema:

Se desea que el analista de compras utilice el computador para definir los pedidos a losdistintos proveedores. Una vez que el pedido este hecho y aprobado, se quiere que elcomputador emita las ordenes de compra. En el momento de hacer un pedido es necesariohacer varias consultas, por ejemplo cuanto hay en stock, cual fue el precio de la ltimacompra, etc.Los siguientes puntos describen los pasos seguidos para el desarrollo de esta aplicacin.

Definir el objetivo

No se debe olvidar que los computadores son meras herramientas. Los usuarios de lossistemas tienen objetivos especficos. Ellos esperan que la aplicacin los ayude aalcanzarlos mas rpido, mas fcil, o a un menor costo. Es parte del trabajo de anlisis, el

conocer esos propsitos y saber por medio de que actividades los usuarios quierenalcanzarlos.Este objetivo debe poder ser expresado en pocas palabras (uno o dos prrafos) y serconocido por todas las personas involucradas con el sistema.En el ejemplo, alguno de los propsitos posibles son:

"El sistema de compras debe disminuir la burocracia existente para laformulacin de un pedido."

"El sistema de compras debe asistir a usuarios no entrenados en la formulacinde pedidos de tal manera que su desempeo se asemeje al de un experto."

"El sistema de compras debe permitir la disminucin del stock existente en lasfarmacias."

De todos los objetivos posibles se debe elegir uno como el objetivo principal oprioritario. Esto es muy importante para el futuro diseo de la aplicacin. Basta conobservar como los distintos objetivos anteriores conducen a diseos diferentes.


10/129


4

Para nuestro ejemplo elegiremos el primer objetivo, dado que en la situacin real elanalista de compras no tenia toda la informacin que necesitaba. Por lo tanto, debaconsultar una serie de planillas manuales y llamar por telfono a los empleados deldeposito para que realizaran un conteo manual del stock.No se debe confundir el objetivo de la aplicacin (el QUE) con la funcionabilidad de lamisma (COMO se alcanzar el objetivo).

Definir el equipo de trabajo

A continuacin se debe definir cul ser el equipo de personas encargado de laimplementacin del sistema. Dicho equipo debe tener como mnimo dos personas:

El analista de sistemas. Y un usuario.

Los analistas de sistemas que trabajen en el desarrollo de la aplicacin deben cumplir doscondiciones:

Haber sido entrenados en el uso de GENEXUS Tener una orientacin a las aplicaciones.

Se recomienda que dichos analistas pasen algn tiempo trabajando con los usuarios en elcomienzo del proyecto a los efectos de familiarizarse con los conceptos, vocabulario,problemas existentes, etc.Como la aplicacin se desarrolla de una manera incremental, es MUY IMPORTANTE laparticipacin de los usuarios en todas las etapas del desarrollo. Se recomienda tener unusuario principal disponible para la prueba de los prototipos y tener acceso a los demsusuarios de una manera fluida.Dado que con GENEXUS los miembros del equipo estarn la mayor parte del tiempotrabajando en tareas de diseo y no de codificacin, se debe tomar como criterio generalel trabajar en equipos PEQUEOS, por ejemplo, no ms de cinco personas.

Obtener una imagen global

Se debe tener entrevistas con el nivel gerencial mas alto que se pueda, de modo deobtener informacin sobre la posicin relativa (e importancia) de la aplicacin dentro detoda la organizacin.


11/129


5

Definir el alcance de la aplicacinLuego de un estudio primario se debe decidir cul ser el alcance de la aplicacin parapoder cumplir con el objetivo. Para ello se recomienda seguir el Principio deEsencialidad:

"Solo lo imprescindible, pero todo lo imprescindible"

En el ejemplo, una vez que una orden de compra es enviada a un proveedor, se debecontrolar como y cuando se fueron entregando efectivamente los productos. Sin embargovemos que esto no es imprescindible para cumplir el objetivo de la aplicacin y por lotanto no ser tratado.

Mantener el diseo simple

Se debe planificar pensando en un proceso de diseo y desarrollo incremental.Comenzando por pequeos pasos y verificando la evolucin del modelo frecuentementecon el usuario.

Orientarse a los datos

En esencia, una aplicacin es un conjunto de mecanismos para realizar ciertos procesossobre ciertos datos.Por lo tanto, en el anlisis de la aplicacin, se puede poner mayor nfasis en los procesoso en los datos.En las metodologas tradicionales -como el Anlisis Estructurado- el anlisis se basa enlos procesos. En general, este anlisis es Top-Down; se comienza con la definicin msabstracta de la funcin del sistema, y luego se va descomponiendo esta en funciones cadavez ms simples, hasta llegar a un nivel de abstraccin suficiente como para poderimplementarlas directamente.Sin embargo, este enfoque tiene ciertos inconvenientes:

Las funciones de un sistema tienden a evolucionar con el tiempo, y por lo tanto, un diseobasado en las funciones ser ms difcil de mantener.La idea que una aplicacin se puede definir por una nica funcin es muy controvertidaen aplicaciones medias o grandes.Frecuentemente se descuida el anlisis de las estructuras de datos.No facilita la integracin de aplicaciones.

Si, por el contrario, el diseo se basa en los datos, se puede obtener las siguientesventajas:


12/129


6

Ms estabilidad. Los datos tienden a ser ms estables que los procesos y en consecuenciala aplicacin ser ms fcil de mantener.

Facilidad de integracin con otras aplicaciones. Difcilmente una aplicacin estotalmente independiente de las otras dentro de una organizacin. La mejor forma deintegrarlas es tener en cuenta los datos que comparten. Incluso es posible que en un futuroel propio concepto de aplicacin evolucione hacia el concepto de objeto, en donde losusuarios pedirn que se implementen nuevos objetos y no nuevas aplicaciones.

Sin embargo, si bien vemos que orientarse a los datos es beneficioso, la pregunta es comoanalizar los datos?. La respuesta de GENEXUS es analizar directamente los datos que elusuario conoce, sin importar como se implementarn en el computador.

El diseo comienza -como veremos ms en detalle en el siguiente captulo- estudiandocuales son los objetos que el usuario manipula. Para cada uno de estos objetos se definecual es su estructura de datos y posteriormente cual es su comportamiento.De esta manera se alcanzan dos objetivos importantes: el anlisis se concentra en hechosobjetivos, y este puede ser evaluado directamente por los usuarios, utilizando la facilidadde prototipacin de GENEXUS.


13/129


7

DISEO DE TRANSACCIONES

El anlisis mismo de la aplicacin comienza con la definicin de las transacciones. Decualquier manera es importante tener en cuenta que todo el proceso de desarrollo esincremental y por lo tanto no es necesario definir en esta etapa todas las transacciones ycada una de ellas en su mayor detalle. Por el contrario lo importante aqu es reconocer lasmas relevantes y para cada una de ellas cual es la estructura mas adecuada.Para poder definir cuales son las transacciones se recomienda estudiar cuales son losobjetos (reales o imaginarios) que el usuario manipula. Afortunadamente es posibleencontrar la mayor parte de las transacciones a partir de:

La descripcin del sistema. Cuando un usuario describe un sistema se pueden

determinar muchas transacciones si se presta atencin a los sustantivos que utiliza. Enel ejemplo:

Analistas de comprasPedidosProveedoresArtculosOrdenes de Compra

Formularios existentes. Por cada formulario que se utilice en el sistema es casiseguro que existir una transaccin para la entrada de los mismos.

Para cada transaccin se puede definir:

EstructuraDe que atributos (campos en la metodologa tradicional) esta compuesta y querelacin tienen entre si.

Pantalla o FormCual es el form que tiene. Esto se realiza con un editor especializado.

FrmulasQue atributos se calculan a partir de otros atributos. Por ejemplo: Valor = Cantidad *Precio.

Reglas


14/129


8

Conjunto de reglas que debe cumplir la transaccin. Por ejemplo cuales son losvalores por defecto de los atributos, cuales son los controles en los datos que hay querealizar, etc.

EventosLas transacciones soportan la programacin dirigida por eventos. Este tipo deprogramacin permite el almacenamiento de cdigo ocioso el cual es activado luegode ciertos eventos - provocados por el usuario o por el sistema.

PropiedadesReglas que definen el comportamiento general de la transaccin.

Form Classes

Cada objeto puede tener asociado mas de un form que pertenece a una determinadaForm Class. Existen dos Form Classes predefinidas: Graphic y Text. Tipicamente laForm Class Graphic se usa para los ambientes graficos (por ejemplo: Windows) y laform class Text se usa para los ambientes que trabajan en modo texto (por ejemplo:AS/400) El combo box que se muestra en la siguiente figura permite seleccionar unform (de determinada Form Class) de los que se hayan asociado al objeto.

Style AsociadoStyles son bsicamente objetos GENEXUS (su forma de definicin es similar a losotros objetos), pero no son tenidos en cuenta en la normalizacin o generacin deprogramas; slo se utilizan para definir estndares. Un ejemplo puede aclarar la idea:supongamos que se quiere definir las transacciones con botones con bitmaps en vez delos usuales de texto. Cuando se crea una transaccion se puede asociar un style en el

cual se basara la transaccion.

AyudaTexto para la ayuda a los usuarios en el uso de la transaccin.

DocumentacinTexto tcnico que se incluye para ser utilizado en la documentacin del sistema.


15/129


9

Fast Access Toolbar

Cuando se bare un objeto esta toolbar se habilita con las siguientes opciones:

Estructura de una transaccin

La estructura define que atributos (campos) integran la transaccin y como estnrelacionados. En el ejemplo, la transaccin de Proveedores posee los siguientesatributos:

PrvCod Cdigo de proveedorPrvNom Nombre del proveedorPrvDir Direccin del proveedor

que componen la informacin que se quiere tener de un proveedor.

Form

Estructura

Reglas

Eventos

Propiedades

Variables

Forms

Help


16/129


10

AtributosPara cada atributo se debe definir:

Name: Es el nombre del atributo. Se utiliza para identificar al atributo.

Title: Es un string que acompaa al atributo en los listados de documentacin quetenemos disponibles y permite tener una descripcin ampliada para ste. Tambin seutiliza en los Forms de las transacciones y reportes que se crean por defecto.

Domain: Dominio en que se basa el atributo al definirlo.

Type: tipo de atributo (Numrico, alfanumrico, fecha, Long Varchar, Varchar oDateTime).


17/129


11

El tipo de dato Long Varchar (por Variable Character) permite almacenar unacantidad de caracteres indefinida. Se utiliza normalmente para almacenar textos, porejemplo notas, descripciones, comentarios, etc.

Length: largo del atributo.

Decimals: Nmero de posiciones decimales.

Picture - Formato del campo que permite una visualizacin en la entrada y salida, porejemplo: en campos caracter @! significa que todos los caracteres se aceptan ydespliegan en maysculas.

Value Range: Rango de valores vlidos para el atributo.

Por ejemplo: La siguiente definicin:

1:20 30: significa que el valor debe estar entre 1 y 20 o ser mayor que 301 2 3 4 significa que el valor debe ser 1 o 2 o 3 o 4'S' 'N' significa que el valor debe ser 'S' o 'N'

Dominios

Es comn cuando estamos definiendo la base de datos, tener atributos que compartendefiniciones similares, y que no se puede establecer ninguna relacin directa entreellos. Por ejemplo, es comn almacenar todos los nombres en atributos de tipocaracter y largo 25. El uso de dominios permite usar definiciones de atributos

genricos. Por ejemplo en la transaccin de proveedores tenemos el nombre(PrvNom) y mas adelante vamos a definir el nombre del analista, entonces podemosdefinir un dominioNombres de tipo caracter con largo 25 y asociarlo a estos atributos.Por lo tanto si en el futuro cambia la definicin de este dominio, los cambios sernpropagados automticamente a los atributos que pertenecen a l.

Atributos Clave

Tambin es necesario definir cual es el atributo o conjunto de atributos que identificana la transaccin (es decir que los valores de los atributos identificadores son nicos),esto se hace poniendo un * al final del o los atributos:

PrvCod*PrvNom

PrvDir

as se indica que no existen dos proveedores con el mismo Cdigo de Proveedor.


18/129


12

Es importante notar que el concepto de identificador se refiere a la unicidad (si puedehaber o no dos proveedores con el mismo nmero) y no a como se debe acceder alarchivo donde se almacenan los proveedores.Reglas para los identificadores:

Toda transaccin debe tener un identificador. Los identificadores tienen valor desde un principio (por ejemplo cuando se

crea un proveedor nuevo se debe saber cual ser su PrvCod) No cambian de valor. Por ejemplo al proveedor con cdigo 123 no se lo puede

cambiar para 234.

En los casos en los cuales no se puede determinar un identificador se debe optar por

crear un atributo artificial (no existente en la realidad) y cuyo valor es asignadoautomticamente por el sistema.

Relacin entre la estructura y el modelo de datos

GENEXUS utiliza la estructura de la transaccin para definir cual es el modelo de datosque se necesita. En particular de la estructura anteriorGENEXUS infiere:

No existen dos Proveedores con el mismo PrvCod. Para CADA PrvCod existe solo UN valor de PrvNom y de PrvDir.

y con esta informacin va construyendo el modelo de datos. En este caso a latransaccin de Proveedores se le asociara la Tabla:

Tabla: Proveedo

Atributos: PrvCod* (con * se indica clave primaria) PrvNom PrvDir

Indices:IPROVEED (PrvCod) Clave Primaria

el nombre de la tabla y el del ndice son asignados automticamente, pero luegopueden ser modificados por el analista).Diremos que la transaccin de Proveedores tiene asociada la tabla PROVEEDO en el

entendido que cuando se ingresen (o modifiquen, etc.) datos en la transaccin estossern almacenados en la tabla PROVEEDO.Otras transacciones simples de nuestro ejemplo son:


19/129


13

Analista de compra:

AnlNro* Numero de analistaAnlNom Nombre del analista

Artculos:ArtCod* Cdigo de articuloArtDsc Descripcin del articuloArtCnt Cantidad en StockArtFchUltCmp Fecha ultima compraArtPrcUltCmp Precio ultima compraArtUnidad Unidad del articulo

ArtSize TamaoArtDisponible Disponibilidad

Que tendrn asociadas las tablas ANALISTA y ARTICULO respectivamente.

Tabla: ANALISTA

AnlNro* AnlNom

Tabla: ARTICULO

ArtCod*

ArtDsc ArtCnt ArtFchUltCmp ArtPrcUltCmp ArtUnidad

ArtSize

ArtDisponible

Veamos ahora la definicin del form de artculos:


20/129


14

Los atributos ArtUnidad, ArtDisponible y ArtSize no aparecen en el form como losatributos convencionales (de edit). ArtUnidad se defini como un Combo Box,ArtSize como un Radio Buttom yArtDisponible como un Check Box.

Tipos de controles

Edit

Normalmente los atributos tienen un rango de valores muy grande, (por ejemplo: unnombre, un precio, etc). En estos casos se le permite al usuario entrar el valor delatributo y el sistema se encarga de validarlo. A estos tipos de controles se los llamaEdit Box. En el ejemplo, Artcod, ArtDsc, etc.Sin embargo existen atributos que tienen un rango de valores muy pequeo y quepueden ser desplegados de antemano para que el usuario seleccione uno. De estaforma controlamos que ingresen solo valores vlidos. Estos tipos de controles son losque veremos a continuacin.

Check Box

Es usado para aquellos atributos que tienen solo dos posibles valores True o False(como en nuestro ejemplo para sealar si existe disponibilidad del artculo). Existe


21/129


15

una nica descripcin (Disponible) y en caso que este campo este seleccionado elvalor ser True y en caso contrario ser False.

Radio Buttom

Los Radio Buttom, en cambio, pueden tener mas de dos valores. Todos los valoresse despliegan en el form (en realidad se despliegan sus descripciones, el valor que sealmacena es manejado internamente) y solo se puede seleccionar uno. En el ejemploel tamao del articulo lo definimos como un Radio Buttom.

Combo Box

Es generalmente usado para aquellos atributos que tienen un rango grande de valores,y que con un Radio Buttom no seria muy practico el manejo. Se despliega un campo

de tipo Edit y presionando un botn que se encuentra a la derecha del campo sedespliega una lista con todos los valores validos. No es recomendable usar este campocomo listas de seleccin de atributos que tienen valores que no pueden serdeterminados a priori, (que son ledos de una tabla). Para estos casos se usan losDynamic Combobox.

Dynamic Combobox

Un dynamic combobox es un tipo de control similar al combo box, la diferencia esque los valores posibles se leen de una tabla de la base de datos. La forma deoperacin es similar a la del combo box, solo que los valores desplegados sondescripciones ledas de una determinada tabla.

List Box

Este tipo de control tiene asociada una coleccin de tems. Cada tem tiene asociadoun par . Existe la posibilidad de cargar la coleccin de tems tantoen diseo como en runtime. El control da la posibilidad de seleccionar un solo tem ala vez. El atributo o variable toma el valor en el momento que se selecciona el tem.La seleccin se realiza dando click con el mouse en un tem o con las flechas delteclado.

Dynamic List Box

Este tipo de control tene asociada una coleccin de tems. Cada tem tiene asociado unpar .


22/129


16

La coleccin de tems se carga en runtime desde una tabla de la base de datos.Tambin es posible agregar tems en forma manual en runtime.En tiempo de diseo se asocian dos atributos al Dynamic List Box, uno al valor quetendr el tem y el otro a la descripcin que ste tomar. Ambos atributos debenpertenecer a la misma tabla.En tiempo de especificacin se determina la tabla desde la cual se traern los valores ylas descripciones.

Definicin de la transaccin de pedidos

Consideremos ahora la transaccin de Pedidos. El formulario preexistente de pedidoses:

Pedido : 1456 Fecha: 02/01/92Analista : 21 Pedro GomezProveedor : 125 ABC Inc.

Cdigo Descripcin Cantidad Precio Valor

321 Aspirinas 100 120 12000567 Flogene 120 50 6000

Total 18000

Los atributos que integran la transaccin son (dejando momentneamente de lado lainformacin de los Artculos del pedido):

PedNro* Numero del pedidoPedFch Fecha del pedidoPrvCod

PrvNom

AnlNro

AnlNom

PedTot Total del pedido

en donde PedNro es el identificador del mismo.Esta transaccin tiene algunas caractersticas interesantes a destacar: tanto PrvCodyPrvNom, como AnlNro y AnlNom son atributos que estn presentes en otrastransacciones. De esta manera estamos indicando que existe una relacin entre los


23/129


17

Proveedores y los Pedidos y tambin entre los Analistas y los Pedidos, en particularaqu estamos indicando que un Pedido solo tiene UN Proveedor y solo UN Analista.Se tiene as que la forma de indicar a GENEXUS la relacin entre las distintastransacciones se base en los nombres de los atributos.

Reglas para nombres de atributos

Se debe poner el mismo nombre al mismo atributo en todas las transacciones en quese encuentre, a no ser que ello no sea posible (es el caso de Subtipos que se detallaramas adelante). Por ejemplo al nombre del proveedor se le llama PrvNom tanto en latransaccin de Proveedores como en la de Pedidos.Se debe poner nombres distintos a atributos conceptualmente distintos, aunque tengandominios iguales. Por ejemplo el nombre del proveedor y el nombre del analistatienen el mismo dominio (son del tipo Character de largo 30), pero se refieren a datosdiferentes, por lo tanto se deben llamar PrvNom yAnlNom.

Integridad referencial en las transacciones

Otra caracterstica a destacar es que, cuando se define la estructura de una transaccinNO se esta describiendo la estructura de una tabla y SI los datos que se necesitan en lapantalla o en las reglas. Por ejemplo, que en la estructura anterior figure elPrvNom noquiere decir que este se encuentre en la tabla de Pedidos, simplemente indica que senecesita tener el PrvNom en la pantalla de Pedidos.La tabla asociada a el cabezal del Pedido ser:

Tabla: PEDIDOS

PedNro*PedFch

PrvCod

AnlNro

PedTot

ndices:

IPEDIDOS (PedNro) Clave PrimariaIPEDIDO1 (PrvCod) Clave ExtranjeraIPEDIDO2 (AnlNro) Clave Extranjera

Observar que PrvNom no se encuentra en la tabla PEDIDOS (diremos que fue'normalizado'). Y que existe una relacin de integridad entre la tabla PROVEEDO,


24/129


18

que tiene a PrvCod como clave primaria, y la PEDIDOS que lo tiene como claveextranjera. La relacin, que llamaremos de integridad referencial, es:

Para insertar un registro en la tabla PEDIDOS debe existir el PrvCodcorrespondiente en la tabla PROVEEDO.

Cuando se elimina un registro de la tabla PROVEEDO no debe haberregistros con el PrvCoda eliminar en la tabla PEDIDOS.

Estos controles de integridad son generados automticamente por GENEXUS y, porejemplo, en la transaccin de Pedidos cuando se digita el PrvCodse valida que esteexista en la tabla PROVEEDO e incluso se genera una subrutina que permitevisualizar los proveedores existentes y seleccionar el proveedor asociado al pedido.

Niveles de una transaccinVolviendo al ejemplo, para terminar de disear la transaccin de Pedidos se debedefinir la informacin sobre los Artculos del pedido. Sin embargo no es posibledefinir la estructura de la siguiente manera:

PedNro*PedFch

PrvCod

PrvNom

AnlNro

AnlNom

ArtCod

ArtDscPedCnt Cantidad pedidaPedPre Precio pedidoPedImp Valor del articuloPedTot

porque esto significara que para cada pedido existe solo UN articulo, lo que no secorresponde con el formulario. La estructura correcta es:


25/129


19

PedNro* PedFch PrvCod PrvNom AnlNro Nivel del AnlNom cabezal

( ArtCod* ArtDsc Nivel de las PedCnt lneas PedPre PedImp )

PedTot

donde el identificador es PedNro y para cada numero de pedido existe solo una fecha,un cdigo y nombre de proveedor, un nmero y nombre del analista y un solo total,pero muchos Artculos, cantidades pedidas, precios y importes de la lnea .Los parntesis indican que para cada Pedido existen muchos Artculos. Cada grupo deatributos que se encuentra encerrado por parntesis diremos que pertenece a unNIVEL de la transaccin.Cabe notar que el primer nivel queda implcito y no necesita un juego de parntesis.As, la transaccin de Pedidos tiene dos niveles: PedNro, PedFch, PrvCod, PrvNom,AnlNro, AnlNom y PedTot pertenecen al primer nivel y ArtCod, ArtDsc, PedCnt,PedPre y PedImp pertenecen al segundo nivel.Una transaccin puede tener varios niveles y ellos pueden estar anidados o ser

paralelos entre si. Por ejemplo si el Pedido tiene varias fechas de entrega:

PedNro* PedFch PrvCod PrvNom AnlNro AnlNom

( ArtCod* ArtDsc PedCnt PedPre PedImp )

( PedFchEnt* Fecha de entregaPedImpPag ) Importe a pagar PedTot


26/129


20

Con esta estructura se define que un Pedido tiene muchos Artculos y muchasEntregas, pero no hay relacin directa entre ambas (a no ser el hecho de pertenecer almismo Pedido). Si por el contrario las fechas de entrega son por articulo (cadaarticulo tiene sus fecha de entrega particulares), la estructura correcta es:


( ArtCod*

ArtDsc PedCnt PedPre PedImp

( PedFchEnt* PedImpPag ) ) PedTot

As como la transaccin tiene un identificador, cada nivel de la misma tambin debetener uno. Por ejemplo en el Pedido tenemos que el identificador del segundo nivel esArtCod. Con esto se indica que dentro de cada Pedido no existen dos lneas delPedido con el mismoArtCod, y por lo tanto el siguiente Pedido no es valido:

Pedido : 1456 Fecha: 02/01/92Analista : 21 Pedro GomezProveedor : 125 ABC Inc.

Cdigo Descripcin Cantidad Precio Valor

321 Aspirinas 100 120 12000321 Aspirinas 120 50 6000

Total 18000

porque existen dos lneas del Pedido con el mismoArtCod.


27/129


21

Aqu tambin se deben tener en cuenta los criterios sobre identificadores que semencionaron previamente. En particular, es comn definir atributos artificiales cuandono hay identificadores naturales, por ejemplo, para el caso en que si puede habervarias veces el mismo articulo en el pedido, se debe definir el Pedido como:


( PedLinNro* ArtCod

ArtDsc PedCnt PedPre PedImp ) PedTot

en donde el PedLinNro lo puede digitar el usuario o se puede incluir una regla paraque lo haga automticamente la transaccin.

Cada nivel de la transaccin tiene una tabla asociada:

Tabla: PEDIDOS PedNro*

PedFch PrvCod AnlNro PedTot

Tabla: PEDIDOS1 PedNro* PedLinNro* ArtCod PedCnt PedPre PedImp

La clave primaria de las tablas asociadas a los niveles subordinados es laconcatenacin de los identificadores de los niveles superiores (PedNro) mas losidentificadores del nivel (PedLinNro).


28/129


22

La eleccin de los identificadores es una tarea importante y que puede simplificar ocomplicar la implementacin de un sistema. Supongamos por ejemplo, que en elPedido no se admite que haya dos lneas con el mismoArtCod. La forma natural deimplementar esto es definiendo aArtCodcomo identificador del segundo nivel. Ahorabien, si por alguna razn se defini a PedLinNro como el identificador, ya notendremos ese control automtico y se debe escribir un Procedimiento para realizarlo.En otras palabras, cuanto mas reglas de la realidad se puedan reflejar en la estructura,menor ser la cantidad de procesos que se debe implementar, ganando as ensimplicidad y flexibilidad.

Tipos de relacin entre los objetos

Muchas veces cuando los usuarios estn describiendo la aplicacin, es comn

preguntarles que tipo de relacin existe entre los distintos objetos. Por ejemplo cual esla relacin entre los proveedores y los pedidos:

Un proveedor tiene muchos pedidos (relacin 1-N).Un pedido tiene un solo proveedor (relacin N-1).

Como ya vimos, la relacin 1-N se puede definir con la estructura:

PrvCod* PrvNom

....(PedNro*....

)Y la relacin N-1 como:

PedNro*....

PrvCod PrvNom

....

Vemos que generalmente para cada relacin N-1 habr una relacin simtrica 1-N. Enestos casos se debe definir la estructura N-1 y no la 1-N.Otro caso muy comn son las relaciones M-N, por ejemplo entre los pedidos y los

Artculos:Un pedido tiene muchos Artculos.


29/129


23

Un articulo puede estar en muchos pedidos.

En este caso las dos estructuras posibles son:


( ArtCod* ArtDsc PedCnt

PedPre PedImp ) PedTot

o:

ArtCod* ArtDsc

( PedNro* PedFch PrvCod PrvNom AnlNro

AnlNom PedTot PedCnt PedPre PedImp )

Se debe definir solo una de las dos estructuras, en este caso la correcta es la primera,porque el usuario ingresa los pedidos con sus Artculos y no para cada articulo quepedidos tiene.

Form de una transaccin

Cada transaccin puede tener varios forms asociados. Inicialmente GENEXUS crea unopor defecto partiendo de los atributos de la misma y luego se puede modificar. Se pueden


30/129


24

agregar o quitar forms a travs de las opcionesEdit/Add New Form oEdit/Select Forms.Tambien se puede seleccionar el form con el cual se desea trabajar seleccionndolo delcombo box que aparece en la toolbar.

Tambin se puede asociar un style y aplicarlo. El style se asocia en cada objeto en laspropiedades del mismo.

Para los Proveedores la pantalla por defecto (en este caso en modo grfico) es:

Utilizando solo esta pantalla el usuario final puede crear, modificar o eliminarproveedores. Para ello la pantalla tiene un Modo, que indica cual es la operacin que se

esta realizando (Insertar, Modificar, etc.) y el usuario puede pasarse de un modo a otro sintener que abandonar la pantalla.GENEXUS puede generar dos tipos de dilogo para las transacciones, full-screen o campoa campo.

Dilogo full-screen

Este tipo de dilogo se genera para las plataformas donde se utilizan terminales noprogramables, por ejemplo para el IBM AS/400.El funcionamiento bsico del dilogo full-screen es:

1- Se aceptan todos los campos de la pantalla

2- Se realizan todas las validaciones3- Si hubo error se muestran los mensajes de error y se vuelve al punto 1.4- Si no hubo error se pide confirmacin, si no se confirma se vuelve a 1.

Atributos que sernaceptados o desplegados

en la pantalla


31/129


25

5- Si se confirma la operacin esta es realizada y se vuelve a 1.

Este proceso tiene leves alteraciones segn el modo (Insertar, Modificar, etc.), ya quesi se encuentra en modo Insertar se aceptan los identificadores, pero si se esta enmodo Modificar no, etc.El pasaje de un modo a otro se realiza presionando teclas de funcin. Por ejemplo conF6 se pasa a modo Insertar, con F11 a modo Modificar, etc.

Dilogo campo a campo

Para plataformas con terminales programables, como es el caso de PCs o LANs,GENEXUS genera las transacciones con una interfaz campo a campo.En este dilogo, cada vez que un campo es digitado inmediatamente se controla su

validez.Tambin trabaja con modos, pero con la diferencia que el modo es inferidoautomticamente por el sistema. Por ejemplo cuando el usuario digita el PrvCod, sieste existe se pasa automticamente a modo Modificar y si no existe se pasa a modoInsertar.

Barra o Botones de Men

En ambos tipos de dilogo se encuentra disponible una Barra de Men que tiene lasopciones para poder visualizar los distintos datos.

Por ejemplo, se puede elegir ver (para luego modificar) el primer proveedor , el

siguiente (a partir del que se esta mostrando en pantalla) o poder elegir uno en

particular .


32/129


26

Atributos de entrada y atributos de salidaConsideremos nuevamente la transaccin de Pedidos pero sin sus Artculos. Lapantalla por defecto es:

Vemos que hay algunos atributos que deben ser digitados (son atributos de entrada),por ejemplo PedNro y PrvCody otros que no, como ser PrvNom (son atributos desalida). GENEXUS automticamente determina que atributos son aceptados y de cualessolo se muestra su valor, siguiendo las reglas:

Solo pueden ser aceptados los atributos que se encuentran en la tablaasociada al nivel (en este caso son los atributos de la tabla PEDIDOS,PedNro, PedFch, PrvCod,AnlNro y PedTot).

Los atributos definidos como frmulas no son aceptados. En modo Modificar no se aceptan los identificadores. Los atributos que tienen una regla de Noaccept no son aceptados.

Facilidad de Prompt

Para los atributos que estn involucrados en la integridad referencial de la tabla basedel nivel se genera la facilidad de Prompt que permite visualizar cual es el conjunto de

valores validos para esos atributos. Por ejemplo, en la transaccin de Pedidospresionando una tecla especial se puede visualizar cuales son todos los proveedores,con la siguiente pantalla:


33/129


27

en donde se puede seleccionar el proveedor. Observar que en la primera parte de lapantalla se permite digitar el PrvCod,el PrvNom, o el PrvDirpara poder posicionarseen la lista de proveedores. Esta lista es un work panel de GeneXus que puede sermodificado como cualquier otro objeto.

Dilogo para transacciones con varios niveles

Para el caso de transacciones con varios niveles se tiene un proceso de dilogo pornivel. Es decir se realiza la validacin y la confirmacin de los datos para cada uno delos niveles.Por ejemplo para la transaccin de Pedidos (considerando ahora los Artculos delmismo) la pantalla por defecto es:


34/129


28

En sta se aceptan primero los datos de entrada del primer nivel (los del cabezal delpedido: Numero, Fecha, Proveedor y Analista), posteriormente se validan y se pideconfirmacin y luego se realiza el mismo proceso para cada una de las lneas delpedido.

Cuando se genera el form por defecto se disea un subfile para el ltimo nivel de latransaccin, en el ejemplo las lneas del pedido.Trabajando con el form editor se puede transformar esta pantalla en la siguiente, quesimula mejor el formulario de pedidos:


35/129


29

Form Editor

Los objetos como las Transacciones o los Work Panels, tienen uno o varios Formulariosasociados. A los efectos de permitir modificar los Formularios que GENEXUSautomticamente crea por defecto, se provee un Form Editor. Este Form Editor es igualpara todos los objetos que tienen Formularios.El Formulario est formado por un marco de ventana (frame) cuyo ttulo es la descripcinde la transaccin. Dentro de ella figurarn los distintos tipos de controles de edicin delFormulario.

Form Edition Controls

En un Formulario se definen controles. Un control es una rea del Formulario quetiene una forma y un comportamiento determinado. Existen los siguientes tipos decontroles:


36/129


30

Atributo. Se utiliza para representar atributos o variables.

Texto. Todo fragmento de texto fijo en la pantalla debe colocarse utilizando uno oms controles de este tipo.

Lnea. Con este control se dibujan lneas horizontales o verticales.

Recuadro. Permite definir recuadros de distintos tamaos y formas.

SubFile. Permite definir SubFiles. La definicin de los subfiles se vera mas adelanteen el capitulo de Work Panels.

Botn. Permite definir Botones (tambin llamados Command Buttons).

Bitmap. Permite definir bitmaps estticos en la pantalla.Cada control tiene una serie de propiedades (ancho de lnea, color, color de fondo,font, etc.), cuyos valores pueden fijarse en forma independiente.

Tab. Permite definir varios controles dentro de otro. Un Tab control tiene una ovarias Paginas y cada Pagina tiene un Title y un area util donde se ponen loscontroles de esa pagina. Solo una de las paginas puede estar activa a la vez y es la quese puede ver, del resto solo se vera su titulo. Esto es util para cuando se quiere dividirlos datos ingresados en la transaccion en distintos grupos de modo que las pantallasqueden diseadas de forma amigable al usuario (transacciones con muchos atributos).

Paleta de herramientas

Mientras se est editando un Formulario, est disponible la paleta de herramientas, enla forma de una ventana adicional, con los botones que representan los tipos decontroles disponibles.


37/129


31

Uso de las HerramientasSobre los objetos seleccionados con el puntero vamos a poder realizar variasoperaciones:

Cambiar el tamao y forma de un control. Edicin de propiedades. Move Forward, Move Back, Move to Front y Move to Back. Estas

operaciones nos van a permitir cambiar la capa en que se encuentra uncontrol. Cada control se encuentra en una capa distinta del Formulario,por lo que algunos estn "ms arriba" que otros. Cuando dos objetos se

superpongan, el de ms arriba ser visible totalmente, mientras que elotro slo en aquellos puntos en que no se encuentre "tapado".

Move, Copy y Delete.

Toolbar

El Form Editor Toolbar nos permite ubicar los controles en el form, y copiar eltamao de otros controles ya definidos:

Toolbar

Alinear a la izquierda. Separar horizontalmente.

Alinear a la derecha. Separar verticalmente.

Alinear al borde superior. Igualar ancho.

Alinear al borde inferior. Igualar altura.

Centrar verticalmente. Igualar tamao.

Centrar horizontalmente. Mostrar Grid


38/129


32

Propiedades de los controles

Vamos a ver las principales propiedades de cada unos de los controles que podemosinsertar en un form.

Atributo

Name. En esta opcin se permite ingresar un nombre al control que se esta editando.Este nombre ser usado luego para asociarle propiedades o eventos al control.

Array Indices. En el caso de utilizarse variables que sean matrices, se habilitan estasopciones, donde se pueden indicar expresiones que definan la fila y la columna.


39/129


33

Frame. Se puede indicar que el atributo est rodeado por un marco. Es posible indicarel tipo: None, Single o 3D; el ancho de la/s lnea/s (Width), si se pinta dentro de l ono (Fill) y si el tamao y forma deben determinarse a partir del atributo (Auto Resize).

Font. Permite seleccionar el font que se utilizar para el atributo en la pantalla.

Control Info

Control Type. En los Formularios generados el atributo podr asociarse a distintostipos de controles Windows. Se puede seleccionar uno de los siguientes: Combo Box,Dynamic Combobox, Radio Button, Edit, List Box, Dynamic List Box y Check Box.El botn de Setup permite definir caractersticas propias a cada tipo de control.

Dentro

Fore Color. Este botn es para seleccionar el color con el que se desplegar el valordel atributo y la/s lnea/s del frame, si tuviera.

Back Color. Con este botn se puede seleccionar el color con el que se pinta el reaasignada al atributo en la pantalla. Slo tiene efecto si est presente la propiedad Fill.


40/129


34

Texto

Text. Indica el texto que se quiere insertar en la pantalla. Puede consistir de una o mslneas.

Alignment. El texto puede estar justificado a la izquierda (Left), derecha (Right) ocentrado (Center).

Resto de las propiedades. Ver control de Atributo.


41/129


35

Recuadro

Del combo box se selecciona el tipo del borde del recuadro: single, none (sin borde) o3D.Para el resto de las propiedades ver la explicacin en el control de Atributo.

Lnea

Utiliza el mismo dilogo de edicin de propiedades con la salvedad de que la opcinFill aparece deshabilitada.

Editor de Propiedades, Mtodos y EventosA los controles (que tienen nombre asociado) que usamos en los forms se le puedenasociar propiedades, mtodos o eventos, por ejemplo: cambiarle el font a un texto,hacer un texto visible o invisible, deshabilitar un botn, etc. El tipo depropiedades/eventos que se pueden asociar a un control depende del tipo de control.Para acceder al dialogo donde poder asociar propiedades a los controles se usa laopcin de menInsert/Property (oInsert/Event) cuando se esta editando los eventos,rules o subrutinas de la transaccin. El dialogo que aparece es el siguiente:


42/129


36

Frmulas

Se dice que un atributo es una frmula si su valor se puede calcular a partir del valor deotros atributos.

En el ejemplo el atributo PedImp de la transaccin de Pedidos se puede calcular a partirde la PedCnty el PedPre:

PedImp = PedCnt* PedPre

En cada transaccin se puede definir que atributos son frmulas, pero esta definicin esglobal, es decir toda vez que se necesite el atributo se calcula la frmula, tanto entransacciones como en los otros objetos GENEXUS (reportes, Paneles de Trabajo, etc.).

Existen distintos tipos de frmulas:

Horizontales Verticales De agregacin/seleccin


43/129


37

Frmulas HorizontalesUna frmula horizontal se define como una o varias expresiones aritmticascondicionales. Por ejemplo:

Descuento = PedTot * 0.10 if PedTot > 100 .and.

PedTot 1000;

= 0 OTHERWISE;

En donde el Descuento ser del 10% si el total del pedido esta entre 100 y 1000 y del

20% si es mayor y en cualquier otro caso no hay descuento (en las frmulas concondiciones es saludable definir siempre el OTHERWISE).

La expresin puede utilizar los operadores aritmticos (+. -, *, /, ^) y funciones (porejemplo 'today()' que devuelve la fecha del da), y para los casos en donde el calculoes muy complicado se puede llamar a una rutina que lo realice en vez de usarformulas:

Descuento = udf('Pdesc', PedTot);

En donde 'udf' viene de User Defined Function. 'Pdesc' es el nombre de la rutinallamada, que recibe como parmetro a PedTot y devuelve Descuento. Esta rutinapuede ser una rutina externa a GENEXUS o escrita con GENEXUS utilizando el objeto

Procedure.El importe del pedido tambin es una frmula horizontal:


Vemos que la forma de definirla involucra a dos atributos (PedCnty PedPre), pero nose indica en que tablas de encuentran. GENEXUS se encarga de buscar la manera derelacionar PedCnty PedPre para poder calcular la frmula (en este caso es muy fcilporque PedCnty PedPre se encuentran en la misma tabla). En los casos en que no esposible relacionar a los atributos GENEXUS da un mensaje de 'frmula invalida'.Ahora bien, cuales son los atributos que pueden estar involucrados?. La respuesta es:en una frmula horizontal todos los atributos de los cuales depende la frmula debenestar en la misma tabla extendida que la frmula (ver el concepto de tabla extendida

en el anexo sobre Bases de Datos Relacionales).


44/129


38

Cuando se define una frmula horizontal GENEXUS 'sabe' cual es la tabla extendida ycontrola que todos los atributos utilizados se encuentren en ella.

Frmulas Verticales

Consideremos ahora el Total del pedido (PedTot), este se debe calcular sumando losImportes (PedImp) de cada una de las lneas del Pedido. Esta frmula se expresacomo:

PedTot= SUM( PedImp )

Y es un caso de frmula vertical, que se define como el tipo de frmula en que losatributos involucrados no se encuentran dentro de la misma tabla extendida que la

frmula. En el caso de PedTot, si observamos el modelo de datos (usando el diagramade tablas de GENEXUS ):

Tenemos que PedTotesta en la tabla PEDIDOS y PedImp en la PEDIDOS1 que esuna tabla subordinada a la PEDIDOS.Podemos utilizar tambin el Database Browser de GENEXUS para determinar que

tablas estn subordinadas y superordinadas a la de pedidos (eligiendo la opcinSuperordinated o Subordinated del dialogo del browser):

Tabla: PEDIDOS PedNro* PedFch PrvCod AnlNro PedTot

Tabla: PEDIDOS1 PedNro*

PedLinNro* ArtCod PedCnt PedPre PedImp

1

N


45/129


39

Adems de ver que tablas tiene subordinadas y superordinadas, podemos consultar laestructura de una tabla, que ndices tiene (composicin de los ndices), frmulas, etc.

Existen dos operadores para frmulas verticales: SUM que suma todos los datos yCOUNT que cuenta cuantos datos hay.

Frmulas y Redundancia

En base a los criterios de normalizacin y dado que por definicin una frmulasiempre puede ser calculada, no es necesario que la misma este almacenada y bastacon recalcularla cada vez que sea necesario.Sin embargo el hecho que la frmula no este almacenada puede ocasionar problemas

de performance, debido al tiempo que pueda demorar el reclculo.Para evitar este inconveniente se puede definir la frmula como REDUNDANTE. Eneste caso la frmula se almacena en la Base de Datos y no es necesario recalcularla

Tablassuperordinadas aPedidos


46/129


40

cada vez que se use. Una vez que la frmula es definida como redundante, GENEXUSse encarga de agregar todas las subrutinas de mantenimiento de redundancia a todaslas transacciones que utilicen esa frmula.Tenemos entonces que la definicin de frmulas redundantes implica un balance deperformance por un lado y almacenamiento y complejidad de los programasgenerados en otro, que el analista debe decidir. Si bien en teora esta decisin puedeser bastante difcil de tomar, en la practica vemos que la mayor parte de las frmulasque se definen redundantes son las verticales (mas adelante veremos que hay unaforma muy fcil de hacerlo) y pocas veces las horizontales.La razn de esto es que el calculo de las frmulas verticales pueden insumir unnmero indeterminado de lecturas. Por ejemplo para calcular el PedTotse deben leertodas las lneas del pedido, que pueden ser una cantidad bastante grande.

Frmulas de FrmulasUna frmula se calcula a partir del valor de otros atributos. Dichos atributos puedenestar almacenados o ser otras frmulas. Por ejemplo si en la transaccin deProveedores definimos:

PrvTotPed= SUM( PedTot) Total pedido del proveedor

tenemos que para calcularlo se necesita:

PedTot= SUM( PedImp )

que a su vez necesita:


Para frmulas de frmulas GENEXUS determina cual es el orden de evaluacincorrespondiente:

PedImp = PedCnt* PedPrePedTot = SUM( PedImp )PrvTotPed = SUM( PedTot)


47/129


41

ReglasSegn el Anlisis Orientado a Objetos, para cada objeto del sistema se debe definir cuales su estructura y cual su comportamiento. En el caso de las transacciones ya vimos ladefinicin de la estructura. Para definir el comportamiento se usan las REGLAS.Usando reglas se definen valores por defecto, controles, etc. Veremos algunas de lasreglas:

Default

Se utiliza para definir los valores por defecto de algunos atributos, por ejemplo:

default( PedFch, today() );

El funcionamiento del default varia segn el tipo de dilogo (full-screen o campo acampo). En el dilogo full-screen se asigna el valor por defecto si el usuario no digitonada en el campo. En el dilogo campo a campo primero se asigna el valor pordefecto y luego se permite modificarlo.

Error

Es la regla para definir los controles que deben cumplir los datos, por ejemplo siqueremos que el precio del articulo pedido sea siempre mayor que 100:

error( 'El precio debe ser mayor que 100') if PedPre


48/129


42

las tablas que pertenecen a la tabla extendida del nivel. Veamos un ejemplo, en latransaccin de Artculos:

Artculos:ArtCod*ArtDscArtCntArtFchUltCmpArtPrcUltCmp

En el atributoArtPrcUltCmp se desea almacenar cual fue el precio del ltimo pedidorealizado para ese articulo, y en que fecha fue realizado enArtFchUltCmp. Esto serealiza definiendo en la transaccin de Pedidos las siguientes reglas:

ArtPrcUltCmp = PedPre if insert;ArtFchUltCmp = PedFch if insert;

As cada vez que se ingrese una lnea del pedido se actualiza la tabla de Artculos conla fecha y el precio correspondiente.

Existe una similitud entre frmulas y asignaciones, incluso la sintaxis de definicin essimilar. La diferencia entre ambas es que una frmula es GLOBAL, es decir vale paratodos los objetos GENEXUS que la utilicen, mientras que una Asignacin es LOCAL,vale solo para la transaccin en la cual fue definida.Cuando un atributo es frmula este no esta almacenado (a no ser que se lo definacomo redundante) y cuando es una Asignacin, por ser esta local, si esta almacenado.

Add y Subtract

Las asignaciones que vimos en la seccin anterior eran relativamente fciles, peroexisten casos mas sofisticados. Por ejemplo en la misma transaccin de Artculostenemos el atributoArtCnten donde se quiere mantener cual es el stock que tenemosde cada articulo.Sin duda la transaccin de Pedidos debe modificar ese valor, porque cada pedidonuevo aumenta el stock. Tambin existir alguna otra transaccin que hace disminuirel stock, que podra ser por ejemplo una transaccin de Facturacin que se realizacuando se vende el articulo. Como esta transaccin esta fuera del alcance del proyectosolo estudiaremos la actualizacin del stock relacionada con la transaccin dePedidos.

En dicha transaccin se debe actualizar ArtCnt, esto se podra hacer con laAsignacin:


49/129


43

ArtCnt=ArtCnt+ PedCnt;

Pero no debemos olvidar que en la misma transaccin se permite crear, modificar oeliminar un pedido, y la asignacin anterior solo es correcta si se esta creando unonuevo, ya que si por ejemplo se est eliminando, la asignacin correcta es:

ArtCnt=ArtCnt- PedCnt;

Entonces, para actualizarArtCntcorrectamente se necesitara tambin considerar loscasos de modificacin y eliminacin, pero para evitar todo esto GENEXUS posee laregla add() que lo hace automticamente:

add(PedCnt,ArtCnt);

Con esta regla si se esta insertando una lnea del pedido se suma la PedCntaArtCnt,si se esta eliminando se resta y si se esta modificando le resta el valor anterior dePedCnt(que se define como old(PedCnt) ) y le suma el nuevo valor.Existe una dualidad entre la frmula vertical SUM y la regla ADD, masconcretamente se puede decir que un SUM redundante es equivalente a la regla ADD.Por ejemplo el PedTotse puede definir como:

PedTot= SUM( PedImp ) y redundanteoadd( PedImp, PedTot);

Dado que es comn que las frmulas verticales tengan que estar redundantes para

tener buena performance se recomienda el uso de la regla ADD y no la frmula SUM.La regla SUBTRACT es equivalente pero realiza las operaciones contrarias, es decircuando se esta insertando resta, en caso de eliminacin suma, etc.

Serial

Esta regla es til cuando se quiere asignar automticamente valores a algnidentificador de la transaccin. Por ejemplo en la transaccin de Pedidos tenemos elPedLinNro y si queremos que este nmero sea asignado automticamente por elsistema se puede usar la regla:

serial(PedLinNro, PedUltLin, 1);

En donde el primer parmetro define cual es el atributo que se esta numerando, elsegundo indica cual es el atributo que tiene el ltimo valor asignado (aqu se trata delltimo nmero de lnea asignado) y el tercer parmetro el incremento (en este caso seincrementa de a uno). El atributo PedUltLin (Ultima lnea asignada) debe ser incluido


50/129


44

en la estructura de la transaccin en el nivel de PedNro (un pedido solo tiene UNAUltima lnea asignada):

PedNro*....

PedUltLin( PedLinNro*

....)

PedTot

De esta manera para cada nueva lnea del pedido el programa asigna automticamentesu nmero.

En el dilogo campo a campo (donde la modalidad era inferida automticamente), sedebe digitar un valor inexistente en PedLinNro (usualmente 0) y el programa asigna elvalor correspondiente.En el dilogo full-screen el valor se asigna cuando el usuario presiona Enter en modoInsertar.

Orden de evaluacin

La definicin de reglas es una forma DECLARATIVA de definir el comportamientode la transaccin. El orden en el cual fueron definidas no necesariamente indica queese sea el orden en que se encuentran en el programa generado.GENEXUS se encarga de determinar el orden correcto segn las dependencias deatributos existentes.

Veamos un ejemplo:

Supongamos que definimos en la transaccin de Artculos un nuevo atributo:ArtCntMax, del mismo tipo queArtCnt. Este atributo indicar el stock mximo quese desea tener de ese artculo.Cuando se ingresa un pedido debemos emitir un mensaje si se sobrepasa el stockmximo de un artculo. Para ello definimos las siguientes reglas en la transaccin depedidos:

msg( 'Se sobrepasa el stock mximo del artculo' )ifArtCnt>ArtCntMax;

add(PedCnt,ArtCnt);El orden de evaluacin ser:


51/129


45

add(PedCnt,ArtCnt);

msg( 'Se sobrepasa el stock mximo del artculo' )ifArtCnt >ArtCntMax;

Ya que la regla add() modificaArtCnty la regla msg() utiliza ese atributo.Esto implica que en la regla msg() se debe preguntar por ArtCnt mayor queArtCntMax y no porArtCnt + PedCnt mayor que ArtCntMax.

Cada vez que se especifica una transaccin se puede pedir la opcin -"DetailedNavigation"- que lista cual es el orden de evaluacin. En este listado se explcita enque orden se generarn (usualmente decimos 'se disparan'), no solo las reglas, sinotambin las frmulas y lecturas de tablas.

Call y funcin After

Otra regla muy usada es CALL, con la cual se permite llamar a otro programa. Estepuede ser cualquier otro objeto GENEXUS, por ejemplo, de una transaccin se puedellamar a un reporte o a otra transaccin, o un programa externo.En el caso de la regla Call es necesario precisar en que MOMENTO se debe dispararel Call. Por ejemplo, si en la transaccin de Pedidos se quiere llamar a un reporte queimprime el pedido que se acaba de ingresar, se utiliza la regla:

call('RIMPREC', PedNro) if after( trn ) ;

En donde 'RIMPREC' es el programa llamado y PedNro es el parmetro que se le

pasa. Al tener after(trn), el Call se realizar despus de haber entrado todo el Pedido.El uso de after() no es privativo de la regla Call y puede ser utilizado en otras reglas,como ser error o Asignacin.Los after() existentes son:

Confirm

La regla se dispara despus de haber confirmado los datos del nivel pero antes dehaber realizado la actualizacin. Se usa para algunos casos de numeracin automticacuando no se quiere utilizar la regla serial para evitar problemas de control deconcurrencia.


52/129


46

Insert | Update | DeleteSe dispara despus de haber insertado, actualizado o eliminado el registro de la tablabase del nivel. Se usa fundamentalmente para llamar a procesos que realizanactualizaciones.

Level

Se dispara despus de haber entrado todos los datos de un nivel. Se usa muchas vecespara controles de totales, por ejemplo, si cuando se entra el cabezal del Pedido sedigita un total (llammosle PedTotDig) y se quiere verificar que este sea igual que eltotal calculado la regla es:

error( 'El total digitado no cierra con el calculado' ) if PedTotDig PedTot.and. after( level(ArtCod) );

En donde el control recin se realizar cuando se terminaron de entrar todas las lneasdel pedido.

Trn

Se dispara despus de haber entrado todos los datos de una transaccin. Se usafundamentalmente para llamar a programas que imprimen los datos o a otrastransacciones. En ambientes con integridad transaccional esta regla se dispara luegoque se realiza el commit de la transaccin.

Propiedades

En el editor de propiedades de las transacciones se pueden definir reglas decomportamiento general. A continuacin vemos la pantalla para la edicin de las mismas:


53/129


47

Por ejemplo vamos a setear propiedades que estn asociadas con el manejo de laintegridad transaccional y con la interface. Podemos indicar si deseamos que latransaccin haga un commit al final o que no deseamos que se pidan confirmaciones cadavez que se actualiza un nivel, etc.


54/129


48

DISEO DE REPORTES

Con Reportes se definen los procesos no interactivos de extraccin de datos. Usualmenteun Reporte es un listado que se enva a la impresora, aunque tambin puede servisualizado en pantalla.

Es un proceso no interactivo, porque primero se extraen los datos y luego se muestran, nohabiendo interaccin con el usuario durante el proceso de extraccin, y es solo deextraccin ya que no se pueden actualizar los datos ledos. Para consultas interactivas seutilizan los Paneles de Trabajo y para los procesos de actualizacin los Procedimientos.

Para cada Reporte se debe definir:

InformacinDatos generales del Reporte, por ejemplo nombre, descripcin, etc.

LayoutAs como las Transacciones tienen una pantalla los Reportes tienen un layout de la salida.

CondicionesQu condiciones deben cumplir los datos para ser impresos.

Reglas - PropiedadesDefinen aspectos generales del Reporte.

AyudaTexto para la ayuda a los usuarios en el uso del Reporte.

DocumentacinTexto tcnico para ser utilizado en la documentacin del sistema.

Layout

En el Layout se define simultneamente la estructura de la navegacin (que datos sequieren listar y en que orden) y el formato de la salida. Para ello se utiliza un lenguajeprocedural muy simple que describiremos brevemente a continuacin.Comencemos por un Reporte para listar todos los proveedores:


55/129


49

En donde tenemos los comandos Header, End, For each y Endfor. Para describir msfcilmente el funcionamiento de estos comandos veamos el resultado de ejecutar elprograma generado correspondiente:

Literales

Atributos

Bloque de

cdigo

Bloque deimpresion


56/129


50

La definicin de reportes se divide en uno o varios bloques. Estos bloques pueden ser decdigo o de impresin . En los bloques de impresin se disea la salida queposteriormente ser impresa. Cada bloque de impresin puede tener un conjunto decontroles (atributos, variables, textos, etc.). Podemos ver un bloque de impresin como unpedazo de papel. Los bloques de impresin (o Print Blocks) tienen asociadas ciertaspropiedades, que pueden seteadas desde un dialogo que se abre al hacer doble-click sobreel bloque de impresin, como ser: los colores a usar, el tipo de papel, el tipo de letra, etc.El dialogo es el siguiente

Para el diseo de los bloques de impresin tenemos disponible una paleta de herramientassimilar a las transacciones.


57/129


51

La cual permite insertar atributos, textos, lneas, recuadros, bitmaps y nuevos bloques deimpresin. Los controles son definidos de la misma forma en que se hace en el editor delform de las Transacciones (tipo de letra, color, tamao, etc.).

Todos los bloques de impresin que se encuentren entre los comandos HEADER y ENDson las lneas que se imprimen en el cabezal de la pagina. Tambin existe el comandoFOOTER que permite imprimir un pie de pgina en cada hoja.

El comando FOR EACH indica que se impriman todos los bloques de impresin que seencuentren entre el FOR EACH y el ENDFOR para cada uno de los datos que seencuentren en la base de datos. En este caso:

se debe imprimir para cada uno de los proveedores.

Comando FOR EACH

Este es, quizs, el comando ms importante en los Reportes ya que toda la definicindel acceso a la base de datos y la estructura del reporte se realizan solo con estecomando.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 seespecifica de que tablas se deben obtener, ni que ndices se deben utilizar. Por lo

tanto, con este comando se define QUE atributos se necesitan y en qu ORDEN sevan a recuperar, y GENEXUS se encarga de encontrar COMO hacerlo. Obviamenteesto no siempre es posible, y en estos casos GENEXUS da una serie de mensajes deerror indicando porque no se pueden relacionar los atributos involucrados.La razn por la cual no se hace referencia al modelo fsico de datos es para que laespecificacin del Reporte sea del mas alto nivel posible, de tal manera que antecambios en la base de datos la especificacin del mismo se mantenga valida la mayorparte de las veces.El acceso a la base de datos queda especificado por los atributos que son utilizadosdentro de un grupo FOR EACH - ENDFOR. Para ese conjunto de atributos GENEXUSbuscar la tabla extendida que los contenga (el concepto de tabla extendida es muyimportante en este comando y sugerimos repasar su definicin en el Anexo sobreModelos de Datos Relacionales).

Por ejemplo, en el Reporte anterior dentro del FOR EACH - ENDFOR se utilizan losatributos PrvCod, PrvNom y PrvDir, GENEXUS 'sabe' que estos atributos seencuentran en la tabla PROVEEDO y por lo tanto el comando:

PrvCod PrvNom PrvDir


58/129


52

For each

Endfor

es interpretado por GENEXUS como:

For each record in table PROVEEDO

Endfor

Para clarificar el concepto hagamos un Reporte que involucre datos de varias tablas.

Por ejemplo, listar el cabezal de todos los pedidos:

Fecha: 09/08/92 Listado de Pedidos

Nmero Fecha Nombre Proveedor Nombre Analista

321 02/02/92 ABC Inc. Juan Gomez654 03/03/92 GXXXX Corp. Juan Gomez987 03/03/92 ABC Inc. Pedro Perez




59/129


53

El layout para este listado es:

Si recordamos el modelo de datos definido en el captulo Diseo de Transacciones, elDiagrama de Bachman es:


60/129


54

En el listado anterior se requieren datos de las tablas PROVEEDO (PrvNom),ANALISTA (AnlNom) y PEDIDOS (PedNro y PedFch). La tabla extendida dePEDIDOS contiene a todos estos atributos y por lo tanto el comando FOR EACH seinterpretar como:

For each record in table PEDIDOSFind the corresponding PrvNom in table PROVEEDOFind the correspondingAnlNom in table ANALISTA

Endfor

Cuando se especifica un Reporte, GENEXUS brinda un listado (que llamaremosListado de Navegacin) donde se indica cuales son las tablas que se estnaccediendo, en este caso el listado es:

AnlNomPrvNomPedFchPedNro


61/129


55

FOR EACH PEDIDOS (Line 6)Order : PedNroIndex : IPEDIDOSNavigation filters:

Start from:First record

Loop while:Not end of table

---->> PEDIDOS ( PedNro )|+-----> ANALISTA ( AnlNro )

|+-----> PROVEEDO ( PrvCod )

END FOR

Donde la flecha doble ( --->> ) indica cual es la tabla base de la tabla extendida y laflecha simple ( ----> ) las tablas N-1 de la misma. Una interpretacin muy prctica deeste diagrama es: para la tabla de la flecha doble se leen muchos registros y para cadatabla con flecha simple se lee un solo registro por cada registro ledo en la tabla conflecha doble.

Orden

En los Reportes anteriores no se tuvo en cuenta en que orden se deben listar los datos.Cuando no se indica el orden, GENEXUS busca un orden que favorezca la performancedel Reporte.Para los casos en donde se quiere definir el orden de los datos de forma explcita seutiliza la clusula ORDER en el comando FOR EACH, por ejemplo, para listar lospedidos ordenados por PrvCod:

For each ORDERPrvCod

Endfor

En este caso el ndice a utilizar ser el IPEDIDO2 (PrvCod) de la tabla PEDIDOS,que fue definido automticamente por GENEXUS. La navegacin para este reporte esla siguiente:


Tablas a las cualesaccede.


62/129


56

FOR EACH PEDIDOS (Line 6)Order : PrvCodIndex : IPEDIDO2Navigation filters:

Start from:First record

Loop while:Not end of table

---->> PEDIDOS ( PedNro )|+-----> ANALISTA ( AnlNro )

|+-----> PROVEEDO ( PrvCod )

END FOR

Si al listado anterior lo queremos ordenar por PedFch:

For each ORDERPedFch

Endfor

Como no hay ningn ndice definido en la PEDIDOS para PedFch, GENEXUS crearun ndice por PedFch cada vez que se ejecute el Reporte y lo eliminar al finalizar elmismo y en el Listado de Navegacin indicar que esta creando un 'ndice temporario'.

Navegacin:A temporary index will be created for PedFch on table PEDIDOS

Obviamente este proceso es ms lento si lo comparamos con el listado anterior endonde haba un ndice definido. Dada esta situacin el analista debe tomar unadecisin:Crear un ndice del usuario. En este caso el Reporte ser bastante ms eficiente, perose debe mantener un ndice ms (lo que implica mayor almacenamiento y mayor

procesamiento en las transacciones para mantener actualizado el ndice).Dejar el Reporte con el ndice temporario.


indiceseleccionado


63/129


57

No es posible recomendar, a priori, cual de las dos soluciones es la mejor, por lo tantose debe estudiar caso por caso la solucin particular, siendo fundamental la frecuenciacon que se ejecutar el Reporte. De cualquier manera si al comienzo no se defini elndice y posteriormente se decide cambiar y definirlo, alcanza con regenerar elReporte (sin modificar nada del mismo) y ste pasar a utilizarlo.Los criterios de ordenamiento utilizado por GENEXUS son:Cada grupo FOR EACH puede estar ordenado por CUALQUIER conjunto deatributos pertenecientes a la tabla base del grupo, pero no se puede ordenar poratributos que NO se encuentren en la misma. Por ejemplo el listado anterior no sepuede ordenar por PrvNom porque la tabla base del grupo es la PEDIDOS que notiene PrvNom.Si no existe un ndice para el orden pedido se crea un ndice temporario que seeliminar al finalizar el Reporte. Observar que este proceso es anlogo a realizar un

SORT cuando se trabajaba con archivos tradicionales.Condiciones en el FOR EACH

Para restringir los datos que se quieren listar se utiliza la clusula WHERE. Porejemplo, para listar slo los pedidos de hoy:

For eachWHERE PedFch = Today()

Endfor

Se puede definir varios WHERE dentro del FOR EACH:

For eachWHERE PedFch = Today()WHERE PedNro > 100

Endfor

Que significa que se deben cumplir AMBAS condiciones, o sea que se interpretacomo que ambas clusulas estn relacionadas por un AND. Si se quiere utilizar un OR(es decir se desea que se cumpla alguna de las dos condiciones) se debe utilizar unsolo WHERE:

For each




64/129


58

WHERE PedFch = Today() OR PedNro > 100

Endfor

GENEXUS posee una serie de mecanismos para optimizar el Reporte en funcin delorden del FOR EACH y de las condiciones del mismo, pero estas se aplican slo a lascondiciones que tienen la siguiente forma:

WHERE

WHEN NONE

Donde: debe estar almacenado en la tabla base. debe ser = o >=. puede ser una constante o una variable. se ejecuta solo cuando no se entra en el For Each

En muchos casos es necesario ejecutar determinado cdigo cuando en un For Each nose encuentra ningn registro. Para esto se usa el comando WHEN NONE. Esimportante aclarar que si se incluyen For Eachs dentro del When None no se infierenJoins ni filtros de ningn tipo con respecto al For each que contiene el When None.

Cuando la condicin ha sido optimizada en el Listado de Navegacin aparece como'Navigation Filter' y cuando no, como 'Constraint'.Tener en cuenta que cuando la condicin tiene esta forma se realizara algn tipo deoptimizacin, pero no quiere decir que otras formas no sean vlidas, al contrario, en elWHERE se pueden definir condiciones para atributos que son frmulas, que no seencuentran en la tabla base, etc.

Determinacin de la tabla extendida del grupo FOR EACH

Resulta muy til saber cmo GENEXUS determina la tabla extendida que se debeutilizar. El criterio bsico es:Dado el conjunto de atributos que se encuentran dentro de un grupo FOR EACH -ENDFOR, GENEXUS determina la MINIMA tabla extendida que los contenga.Consideremos nuevamente el listado:



65/129


59

For each

Endfor

Segn ya vimos todos estos atributos se encuentran dentro de la tabla extendida dePEDIDOS, sin embargo, tambin se encuentran dentro de la tabla extendida dePEDIDOS1 (Lnea del pedido), pero la tabla extendida de PEDIDOS est contenidaen la de PEDIDOS1 (porque justamente la de PEDIDOS1 contiene a la de PEDIDOSadems de otras tablas), y por lo tanto ser la elegida porGENEXUS.Para que GENEXUS pueda determinar cual es la tabla extendida del grupo FOR EACHdebe haber por lo menos un atributo que pertenezca a la tabla base. Por ejemplo, en el

Reporte que estamos realizando hay dos atributos pertenecientes a la tabla basePEDIDOS (PedNro y PedFch), si ellos no estuvieran y el listado fuera:

For each

Endfor

se podra argumentar que la tabla extendida de PEDIDOS contina siendo vlida, sinembargo por razones de simplicidad GENEXUS en este caso indicar que no hayrelacin entre estos dos atributos y ser necesario que se utilice algn atributo de latabla PEDIDOS para poder generar el Reporte.

Tambin puede darse el caso que exista ms de una tabla extendida mnima quecontenga a los atributos del grupo FOR EACH - ENDFOR. Ante esta ambigedadGENEXUS escoge la PRIMERA tabla extendida que cumpla con las condicionesanteriores.Para resolver estos dos problemas (no hay ningn atributo de la tabla base y hay msde una tabla extendida mnima posible), se utiliza la clusula DEFINED BY dentrodel comando FOR EACH, por ejemplo:

For eachDefined byPedFch

Endfor

AnlNomPrvNom


manual de genexus[1]

Documents