No si se les parezca algo muy sencillo o inútil, pero recientemente me tope con este problema, lo curioso es que pensé que era muy sencillo y me pareció extraño que en todos lo años que llevo en esto no se me hubiese presentado.
El problema era el siguiente:
Se tenia un report el cual ejecutaba una operación de facturar unas entregas de SD, el problema era sencillo, el report debía responder a un evento "Enter" en la transacción, algo aparentemente simple al parecer, cuando fui a modificar el reporte la estructura del programa era muy simple realizaba lo siguiente:
- Declaraba un selection-screen.
- Dentro del selection-screen declaraba 2 parámetros.
- Luego en el Start-of-selection, se llamaba una función, que tenia la opción de ejecutarse en Job, realizando un SUBMIT a ella misma y pasandole los 2 parámetros que se declararon.
Se que esto se puede hacer de mil formas para solucionar el problema puntual, podría crear el screen como un subscreen y en dynpro llamarlo sobre un subarea y agregar un status gui al dynpro que ejecutara el "Enter" y listo, pero tendría el problema con el submit y los parámetros que se le pasaba a este, al igual que la ejecución que haría en el submit, entonces me metería en otro problema solucionando algo tan simple como un "Enter", la verdad que parece algo muy sencillo pense, dije realizando un SET PF-STATUS en el START-OF-SELECTION o en el INITIALIZATION me debería cambiar el status pero no fue asi.
Debo reconocer que estoy acostumbrado a realizar programas con Dynpros y no declarando selection-screen, no se por que pero no me gusta, pero en esta ocaciòn el problema era muy puntual y no era viable re diseñar el programa, después de mucho consultar di con la solución.
Debo reconocer que estoy acostumbrado a realizar programas con Dynpros y no declarando selection-screen, no se por que pero no me gusta, pero en esta ocaciòn el problema era muy puntual y no era viable re diseñar el programa, después de mucho consultar di con la solución.
- Primero con el Set pf-status no sirve por que cambiaria el status de la pantalla siguiente y no la actual( o primera), por ejemplo si luego de eso hiciéramos un write "Cualquier cosa" si nos cambiaría el status gui, en mi caso no procedía de esta forma por lo que no servia.
- Para realizar el cambio se debe hacer que en el AT Selection-Screen output, invoquemos una función llamada RS_SET_SELSCREEN_STATUS pasandole el nombre del status que creamos, el programa y que nos devuelva una tabla(que realmente nunca devuelve nada) con las funciones del status así:
- Controlar los eventos de los botones o comandos de usuario en el At selection-screen.
AT SELECTION-SCREEN.
CASE sy-ucomm.
WHEN 'OPC1'.
MESSAGE 'Opcion 1' TYPE 'I'.
WHEN 'OPC2'.
MESSAGE 'Opcion 2' TYPE 'I'.
WHEN 'OPC3'.
MESSAGE 'Opcion 3' TYPE 'I'.
WHEN 'OK'.
MESSAGE 'Ejecuto OK' TYPE 'I'.
WHEN 'CANCEL' OR 'EXIT' OR 'BACK'.
LEAVE TO SCREEN 0.
ENDCASE.
AT SELECTION-SCREEN OUTPUT.
CALL FUNCTION 'RS_SET_SELSCREEN_STATUS'
EXPORTING
p_status = 'GS_MI_STATUS_GUI'
p_program = sy-repid
TABLES
p_exclude = lt_exclude.
De esta forma cambiara el status-gui en tiempo de ejecución y podrán controlar la ejecución de este, espero que esto les sirva algún día(o tal vez no), de cualquier forma acá lo tienen.
Excelente Articulo, Gracias.
ResponderEliminar