Oracle Forms Developer: añadir funcionalidad a Elementos
Controlar los datos de un elemento de texto
Copiar Valor de Elemento
Esta propiedad especifica el origen del dato que se utilizará para rellenar el valor de un campo de un formulario. Cuando establecemos una relación maestro-detalle, Forms Builder establece automáticamente esta propiedad en los campos de la FK en el bloque detalle. Este valor hace referencia a la PK del bloque maestro utilizando la notación punto (<nombrebloque>.<nombrecampo>), cuyo valor se copiará en los campos de la FK en el bloque detalle cuando se crea un nuevo registro o bien cuando se consulta.
El valor de esta propiedad no será una variable ligada, es decir, no se antepone el carácter dos puntos (":") al nombre del bloque, tal y como se muestra en el siguiente ejemplo:
Sincronizar con elemento
Esta propiedad se utilizará para especificar el nombre del campo a partir del cual el elemento actual derivará su valor y quedarán ambos sincronizados. Por tanto, ambos campos se comportarán como si fueran espejos, es decir, si el usuario final modifica el valor de uno de ellos, el cambio se verá reflejado también en el otro campo. Esta propiedad presenta un desplegable con los distintos campos disponibles en el formulario al que se quiera ligar el comportamiento del elemento actual.
Funcionalidad de CheckBoxes
Los CheckBox son una muy buena alternativa para cuando queremos realizar un mismo proceso que afecta a varios registros. Nos va a permitir seleccionar sobre qué registros se realizará una acción determinada.
Si el elemento de tipo CheckBox mapea un campo de una tabla de la base de datos, este elemento representará un valor booleano. En función de cómo esté declarado el campo en la base de datos, el valor del elemento en el formulario podrá ser de dos tipos, bien Number o bien Char, puesto que son las únicas formas de representar un valor booleano (Number: 0 falso, 1 verdadero; Char: 'F' o 'N' para el falso y 'V' o 'S' para el verdadero).
Si el elemento de tipo CheckBox no mapea ningún campo de la base de datos, tendrá una función meramente de control, para marcar aquellos elementos sobre los que se va a realizar una determina acción.
Si tenemos un bloque multi-registro (EMP) y hemos incluido un elemento de tipo CheckBox, podemos añadir otro elemento check en un bloque de control (B_CONTROL) para añadir la funcionalidad de marcar/desmarcar todos.
GO_BLOCK('EMP');
FIRST_RECORD; -- nos posicionamos en el primer registro del bloque a recorrer
LOOP
IF :B_CONTROL.SELTODOS='S' THEN -- si el check del bloque de control
:EMP.CHK_EMP:='S'; -- está marcado, cada registro del
-- bloque EMP se marcará
ELSE -- si el check del bloque de control no está marcado,
:EMP.CHK_EMP:='N'; -- cada registro del bloque EMP se desmarcará
END IF;
EXIT WHEN :SYSTEM.LAST_RECORD='TRUE'; -- evaluamos la condición de
-- continuación del recorrido
NEXT_RECORD; -- si no estamos en el último registro, avanzamos para seguir
END LOOP; -- tratando el siguiente
FIRST_RECORD; -- volvemos al primer registro del bloque
GO_BLOCK('B_CONTROL'); -- devolvemos el foco al bloque de control
IF :B_CONTROL.SELTODOS = 'S' THEN
SET_ITEM_PROPERTY('B_CONTROL.SELTODOS',TOOLTIP_TEXT,'Desmarcar todos');
ELSE
SET_ITEM_PROPERTY('B_CONTROL.SELTODOS',TOOLTIP_TEXT,'Marcar todos');
END IF;
Para que nada más entrar al formulario esta opción también esté disponible, habría que añadir la línea de código correspondiente al "marcar todos" en el trigger WHEN-NEW-FORM-INSTANCE.
Funcionalidad de los RadioButton
A diferencia de los CheckBox, que permiten realizar una selección múltiple, los RadioButton son elementos que sirven para realizar una selección de valor entre las distintas alternativas posibles. Es decir, existen varios valores, pero solo uno de ellos será el seleccionado.
Los RadioButton son una alternativa muy buena para el filtrado de datos en los bloques multi-registro. Vamos a verlo con un ejemplo:
Dentro de las propiedades asociadas al RadioGroup modificaremos, al menos, las siguientes: nombre, tipo de dato, longitud y el valor inicial. Este valor inicial se tendrá que corresponder con el valor de alguno de los RadioButton asociados al RadioGroup.
En cuanto a las propiedades asociadas a los RadioButton, modificaremos, el menos, las que enumeramos a continuación: nombre, etiqueta (literal que se visualiza en el lienzo) y valor de botón de radio (valor que tomaría la variable si se selecciona dicha opción).
Una vez que hemos modificado las propiedades tanto del RadioGroup, como de los distintos RadioButton, podremos modificar las propiedades visuales del color de fondo para que el fondo de la etiqueta (no es transparente) coincida con el color del lienzo y así no se visualice la forma rectangular de la etiqueta.
IF :B_CONTROL.RG_DEPART = 'T' THEN -- si el valor del RadioGroup es 'T' (todos), no se filtra,
-- es decir, se asigna el valor del departamento a sí -- mismo para que recupere todos los registros
:EMP.DEPTNO := :EMP.DEPTNO;
ELSE -- en caso contrario se le asigna al campo departamento, -- el valor del RadioGroup
:EMP.DEPTNO := :B_CONTROL.RG_DEPART;
END IF;
Pero esto solo no sería suficiente. Además del PRE-QUERY, debemos añadir el siguiente código en el trigger WHEN-RADIO-CHANGED del RadioGroup:
Es decir, que cada vez que se marca una opción del RadioGroup, pase el foco al bloque EMP y ejecute la consulta sobre el bloque. Esto activará el trigger PRE-QUERY del bloque que, en función del valor del RadioGroup, filtrará los datos del bloque según corresponda.
En la siguiente imagen se muestra el resultado final. Podemos comprobar cómo en el RadioButton está seleccionada la opción del Departamento con código 10 y en el bloque donde se muestran los empleados solo aparecen aquellos que pertenezcan a dicho departamento.
Listas de Valores (LOVs) dinámicas
Para crear las listas de valores, es necesario previamente establecer el origen de los datos de dicha lista, es decir, necesitamos el Grupo de Registros en el que se basa la LOV. Por tanto, al final tendremos un conjunto de pares (Grupo de Registro - Lista de Valores) que nos permitirán mostrar una serie de alternativas al usuario en forma de lista.
Al igual que ocurre con los elementos de lista (itemList), las LOV quedan definidas en tiempo de diseño, donde el desarrollador establece a qué grupo de registros está asociada cada lista de valores. A pesar de que la lista de valores está basada en una consulta y, por tanto, si hay una alteración en los datos que devuelve dicha consulta, estos se reflejarán en tiempo real a la hora de mostrar la LOV, no deja de ser una consulta estática, que no va a sufrir variantes.
Las LOV pueden hacerse más flexibles cuando se asignan a los items en tiempo de ejecución, en lugar de en el tiempo de diseño. La asignación se realizará mediante la Built-in SET_ITEM_PROPERTY. Por otro lado, es posible usar una única lista de valores para varios elementos modificando la consulta de su grupo de registros en tiempo de ejecución utilizando POPULATE_GROUP_WITH_QUERY.
Este sería un ejemplo de modificación del Grupo de Registro en tiempo de ejecución: