Prompt

Los Prompts tienen dos momentos, uno que es el de la definición y otro que es el de la referencia a un Prompt.

El Prompt se define debajo del nodo Level de la instancia y se refiere a la Transacción base de la misma. Allí se pueden definir tantos Prompts como sean necesarios.

Puede ser necesario definir múltiples Prompts por varios motivos, pero lo más común es que se trate de una Transacción muy compleja y que en determinados casos tengamos que filtrar por determinado atributo y en otros por otros, para mostrar cosas distintas, etc. Entonces, haciendo botón derecho sobre el nodo Level y Add prompt un par de veces, nos aparecen dos nodos Prompts.

Ahora podemos preguntarnos qué pasa con la nomenclatura de estos objetos.El nodo Level es el que comanda la nomenclatura de todos los objetos que tiene debajo de él. Al nodo Prompt el sistema le agrega un “Pr” como prefijo al nombre declarado en el Level, pero ¿cómo se resuelven sus nombres cuando hay más de uno?.

El tema es así, con el primer Prompt declarado no hay problema, no es necesario declarar su propiedad “Name” porque el sistema lo va a identificar como “Pr<nombre de Level>”, pero ya para el segundo es necesario declarar obligatoriamente un “Name”, al que también el sistema le va a agregar el prefijo “Pr”. Es como declarar un nuevo <nombre de Level>.

Por Ejemplo, al primer Prompt el sistema lo denomina PrCli01 (ya que el Level es Cli01) y si a los siguientes les declaramos en sus respectivos “Name”: Cli02 y Cli03, para el sistema serán el PrCli02 y PrCli03 respectivamente.

Después, el Prompt no agrega mucho a lo visto respecto al Selection, es un “Trabajar Con” en sí. Tiene una particularidad que es que al ser declarado como Prompt siempre va a tener un botón que va a decir “Salir”, porque se asume que el mismo siempre va a ser llamado a ventana nueva.

Por lo demás, como dijimos es muy similar al Selection, inclusive por la posibilidad (que no está en el WorkWith original) de poder seleccionar los modos de Insert, Update y Delete en el propio Prompt.

Esto permite insertar una tupla en la Transacción, desde el propio Prompt. Por ejemplo, vamos a ingresar una factura que nos solicita identificar al cliente, para lo cual accedemos al botón de Prompt. Sucede que el cliente no fue creado, entonces, allí mismo hago un insert y accedo a la Transacción en modo Insert para agregar el nuevo cliente.

Y puedo insertarlo desde la ventana superior. Esto que parece sencillo tiene varios temas de debimos solucionar: Por ejemplo, el Recent Link de las ventanas Pop Up en forma independiente de los Recent Link de las ventanas principales de abajo. Cada nuevo nivel superior de Pop Up que se vaya generando va a tener su Recent Link independiente.

Otro tema que tuvimos que solucionar es la visualización de las pantallas. Ahora la Master Page es capaz de detectar si está en un estado de ventana principal o en un estado de ventana Pop Up y en función de este estado muestra o no muestra el entorno de navegación, cabezal y (si hubiera) pié de página.

Ya en el WorkWith original era razonable que todos los Prompts relativos a una Transacción tuvieran que ser declarados en la instancia basada en esa Transacción, pero ahora que le agregamos los modos Insert, Update y Delete, más que nunca tiene sentido esto porque esos modos tienen que ser comandados por la Transacción en que se basa dicha instancia.

Si declaramos los modos por defecto me va a llamar a esa Transacción. Esto en cuanto a la generación del Prompt, pero después tenemos el tema de las referencias a ese Prompt. Por ejemplo, si estamos trabajando en "Factura" podemos querer referenciar el Prompt de "Clientes". Estando en el atributo "ClienteNro" le podemos asociar un nodo Prompt haciendo botón derecho en el nodo "ClienteNro" y Add prompt. Pero hay que tener cuidado, porque si hacemos esto y dejamos todo por defecto, en realidad puedo no estar vinculándolo directamente al atributo. En este caso, lo único que está haciendo el Pattern es generar la Regla Prompt y si no le paso parámetros, asume que el único parámetro que hay que pasar es el asociado al atributo que declaramos en la instancia.

O sea que va a poner: “Prompt <Nombre del objeto declarado en GXObject> (en este caso HPrCli03) y el parámetro va a ser "ClienteNro". En este caso seguramente el Prompt va a estar asociado a "ClienteNro", pero si tenemos un Prompt con una clave compuesta (una Transacción con Fecha, Tipo y Número) y ponemos el Add prompt sobre un campo, el número por ejemplo, si lo hacemos así nomás y le pasamos los tres atributos (allí tenemos que declarar explícitamente Fecha, Tipo y Número porque en realidad son los tres parámetros), la Regla Prompt me va a asociar el Prompt a cada uno de los atributos que pasamos por parámetros y fueron declarados en el Prompt como de “Out”. Más allá de que de pronto lo asociamos a un solo atributo, después GeneXus lo termina asociando a todos lo atributos que fueron pasados por parámetros y que son de “Out” (los que devuelven).

Por eso dijimos que podemos declarar el Add prompt debajo del atributo "ClienteNro" pero en realidad puede que no esté directamente asociado allí. Esto pasa si declaramos el Forced en False, en la sección General. El Forced en False simplemente está determinando la declaración de la Regla Prompt. Si en cambio declaramos el Forced en True, lo que estamos declarando es que ahí sí, este Prompt está asociado a un Control de Edición concretamente.

Si no se declara el nodo Parameters, asume que el único parámetro que hay que pasar es el atributo asociado. Si está declarado el nodo Parameters, el sistema va a atender exclusivamente lo declarado en ese nodo sin asumir nada respecto al atributo asociado, de modo que tenemos que agregar todos los parámetros.

Grupos de Propiedades:

Sub Nodos:

  • Parameters

  • Attributes

  • Modes

  • Orders

  • Filter

  • Fixed Data

  • Codes

  • Actions

  • Variables

  • Confirms

  • Help

  • Documentation