Cuando se está ejecutando un formulario, el usuario final va a recibir información sobre determinados eventos en el transcurso de su sesión. Estos mensajes pueden aparecer de dos formas distintas:
Cuando se realiza una llamada a un un subprograma desde un trigger, esta llamada puede fallar sin que se llegue a generar una excepción, es decir, el código continúa su ejecución normal, a menos que tomemos las acciones oportunas para detectar un fallo.
Las Built-in que existen para detectar tanto el Éxito como el Fracaso de la ejecución de un subprograma son:
La más utilizada es sin duda FORM_SUCCESS que devuelve FALSE en caso de error, sea del tipo que sea.
Ejemplo de Error en tiempo de Ejecución
Imaginemos que queremos acceder a un bloque nada mas entrar a un formulario. En el trigger When-New-Form-Instance escribiremos el código GO_BLOCK('EMPL'). Al escribir el nombre del bloque, nos hemos equivocado, ya que el bloque EMPL no existe. Al tratarse de una cadena de texto, el compilador no detecta error en tiempo de compilación, así que, si no nos damos cuenta, el posible error vendrá en tiempo de ejecución.
Como vemos, no muestra datos en el bloque EMPL, pero sigue el transcurso del código y se llega a visualizar los datos en el bloque inferior. Si no estamos muy atentos, no nos damos cuenta de que aparece un mensaje en la barra de estado.
Posible Solución
Para escribir un código totalmente blindado ante fallos de este tipo, podremos utilizar la Built-in FORM_SUCCESS y controlar el error. Esta podría ser una posible solución:
DECLARE
n NUMBER;
BEGIN
GO_BLOCK('EMPL');
IF FORM_SUCCESS THEN
EXECUTE_QUERY;
ELSE
n := f_mostrar_alerta('ERROR','ERROR','El bloque no existe');
RAISE FORM_TRIGGER_FAILURE;
END IF;
END;
El resultado sería el siguiente:
En este caso sí se aborta la ejecución del programa.
Los mensajes Informativos y los mensajes de Error se muestran en la barra de estado de la aplicación, de ahí la importancia que tiene que los usuarios finales utilicen la aplicación a pantalla completa o utilicen una resolución de pantalla que le permita ver todo el formulario. De lo contrario, es posible que se estén produciendo errores y que el usuario no vea los mensajes que se están generando.
También es posible mostrar mensajes de aplicación en la barra de estado, utilizando en cualquier trigger la llamada a la Built-in MESSAGE, pasando como parámetro la cadena de texto que deseamos mostrar.
Los triggers: ON-ERROR y ON-MESSAGE
Los mensajes Informativos se pueden omitir utilizando el trigger On-Message, mientras que los mensajes de Error se pueden omitir mediante el uso del trigger On-Error. Ambos triggers pueden implementarse en cualquiera de los tres niveles de abstracción que existen en las aplicaciones (Módulo o Formulario, Bloque e Item). Tanto el trigger On-Message como el trigger On-Error se utilizan para "atrapar" mensajes de información o mensajes de error propios de Oracle Forms y personalizarlos, de manera que sean más claros para el usuario final.
En los triggers On-Error se dispone de tres variables que informan sobre el error. Estas tres variables son:
Por otro lado, en los triggers On-Message también existen tres variables que aportan información sobre el mensaje que se produce. Estas variables son:
La variable de sistema :SYSTEM.MESSAGE_LEVEL
Oracle Forms solo va a emitir mensajes que estén por encima del nivel de severidad definido en la variable de sistema :SYSTEM.MESSAGE_LEVEL. El valor por defecto es 0, por lo que al abrir el formulario se van a mostrar todos los mensajes.
Si solo nos interesa que se muestren los mensajes críticos, actualiza el valor de la variable de sistema asignándole el valor 15. Si queremos mantener este valor durante toda la ejecución del formulario puedes utilizar el trigger WHEN-NEW-FORM-INSTANCE, pero si quieres cambiar el nivel de severidad para una acción concreta, por ejemplo al hacer COMMIT sobre un bloque, realiza el cambio a nivel de ese bloque. Haríamos lo siguiente:
:SYSTEM.MESSAGE_LEVEL := 15;
--
-- ejecutamos las operaciones
--
:SYSTEM.MESSATE_LEVEL := 0;
La excepción: FORM_TRIGGER_FAILURE
Cuando se fuerza la excepción FORM_TRIGGER_FAILURE con la instrucción RAISE, se aborta la ejecución del trigger de una manera ordenada.
Las Alertas son ventanas modales que se pueden mostrar por pantalla en un momento determinado. Se usan normalmente para informar al usuario final sobre un determinado evento que se produce durante la ejecución del programa, o para obligarle a tomar una determinada decisión.
Existen tres tipos o estilos de alerta, identificados por sus distintos iconos gráficos: PARAR, ATENCIÓN y NOTA.
Las alertas se crean en tiempo de diseño, desde el Navegador de Objetos, y algunas de sus propiedades se pueden modificar en tiempo de ejecución, como son el título, el mensaje y los botones. No es necesario crear tantas alertas como mensajes se quieran mostrar por pantalla, sino que lo ideal es crear una alerta de cada tipo y en tiempo de ejecución modificar los distintos mensajes a mostrar.
A la hora de utilizar Alertas en Oracle Forms, existen tres fases para la creación y visualización de las mismas. Las tres fases son:
Creación de la alerta
Para crear una alerta desde el Navegador de Objetos, tan solo tenemos que seleccionar la sección correspondiente a las Alertas y pinchar sobre el icono 
. Automáticamente aparecerá un nuevo elemento, de tipo alerta, en la sección correspondiente. Oracle Forms, como a cualquier otro elemento, le asigna un nombre por defecto que podrá modificarse desde la Paleta de Propiedades o el propio Navegador de Objetos.
 |  |
