Unidad 2: Programación de diálogo.
Lección 6: Lógica de procesamiento en PAI. Ejecución de las acciones.
1.- Ejecución condicionada de módulos.
ABAP tiene varias maneras de condicionar la ejecución de un módulo. La llamada al módulo debe estar asociada siempre a una sentencia FIELD o CHECK-ENDCHECK.
- Si especificamos la cláusula ON INPUT después de MODULE en una instrucción FIELD el módulo se ejecutará solo en el caso de que el campo tenga un valor distinto al inicial.
- Si especificamos la cláusula ON CHAIN-INPUT después de MODULE en en el ámbito de una instrucción CHAIN-ENDCHAIN. El módulo se ejecutará solo si por lo menos alguno los campos de la pantalla afectados contienen un valor diferente al inicial. Este filtro solo se producirá si MODULE está especificada dentro de una instrucción FIELD.
- Si especificamos la cláusula ON REQUEST después de MODULE en una instrucción FIELD, el módulo so se ejecuta si el campo tiene un nueva entrada.
- Si especificamos la cláusula ON CHAIN-REQUEST después de MODULE dentro del ámbito de CHAIN-ENDCHAIN. Siempre y cuando MODULE esté asociada a una instrucción FIELD. El módulo se procesará solo si al menos uno de los campos de la dynpro tiene una nueva entrada.
- Ocasionalmente el usuario quiere salir de la dynpro sin necesidad de pasar las validaciones automáticas mediante las funciones estándar. En este caso podemos utilizar la sentencia MODULE con la cláusula AT EXIT-COMMAND.
En el módulo deberemos tener la sentencia LEAVE PROGRAM.
Si se quiere utilizar la cláusula, en un botón de campo, deberá asignarse el valor E en el atributo de campo tipo de función del editor de pantallas. En el módulo llamado incluiremos las instrucciones necesarias para salir de la transacción o de la pantalla. LEAVE PROGRAM o LEAVE TO SCREEN <n>.
2.- Tratamiento de los códigos de función.
Cuando en una transacción Module Pool se realiza una acción (tecla de función, punto de menu, botón, ícono o por ejemplo ENTER. Pasamos los datos introducidos en la pantalla se pasan a los módulos especificados en PAI y se procesan junto al OK_CODE que nos indica la función escogida por el usuario.
Para el tratamiento del OK_CODE de cada dynpro utilizaremos el módulo USER_COMMAND. Este módulo deberá ser el último llamado en el evento PAI. Se jecuta una vez se han validado correctamente todos campos de la dynpro.
En el módulo USER-COMMAND una vez procesado las sentencias del módulo podemos limpiar el valor de OK_CODE para la próxima dynpro. De hecho si movemos el valor de OK_CODE a una variable al inicio del módulo ya podemos limpiarlo inmediatamente después. La variable debe ser del tipo SY-UCOMM.
La diferencia entre SY-UCOMM y OK_CODE en una programa de diálogo. SY-UCOMM una variable del sistema que se utiliza principalmente en los menús y que contiene la última acción realizada por el usuario. OK_CODE por el contrario es una variable que se declara en los programas ABAP del tipo SY-UCOMM que se utiliza principalmente en la dynpros como una variable temporal que contendrá el valor de SY-UCOMM. En los module pool hay que trabajar con el OK_CODE porqué es una variable totalmente dependiente del programa y no se debe nunca modificar el contenido de una variable del sistema. El que en PAI se limpia el OK_CODE se debe a que en PBO este campo y el SY-UCOMM se cargan y no queremos tener valores que no correspondan.
3.- Secuencia dinámica de pantallas.
En un module pool es posible controlar la secuencia de ejecución de las pantallas que componen la transacción. Par ello ABAP tiene tres sentencias:
SET SCREEN < Nº pantalla>.
Esta instrucción de manera temporal nos indica la siguiente pantalla a procesar. Esta pantalla debe ser una dynpro del module pool. Pasaremos a la pantalla siguiente al finalizar el procesamiento de la pantalla actual o alcanzar una sentencia LEAVE SCREEN.
LEAVE TO SCREEN <nº pantalla>.
Esta sentencia combina en una sola sentencia las dos del punto anterior.
CALL SCREEN <nº pantalla>
Esta instrucción interrumpe el procesamiento de la pantalla actual para procesar la pantalla indicada en la sentencia y las siguientes. La pantalla llamada ha de formar parte del mismo Module Pool. Con SET SCREEN 0, LEAVE SCREEN o LEAVE TO SCREEN 0 el control volverá a donde se ejecuto la sentencia CALL SCREEN.
Cualquiera de estas instrucciones si se ejecuta sin haber una llamada CALL SCREEN anterior provocará la terminación del programa.
Mediante las cláusulas STARTING AT y ENDING AT en la instrucción CALL SCREEN se puede especificar la posición y el tamaño de la ventana a llamar. Si por el tamaño no puede verse completo su contenido se generan barras de scrolling.