La logica de procesamiento en el PAI y la ejecucion de las acciones.
Ejecución condicionada de módulos
- Uso de la cláusula "on input" en una sentencia fill para ejecutar módulos solo si el campo tiene un valor diferente al inicial.
- En sentencias "chain endchain", se utiliza "on chain input" para procesar el módulo solo si algún campo ha cambiado respecto a su valor inicial.
- La cláusula "on request" ejecuta el módulo solo si el campo ha sido modificado tras el PBO, aunque sea con el mismo valor o el valor inicial.
- "On chain request" en "chain endchain" procesa el módulo si alguno de los campos tiene una nueva entrada tras el PBO.
- Para permitir que el usuario salga de la pantalla sin validaciones, se usan los botones back, exit o cancel con la cláusula "at exit-command" en la sentencia module.
- Es necesario crear módulos de salida para cada dimpro dentro del PAI (por ejemplo, EXIT_0100, EXIT_0200, etc.)
- La instrucción "leave to screen" permite volver a una pantalla específica, como regresar de la dimpro 300 a la 200.
- "Leave to screen 0" lleva de regreso a la pantalla inicial.
Tratamiento de los códigos de función
- Al interactuar con teclas de función, menú, botones o enter, los datos se validan y se procesa un código de función (ok_code).
- El procesamiento del ok_code se realiza en el módulo USER_COMMAND, que debe ser el último en el evento PAI.
- Tras procesar el código de función, es importante inicializar (borrar) el ok_code para la próxima dimpro.
- Se recomienda usar una variable intermedia para guardar el valor de ok_code antes de inicializarlo.
- Se deben definir explícitamente las variables W_UCOM y ok_code.
Secuencia dinámica de las pantallas
- Se controla la secuencia de ejecución de dimpros usando las instrucciones set screen y call screen.
- "Set screen" reescribe temporalmente la siguiente pantalla a procesar, siempre dentro del mismo módulo pool.
- La pantalla siguiente se procesa tras la actual, salvo que se use "leave screen" para terminar la actual inmediatamente.
- "Leave to screen" permite finalizar la pantalla actual e ir directamente a otra.
- "Call screen" interrumpe la pantalla actual para procesar otra y sus subsecuentes; también debe ser del mismo módulo pool.
- Instrucciones como "set screen 0", "leave screen" o "leave to screen 0" regresan el control al punto original si se usaron tras "call screen".
- Si se usan estas instrucciones fuera del modo de llamada, el programa termina.
- Se puede controlar la posición y tamaño de la pantalla llamada con "starting at" y "ending at" en "call screen".
- Si la pantalla no cabe completamente, se agrega automáticamente una barra de desplazamiento.
Diferenciación entre CUCOM y OKCODE
- CUCOM es una variable del sistema utilizada principalmente en los menús, almacenando la última acción ejecutada por un usuario.
- OKCODE es una variable declarada en programas ABAP, del mismo tipo que CUCOM, usada principalmente en pantallas (dynpros).
- OKCODE funciona como variable temporal que toma el valor de CUCOM cuando el usuario interactúa con la pantalla.
- En los programas ABAP se debe trabajar con OKCODE, no con CUCOM.
Razones para Utilizar OKCODE sobre CUCOM
- El programa ABAP tiene control total sobre los campos que declara, como OKCODE.
- No se debe modificar el valor de variables del sistema como CUCOM dentro de los programas ABAP.
Buenas Prácticas en la Gestión de OKCODE
- Es necesario inicializar (limpiar) OKCODE al inicio del programa para evitar que contenga valores no deseados.
- Tanto OKCODE como CUCOM se asignan automáticamente con el contenido de los campos de pantalla correspondientes durante el procesamiento PBO.
- Si OKCODE no se limpia, un código de función residual podría causar la activación no deseada del próximo evento PAI, por ejemplo al presionar Enter.
Lógica de acciones en PAI
Repaso del manejo de acciones en el PAI
- El objetivo del módulo exit_0100 es manejar la lógica de los botones de navegación (back, exit y cancel) en cada dimpro del programa de diálogo.
- Esta lógica se repite de forma similar en todas las dimpros para garantizar la navegación adecuada.
- Se copia la lógica del módulo exit_0100 al módulo exit_0200 en la dimpro 200, ajustando el destino de los botones back, exit y cancel para regresar a la dimpro 100.
Implementación en otras dimpros y definición de botones
- En la dimpro 200, se agregan dos botones: Modificar (modif) y Cancelar (cancel), con lógica para avanzar a la dimpro 300 o volver a la 100, respectivamente.
- Se define el user_command para cada dimpro, copiando la estructura y ajustando las acciones según la pantalla destino.
- En la dimpro 300, se agregan botones para confirmar (confirm) o cancelar (cancel) la modificación de datos; la lógica dirige la navegación según la selección del usuario.
Confirmación de acciones y manejo de respuestas
- Al confirmar una modificación en la dimpro 300, se implementa un popup de confirmación utilizando pop up to confirm.
- El título y el texto de la pregunta se establecen dinámicamente, aunque se recomienda usar textos de selección en vez de valores hardcodeados.
- Se define una variable the_answer (char 1) para capturar la respuesta del usuario.
- Si the_answer es "1" (sí), se realizará la modificación en la base de datos (pendiente de implementación en próximas lecciones).
- Si the_answer es "2" (no), se retorna a la pantalla anterior.
Consideraciones finales
- El manejo de la lógica para los botones y comandos se debe centralizar y modularizar, evitando la codificación directa de textos y valores.
- Se recomienda realizar futuras configuraciones y modificaciones una vez implementado el table control que se tratará en próximas lecciones.
- Implementar la lógica de modificación de la base de datos una vez creado el table control.
- Modularizar y trasladar los textos de botones y preguntas a la gestión de textos de selección.