Modificación de características
En primer lugar modificamos el Nombre, asignándole un valor que sea lo suficientemente descriptivo.
En segundo lugar podríamos modificar el Título y el Mensaje, pero los dejamos en blanco, ya que de lo contrario estaríamos restringiendo el uso de esta Alerta. Como ya comentamos anteriormente, lo mejor es crear una alerta por tipo y el Título y el Mensaje asignarlo dinámicamente mediante código. Lo veremos en el siguiente apartado.
En tercer lugar definimos el Estilo de la alerta, pudiendo elegir entre Parar, Atención y Nota.
En cuarto lugar asignamos las Etiquetas a cada uno de los botones. Dependiendo del tipo de alerta, quizá convenga tener un único botón, cuya leyenda sea, por ejemplo, 'OK' o 'Aceptar' (asignaríamos valor para la etiqueta del botón 1). También nos puede interesar tener dos botones, por ejemplo que tengan leyendas 'Sí' y 'No' o bien 'Aceptar' y 'Cancelar' (asignaríamos valor para las etiquetas de los botones 1 y 2) o, por otro lado, también nos puede interesar que existan 3 botones, por ejemplo con las leyendas 'Sí', 'No' y 'Cancelar' (asignaríamos valor a las etiquetas de los botones 1, 2 y 3).
Y por último establecemos qué botón queremos que se defina como botón por defecto. En el ejemplo decimos que será el Botón 1.
El Botón por Defecto será aquel que se visualice alrededor de él una línea discontinua. En la imagen vemos claramente como el botón por defecto es el que tiene la leyenda 'No'.
Hay que tener especial cuidado con los botones por defecto, puesto que si pulsamos la tecla Enter o la Barra Espaciadora, conseguiríamos el mismo resultado que si hacemos click con el botón izquierdo del ratón, es decir, estamos seleccionado esa opción y, por tanto, se ejecutará el código correspondiente.
Invocación para visualización
Podríamos crear una función que devuelva el resultado de la llamada a SHOW_ALERT y que, además, nos permita asignar dinámicamente el Título y el Mensaje que queremos mostrar. Para asignar propiedades a una alerta utilizamos la Built-in SET_ALERT_PROPERTY cuya sintaxis es:
SET_ALERT_PROPERTY(nombre_alerta, propiedad, valor)
nombre_alerta: es una cadena de texto con el nombre de la alerta que queremos visualizar.
propiedad: es una constante de tipo numérico. Utilizaremos TITLE para indicar que la propiedad que queremos modificar es el título, y ALERT_MESSAGE_TEXT para indicar que vamos a modificar el mensaje a mostrar
Al tratarse de valores constantes, el nombre de la propiedad no va entrecomillado. Fíjate en el código que aparece en el ejemplo de más abajo.
valor: es una cadena de texto (aquí sí iría entrecomillado), o bien una variable de tipo carácter, con el contenido de la propiedad que vamos a modificar, ya sea el título o el mensaje.
Este podría ser el contenido de la función que nos facilite las llamadas para visualizar alertas y, además, nos permite tener un código flexible ya que podemos modificar en tiempo de ejecución tanto el tipo de alerta, el título y el mensaje.
Imaginemos que queremos introducir un nuevo registro para un empleado y seleccionamos un código de empleado que ya existe.
Consultar información sobre el Error
Vemos en la imagen como en la barra de estado nos muestra el siguiente mensaje FRM-40508: Error de ORACLE: No se ha podido insertar (INSERT) un registro. Esta es toda la información que tenemos del error. Si queremos más información, podemos acceder al menú Ayuda y seleccionar la opción Mostrar Error, nos aparece entonces la ventana central con el Error en la sentencia SQL y el Error Oracle. Esto ya nos aporta algo más de información, pero sigue siendo información técnica que un usuario final posiblemente no encuentre o le sea difícil "descifrar".
Primera versión del trigger On-Error
Si combinamos el uso del trigger On-Error con el uso de Alertas, podremos ofrecerle al usuario mejores mensajes de error y controlaremos mejor este tipo de situaciones. Por ejemplo, vamos a definir una Alerta de tipo Parar y la vamos a utilizar cuando se produzca un Error 40508. Para ello, en el trigger On-Error escribimos el siguiente código:
Como vemos, en el trigger On-Error, cuando el error es distinto del 40508, se muestra el código de error, el tipo y el texto del error, pero cuando el error que se produce es un 40508, mostraríamos la alerta ERROR.
Visualización incompleta de Alerta
Al utilizar la Built-in SHOW_ALERT y sin modificar las propiedades de la alerta (tan solo le hemos asignado el nombre), este sería el resultado. Se muestra la ventana modal de la alerta, pero no se muestra el título ni el mensaje, puesto que a la hora de crear la alerta no se establecieron dichas propiedades.
Uso de función para visualizar Alertas
Con el objeto de hacer más flexible el código y de potenciar su funcionalidad, si en lugar de utilizar la Built-in SHOW_ALERT utilizamos la función de la que hablamos anteriormente, donde podemos indicar el tipo, el título y el mensaje a mostrar en la alerta, el código del trigger On-Error quedaría de la siguiente forma:
Visualización personalizada de Alerta
Y el resultado obtenido mejora bastante el anterior:
Esta píldora formativa está extraída del Curso online de Desarrollo de Aplicaciones en Oracle Forms Developer.
No pierdas tu oportunidad y ¡continúa aprendiendo!
Política de privacidad
ADR Formación utiliza cookies propias y de terceros para fines analíticos anónimos, guardar las preferencias que selecciones y para el funcionamiento general de la página.
Puedes aceptar todas las cookies pulsando el botón "Aceptar" o configurarlas o rechazar su uso pulsando el botón "Configurar".
Puedes obtener más información y volver a configurar tus preferencias en cualquier momento en la Política de cookies
