Capítulo I
95
Capítulo I : Programación en Diálogo. 1. Técnicas Especiales del Screen Painter. 1.1 Verificación automática en Module Pool Verificación de formato. 2 Verificación de campos obligatorios. 5 Verificación de llaves foráneas. 6 Verificación valores fijos. 7 1.2 Mensajes en pantalla Mensaje de Error. 14 Mensaje de Advertencia. 17 Mensaje de Información. 19 Mensaje de Buen Resultado. 21 Mensaje de Interrupción. 23 1.3 Configuración dinámica de pantallas 25 1.4 Ejecución Condicionada De Módulos ON CHAIN- [INPUT REQUEST] 31 2 Modificación Dinámica de Pantallas. 58 3 Definición y Manejo de Tabstrip controls. 67 Capítulo I : Programación en Diálogo. 4 horas Técnicas Especiales del Screen Painter. 3.1 Verificación automática en Module Pool Verificación de formato. Verificación de campos obligatorios. Verificación de llaves foráneas. Verificación valores fijos. 1
-
Upload
juan-carlos-hermitano-villegas -
Category
Documents
-
view
47 -
download
0
Transcript of Capítulo I
Capítulo I: Programación en Diálogo. 1. Técnicas Especiales del Screen Painter.
1.1 Verificación automática en Module Pool Verificación de formato. 2 Verificación de campos obligatorios. 5 Verificación de llaves foráneas. 6 Verificación valores fijos. 7
1.2 Mensajes en pantalla Mensaje de Error. 14 Mensaje de Advertencia. 17 Mensaje de Información. 19 Mensaje de Buen Resultado. 21 Mensaje de Interrupción. 23
1.3 Configuración dinámica de pantallas 251.4 Ejecución Condicionada De Módulos ON CHAIN-[INPUT REQUEST] 31
2 Modificación Dinámica de Pantallas. 583 Definición y Manejo de Tabstrip controls. 67
Capítulo I: Programación en Diálogo. 4 horas
Técnicas Especiales del Screen Painter.3.1 Verificación automática en Module Pool
Verificación de formato. Verificación de campos obligatorios. Verificación de llaves foráneas. Verificación valores fijos.
1
Verificación automática en Module Pool.
3.2 Verificación de formato.
El procesador de diálogo valida las entradas de acuerdo a los atributos de cada campo. Si el sistema detecta un valor incorrecto, despliega un mensaje de error y vuelve a mostrar los campos para su nueva entrada.
Ejemplo:Crear un dynpro similar a este:
En el Servidor, el programa ZNICAPII1A llama a este dynpro de la forma siguiente:
2
El dynpro tendría los siguientes elementos:I_FECHA: elemento de Formato Fecha “DATS”.I_MONTO: elemento de Formato Fecha “DEC”.
Finalmente, una vez activado el Dynpro se pueden hacer las pruebas con los siguientes valores, se observará que sin agregar código el sistema valida el contenido de los campos de pantalla de acuerdo a su formato.
3
3.3 Verificación de campos obligatorios.
Al momento de que algún campo de la pantalla se le asigna el atributo de que es obligatorio, el procesador de diálogo no continúa con el proceso, al menos que todos los campos obligatorios tengan algún valor.
Ejemplo:Al crear un dynpro similar al ejemplo de Verificación de formato, modificando el elemento “I_FECHA”, del siguiente modo:
En el Servidor, el programa ZNICAPII1B llama a este dynpro del ejemplo:
Finalmente, una vez activado el Dynpro se pueden verificar que el sistema pide que se ingrese un valor para el campo “I_FECHA”.
4
3.4 Verificación de llaves foráneas.
Una verificación de clave foránea es procesada solo si un campo de pantalla se refiere a un campo del Diccionario para el cual se ha definido una tabla de verificación.Al mismo tiempo, la funcionalidad de la tecla F4 es activada. Esto significa que las posibles entradas para un campo son desplegadas.
Ejemplo:Al crear en un dynpro un elemento que haga referencia a un campo de una Tabla que tiene Foreign Key a otra Tabla, como es el caso de SBOOK-CARRID con SCARR-CARRID, del siguiente modo:
En el Servidor, el programa ZNICAPII1C llama a este dynpro del ejemplo:
Finalmente, una vez activado el Dynpro se pueden verificar que el sistema sólo permite el ingreso se valores existentes en el campo de la Tabla SBOOK-CARRID.
5
3.5 Verificación valores fijos.
En el Diccionario ABAP/4, se pueden definir los valores fijos para los dominios.Si se define un campo de pantalla con referencia a un dominio con valores fijos, ocurre lo siguiente: Los valores fijos son desplegados si el usuario presiona la tecla F4 para ver los
posibles valores para el campo de entrada. El procesador de diálogo verifica los valores introducidos en el campo contra
el conjunto de valores fijos del Dominio correspondiente.
Ejemplo:Al crear en un dynpro un elemento que haga referencia a un campo de una Tabla que tiene un dominio con valores fijos, como es el caso del campo “Clase de Vuelo” del campo de tabla SBOOK-CLASS, del siguiente modo.
En el Servidor, el programa ZNICAPII1D llama a este dynpro del ejemplo:
Finalmente, una vez activado el Dynpro se pueden verificar que el sistema sólo permite el ingreso se valores existentes del dominio para el campo de la Tabla SBOOK-CLASS.
Conjunto de valores para el campo SBOOK-CLASS:C Business classY Economy classF First class
6
3.6 Mensajes en pantalla Mensaje de Error. Mensaje de Advertencia. Mensaje de Información. Mensaje de Buen Resultado. Mensaje de Interrupción.
Mensajes en pantalla
3.7 Mensaje de Error.
El texto de un mensaje de error (E) es desplegado en la pantalla actual.
Todos los campos de pantalla asignados al módulo correspondiente (instrucción FIELD) se vuelven disponibles para introducir información de nuevo.
El sistema obliga al usuario a reintroducir datos.
Ejemplo de Mensaje de Error
Al crear un dynpro con 3 elementos que haga referencia a 3 variables de un programa.
7
En el Servidor, el programa ZNICAPII1G llama a este dynpro del ejemplo:
8
REPORT ZNICAPII1F MESSAGE-ID zmsg001 .*************************************************************************CAPITULO II ** Mensajes en pantalla ** Mensaje de Error *************************************************************************DATA: ok_code TYPE sy-ucomm, input1 TYPE i, input2 TYPE i, input3 TYPE i, sum TYPE i.
CALL SCREEN 100.
*Modulos PBOMODULE init_screen_100 OUTPUT. CLEAR: input1, input2, input3. SET PF-STATUS 'STATUS_100'.ENDMODULE.
*Modulos PAIMODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE.
MODULE chain_module_1 INPUT. CLEAR sum. sum = sum + : input1, input2, input3. IF sum <= 100.*EMITIR MENSAJE MESSAGE e003 WITH text-006. ENDIF.ENDMODULE.
El flow logic del dynpro 100 sería como el siguiente:
Casos de Prueba Mensaje de Error
El Modulo chain_module_1 muestra un mensaje de error si la Suma de los campos es menor a 100, Chain permite el ingreso de valores en los 3 campos.
9
PROCESS BEFORE OUTPUT. MODULE init_screen_100.
PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND. CHAIN. FIELD input1. FIELD input2. FIELD input3 MODULE chain_module_1. ENDCHAIN.
3.8 Mensaje de Advertencia.
El texto del mensaje de advertencia (W) es desplegado en la pantalla actual.
Todos los campos de pantalla asignados al módulo correspondiente (instrucción FIELD) se vuelven disponibles para introducir información de nuevo.
El usuario puede reintroducir los datos o ignorar el mensaje de advertencia presionando la tecla ENTER.
Ejemplo de Mensaje de Advertencia
Al crear un dynpro con 3 elementos que haga referencia a 3 variables de un programa.
En el Servidor, el programa ZNICAPII1H llama a este dynpro del ejemplo:
10
REPORT ZNICAPII1H MESSAGE-ID zmsg001 .*************************************************************************CAPITULO II ** Mensajes en pantalla ** Mensaje de Advertencia *************************************************************************DATA: ok_code TYPE sy-ucomm, input1 TYPE i, input2 TYPE i, input3 TYPE i, sum TYPE i.
CALL SCREEN 100.
*Modulos PBOMODULE init_screen_100 OUTPUT. CLEAR: input1, input2, input3. SET PF-STATUS 'STATUS_100'.ENDMODULE.
*Modulos PAIMODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE.
MODULE chain_module_1 INPUT. CLEAR sum. sum = sum + : input1, input2, input3. IF sum = 100.*EMITIR MENSAJE MESSAGE W004 WITH text-007. ENDIF.ENDMODULE.
El flow logic del dynpro 100 sería como el siguiente:
Casos de Prueba Mensaje de Advertencia
El Modulo chain_module_1 muestra un mensaje de Advertencia si la Suma de los campos es igual a 100, Chain permite el ingreso de valores en los 3 campos.
11
PROCESS BEFORE OUTPUT. MODULE init_screen_100.
PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND. CHAIN. FIELD input1. FIELD input2. FIELD input3 MODULE chain_module_1. ENDCHAIN.
3.9 Mensaje de Información.
El texto de un mensaje de información (I) es desplegado en la pantalla actual.
El proceso de la pantalla actual es suspendido. Después de que el usuario presione la tecla ENTER, el programa continúa con su ejecución normal desde el punto donde fue suspendido.
Ejemplo de Mensaje de Información
Al crear un dynpro con 3 elementos que haga referencia a 3 variables de un programa.
En el Servidor, el programa ZNICAPII1I llama a este dynpro del ejemplo:
12
REPORT ZNICAPII1I MESSAGE-ID zmsg001 .*************************************************************************CAPITULO II ** Mensajes en pantalla ** Mensaje de Información *************************************************************************DATA: ok_code TYPE sy-ucomm, input1 TYPE i, input2 TYPE i, input3 TYPE i, sum TYPE i.
CALL SCREEN 100.
*Modulos PBOMODULE init_screen_100 OUTPUT. CLEAR: input1, input2, input3. SET PF-STATUS 'STATUS_100'.ENDMODULE.
*Modulos PAIMODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE.
MODULE chain_module_1 INPUT. CLEAR sum. sum = sum + : input1, input2, input3. IF ( sum >= 100 and sum <= 150 ).*EMITIR MENSAJE MESSAGE I005 WITH text-008. ENDIF.ENDMODULE.
El flow logic del dynpro 100 sería como el siguiente:
Casos de Prueba Mensaje de Información
El Modulo chain_module_1 muestra un mensaje de Información si la Suma de los campos está en el rango de 100 a 150, Chain permite el ingreso de valores en los 3 campos.
13
PROCESS BEFORE OUTPUT. MODULE init_screen_100.
PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND. CHAIN. FIELD input1. FIELD input2. FIELD input3 MODULE chain_module_1. ENDCHAIN.
3.10 Mensaje de Buen Resultado.
Un mensaje de texto de buen resultado (S) es desplegado en la pantalla siguiente a la actual.
Ejemplo de Mensaje de Buen Resultado
Al crear un dynpro con 3 elementos que haga referencia a 3 variables de un programa.
En el Servidor, el programa ZNICAPII1J llama a este dynpro del ejemplo:
14
REPORT ZNICAPII1J MESSAGE-ID zmsg001 .*************************************************************************CAPITULO II ** Mensajes en pantalla ** Mensaje de Buen Resultado *************************************************************************DATA: ok_code TYPE sy-ucomm, input1 TYPE i, input2 TYPE i, input3 TYPE i, sum TYPE i.
CALL SCREEN 100.
*Modulos PBOMODULE init_screen_100 OUTPUT. CLEAR: input1, input2, input3. SET PF-STATUS 'STATUS_100'.ENDMODULE.
*Modulos PAIMODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE.
MODULE chain_module_1 INPUT. CLEAR sum. sum = sum + : input1, input2, input3. IF ( sum >= 100 ).*EMITIR MENSAJE MESSAGE S005 WITH text-009. ELSE. MESSAGE E003 WITH text-006. ENDIF.
El flow logic del dynpro 100 sería como el siguiente:
Casos de Prueba Mensaje de Buen Resultado
El Modulo chain_module_1 muestra un mensaje de Buen Resultado si la Suma de los campos es mayor a 100.
El Modulo chain_module_1 muestra un mensaje de Error si la Suma de los campos es menor a 100, Chain permite el ingreso de valores en los 3 campos.
15
PROCESS BEFORE OUTPUT. MODULE init_screen_100.
PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND. CHAIN. FIELD input1. FIELD input2. FIELD input3 MODULE chain_module_1. ENDCHAIN.
3.11 Mensaje de Interrupción.
El texto de un mensaje de Interrupción (A) es desplegado en la pantalla actual.
Después de que el usuario presione la tecla ENTER, el proceso actual es terminado y el proceso regresa a la pantalla inicial.
Ejemplo de Mensaje de Buen Resultado
Al crear un dynpro con 3 elementos que haga referencia a 3 variables de un programa.
En el Servidor, el programa ZNICAPII1K llama a este dynpro del ejemplo:
16
REPORT ZNICAPII1K MESSAGE-ID zmsg001 .*************************************************************************CAPITULO II ** Mensajes en pantalla ** Mensaje de Interrupción *************************************************************************DATA: ok_code TYPE sy-ucomm, input1 TYPE i, input2 TYPE i, input3 TYPE i, sum TYPE i.
CALL SCREEN 100.
*Modulos PBOMODULE init_screen_100 OUTPUT. CLEAR: input1, input2, input3. SET PF-STATUS 'STATUS_100'.ENDMODULE.
*Modulos PAIMODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE.
MODULE chain_module_1 INPUT. CLEAR sum. sum = sum + : input1, input2, input3. CLEAR sum. sum = sum + : input1, input2, input3. IF ( sum >= 100 ).*EMITIR MENSAJE MESSAGE S005 WITH text-009. ELSEIF ( sum < 10 ).. MESSAGE A003 WITH text-006. ENDIF.ENDMODULE.
El flow logic del dynpro 100 sería como el siguiente:
Casos de Prueba Mensaje de Interrupción
El Modulo chain_module_1 muestra un mensaje de Interrupción si la Suma de los campos es menor a 10, el proceso actual es terminado.
Y el proceso regresa a la pantalla inicial.
17
PROCESS BEFORE OUTPUT. MODULE init_screen_100.
PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND. CHAIN. FIELD input1. FIELD input2. FIELD input3 MODULE chain_module_1. ENDCHAIN.
3.12 Configuración dinámica de pantallas
Configuración dinámica de pantallas
Desde una transacción podemos ir controlando el flujo de pantallas de la misma, llamar a otras transacciones o reportes.
3.13 Configuración Dinámica de la siguiente pantalla.
Ejemplo de Sentencia SET SCREEN
Crear dos dynpro cualquiera 100 y 200 asociados a un programa.
En el Servidor, el programa ZNICAPII1L llama a estos dynpros del ejemplo:
En el Screen Painter (Transacción SE51), creamos los dynpros 100 y 200 para el programa ZNICAPII1L.
18
SET SCREENSET SCREEN
CALL SCREENCALL SCREEN
1
2
19
Por defecto, cuando acaben los módulos del evento PAI, el sistema saltará a la pantalla que indique el atributo Next Screen de la pantalla en ejecución. Es posible modificar el atributo de la próxima pantalla con la instrucción SET .
SET SCREEN <no._pantalla>.
Partiendo de un Dynpro 100, Su flow logic correspondiente sería como el siguiente:
Donde los módulos PBO_100 y PAI_100 (dentro del programa ZNICAPII1L) serían de la siguiente forma:
La instrucción SET SCREEN XXX rescribe temporalmente la siguiente pantalla a procesar. La pantalla xxx debe ser una pantalla del mismo "module pool".
20
PROCESS BEFORE OUTPUT. MODULE PBO_100.
PROCESS AFTER INPUT. MODULE PAI_100.
*Modulos PBO*&---------------------------------------------------------------------**& Module PBO_100 OUTPUT*&---------------------------------------------------------------------*MODULE PBO_100 OUTPUT. SET PF-STATUS 'STATUS_100'.ENDMODULE.*Modulos PAI*&---------------------------------------------------------------------**& Module PAI_100 INPUT*&---------------------------------------------------------------------*MODULE PAI_100 INPUT. SET SCREEN 200. LEAVE SCREEN.ENDMODULE.
La pantalla siguiente es procesada después de procesar la pantalla actual, o al menos que se termine la ejecución de la pantalla actual con la instrucción LEAVE SCREEN. Al encontrar esta instrucción, se ejecuta la pantalla siguiente en forma inmediata.
Si se desea terminar el procesamiento de la pantalla actual e ir directamente a la pantalla siguiente en una sola instrucción, se puede usar el estatuto LEAVE TO SCREEN xxx.
21
3.14 Inserción de una o más pantallas
La instrucción CALL SCREEN xxx interrumpe el procesamiento de la pantalla actual para procesar la pantalla xxx y las pantallas subsecuentes.
La pantalla llamada con esta instrucción deberá ser una pantalla del mismo "module pool".
Ejemplo de Sentencia CALL SCREEN
Crear dos dynpro cualquiera 100 y 200 asociados a un programa. En el Servidor, el programa ZNICAPII1L llama a estos dynpros del ejemplo:
En el Screen Painter (Transacción SE51), creamos los dynpros 100 y 200 para el programa ZNICAPII1M (Nótese que son iguales al del programa ZNICAPII1L).
La lógica del programa ZNICAPII1M sería como el siguiente:
22
1
2
REPORT ZNICAPII1M MESSAGE-ID zmsg001.
CALL SCREEN 100.*&---------------------------------------------------------------------**& Module PBO_XXX OUTPUT*&---------------------------------------------------------------------*MODULE PBO_XXX OUTPUT. SET PF-STATUS 'STATUS_XXX'.ENDMODULE.*&---------------------------------------------------------------------**& Module PAI_100 INPUT*&---------------------------------------------------------------------*MODULE PAI_100 INPUT. CALL SCREEN 200.ENDMODULE.*&---------------------------------------------------------------------**& Module PAI_200 INPUT*&---------------------------------------------------------------------*MODULE PAI_200 INPUT. SET SCREEN 0. LEAVE SCREEN.ENDMODULE.*&---------------------------------------------------------------------**& Module CANCELAR INPUT*&---------------------------------------------------------------------*MODULE CANCELAR INPUT. LEAVE PROGRAM.ENDMODULE.
Partiendo de un Dynpro 100, Su flow logic correspondiente sería como el siguiente:
El flow logic del Dynpro 200 correspondiente sería como el siguiente:
El Status XXX sería como el siguiente (sólo el icono cancel iría):
Finalmente, una vez grabado y activado el programa y los dynpros, podemos ver el fuljo de los dynpros:
23
PROCESS BEFORE OUTPUT. MODULE PBO_XXX.
PROCESS AFTER INPUT. MODULE CANCELAR AT EXIT-COMMAND. MODULE PAI_100.
PROCESS BEFORE OUTPUT. MODULE PBO_XXX.
PROCESS AFTER INPUT. MODULE CANCELAR AT EXIT-COMMAND. MODULE PAI_200.
1
2
Ejecución Condicionada De Módulos ON CHAIN-[INPUT REQUEST]
Ejecución Condicionada de Módulos.
Si se especifica la adición ON INPUT después de MODULE en una instrucción FIELD, el módulo es ejecutado solamente si el campo relevante contiene un valor diferente al valor inicial.
En un estatuto CHAIN se debe usar la instrucción ON CHAIN-INPUT. Entonces, el módulo concerniente es procesado solamente si al menos uno de los campos de pantalla del estatuto CHAIN contiene un valor diferente al valor inicial.
Si se especifica la adición ON REQUEST después de MODULE en una instrucción FIELD, el módulo es ejecutado únicamente si el campo relevante tiene una nueva entrada.
En un estatuto CHAIN, se debe usar la instrucción ON CHAIN-REQUEST. Entonces, el módulo concerniente es procesado solamente si al menos uno de los campos de pantalla del estatuto CHAIN tiene una nueva entrada.
24
PROCESS AFTER INPUT.FIELD <campo de pantalla>.
MODULE <módulo> ON INPUT...
PROCESS AFTER INPUT.CHAIN.
FIELD <campo de pantalla>, <campo de pantalla>,
.
. <Campo de pantalla>.
MODULE <módulo> ON CHAIN-INPUT.ENDCHAIN...
PROCESS AFTER INPUT.FIELD <campo de pantalla>.
MODULE <módulo> ON REQUEST...
PROCESS AFTER INPUT.CHAIN.
FIELD <campo de pantalla>, <campo de pantalla>,
.
. <Campo de pantalla>.
MODULE <módulo> ON CHAIN-REQUEST.
ENDCHAIN.
Ejemplo de Sentencia ON INPUT, ON CHAIN-INPUT y ON CHAIN-REQUEST
Creamos un programa con 6 campos, del modo siguiente:En el Servidor, el programa ZNICAPII1N llama a este dynpro del ejemplo:
La lógica del programa ZNICAPII1N sería como el siguiente:
25
REPORT ZNICAPII1N MESSAGE-ID zmsg001 .*************************************************************************CAPITULO II **EJECUCIÓN CONDICIONADA DE MÓDULOS ** Sentencia-ON INPUT, ON CHAIN-INPUT y ON CHAIN-REQUEST *************************************************************************
DATA: ok_code TYPE sy-ucomm, input1 TYPE i, input2 TYPE i, input3 TYPE i, input4 TYPE i, input5 TYPE i, input6 TYPE i.
CALL SCREEN 100.
*Modulos PBOMODULE init_screen_100 OUTPUT.* CLEAR: input1, input2, input3, input4, input5, input6. SET PF-STATUS 'STATUS_100'.ENDMODULE.
*Modulos PAIMODULE MOD_A INPUT. MESSAGE i888(sabapdocu) WITH text-001.ENDMODULE.
MODULE MOD_B INPUT. MESSAGE i888(sabapdocu) WITH text-002.ENDMODULE.
MODULE MOD_C INPUT. MESSAGE i888(sabapdocu) WITH text-003.ENDMODULE.
MODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE.
Partiendo de un Dynpro 100, Su flow logic correspondiente sería como el siguiente:
El Status STATUS_100 sería como el siguiente (sólo el icono cancel iría):
Los “Text-Elements” text-001, text-002 y text-003 que mostrarían los módulos PAI serían como los siguientes:
26
PROCESS BEFORE OUTPUT. MODULE init_screen_100.
PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND.
FIELD input1 MODULE MOD_A ON INPUT.
CHAIN. FIELD input2. FIELD input3 MODULE MOD_B ON CHAIN-INPUT. ENDCHAIN.
CHAIN. FIELD input4. FIELD input5. FIELD input6 MODULE MOD_C ON CHAIN-REQUEST. ENDCHAIN.
Finalmente, una vez grabado y activado el programa y sus elementos podemos ver como trabajan las sentencias ON INPUT, ON CHAIN-INPUT y ON CHAIN-REQUEST.
INPUT: FIELD ON INPUTPor cada campo que se modifica se genera un mensaje.
REQUEST: CHAIN ON FIELD REQUEST Si se modifica al menos un campo, sale el mensaje, Notar que si no modificamos los valores ingresados y le damos ENTER a la pantalla el mensaje “…ON CHAIN-REQUEST” no vuelve a aparecer porque no ha variado los valores en los campos.
27
Configuración dinámica de pantallas
Desde una transacción podemos ir controlando el flujo de pantallas de la misma, llamar a otras transacciones o reportes.
3.15 Configuración Dinámica de la siguiente pantalla.
Ejemplo de Sentencia SET SCREEN
Crear dos dynpro cualquiera 100 y 200 asociados a un programa.
En el Servidor, el programa ZNICAPII1L llama a estos dynpros del ejemplo:
En el Screen Painter (Transacción SE51), creamos los dynpros 100 y 200 para el programa ZNICAPII1L.
28
SET SCREENSET SCREEN
CALL SCREENCALL SCREEN
1
2
Por defecto, cuando acaben los módulos del evento PAI, el sistema saltará a la pantalla que indique el atributo Next Screen de la pantalla en ejecución. Es posible modificar el atributo de la próxima pantalla con la instrucción SET .
SET SCREEN <no._pantalla>.
Partiendo de un Dynpro 100, Su flow logic correspondiente sería como el siguiente:
Donde los módulos PBO_100 y PAI_100 (dentro del programa ZNICAPII1L) serían de la siguiente forma:
La instrucción SET SCREEN XXX rescribe temporalmente la siguiente pantalla a procesar. La pantalla xxx debe ser una pantalla del mismo "module pool".
29
PROCESS BEFORE OUTPUT. MODULE PBO_100.
PROCESS AFTER INPUT. MODULE PAI_100.
*Modulos PBO*&---------------------------------------------------------------------**& Module PBO_100 OUTPUT*&---------------------------------------------------------------------*MODULE PBO_100 OUTPUT. SET PF-STATUS 'STATUS_100'.ENDMODULE.*Modulos PAI*&---------------------------------------------------------------------**& Module PAI_100 INPUT*&---------------------------------------------------------------------*MODULE PAI_100 INPUT. SET SCREEN 200. LEAVE SCREEN.ENDMODULE.
La pantalla siguiente es procesada después de procesar la pantalla actual, o al menos que se termine la ejecución de la pantalla actual con la instrucción LEAVE SCREEN. Al encontrar esta instrucción, se ejecuta la pantalla siguiente en forma inmediata.
Si se desea terminar el procesamiento de la pantalla actual e ir directamente a la pantalla siguiente en una sola instrucción, se puede usar el estatuto LEAVE TO SCREEN xxx.
30
3.16 Inserción de una o más pantallas
La instrucción CALL SCREEN xxx interrumpe el procesamiento de la pantalla actual para procesar la pantalla xxx y las pantallas subsecuentes.
La pantalla llamada con esta instrucción deberá ser una pantalla del mismo "module pool".
Ejemplo de Sentencia CALL SCREEN
Crear dos dynpro cualquiera 100 y 200 asociados a un programa. En el Servidor, el programa ZNICAPII1L llama a estos dynpros del ejemplo:
En el Screen Painter (Transacción SE51), creamos los dynpros 100 y 200 para el programa ZNICAPII1M (Nótese que son iguales al del programa ZNICAPII1L).
La lógica del programa ZNICAPII1M sería como el siguiente:
31
1
2
REPORT ZNICAPII1M MESSAGE-ID zmsg001.
CALL SCREEN 100.*&---------------------------------------------------------------------**& Module PBO_XXX OUTPUT*&---------------------------------------------------------------------*MODULE PBO_XXX OUTPUT. SET PF-STATUS 'STATUS_XXX'.ENDMODULE.*&---------------------------------------------------------------------**& Module PAI_100 INPUT*&---------------------------------------------------------------------*MODULE PAI_100 INPUT. CALL SCREEN 200.ENDMODULE.*&---------------------------------------------------------------------**& Module PAI_200 INPUT*&---------------------------------------------------------------------*MODULE PAI_200 INPUT. SET SCREEN 0. LEAVE SCREEN.ENDMODULE.*&---------------------------------------------------------------------**& Module CANCELAR INPUT*&---------------------------------------------------------------------*MODULE CANCELAR INPUT. LEAVE PROGRAM.ENDMODULE.
Partiendo de un Dynpro 100, Su flow logic correspondiente sería como el siguiente:
El flow logic del Dynpro 200 correspondiente sería como el siguiente:
El Status XXX sería como el siguiente (sólo el icono cancel iría):
Finalmente, una vez grabado y activado el programa y los dynpros, podemos ver el fuljo de los dynpros:
32
PROCESS BEFORE OUTPUT. MODULE PBO_XXX.
PROCESS AFTER INPUT. MODULE CANCELAR AT EXIT-COMMAND. MODULE PAI_100.
PROCESS BEFORE OUTPUT. MODULE PBO_XXX.
PROCESS AFTER INPUT. MODULE CANCELAR AT EXIT-COMMAND. MODULE PAI_200.
1
2
4. Modificación dinámica de pantallas
Modificación dinámica de campos de pantallas.
Se pueden cambiar temporalmente ciertos atributos de campos, por ejemplo cambiar los campos de solo-lectura en campos de entrada/salida.
También se puede usar la modificación dinámica de pantallas para facilitar el ocultar ciertos campos y así evitar secuencias dinámicas de pantallas.
Atributos de campos Modificables
Los campos de pantalla y sus atributos modificables son automáticamente almacenados en la tabla interna SCREEN.
La tabla SCREEN es inicializada con los campos definidos en el Screen Painter y con sus atributos cada vez que el módulo PBO es ejecutado.
Para determinar los campos para los cuales se puede cambiar uno ó más atributos, se lee el campo SCREEN-NAME y del campo SCREEN-GROUP1 al campo SCREEN-GROUP4 en la tabla SCREEN.
El campo SCREEN-REQUEST está reservado para uso interno del sistema.
Puede modificar la estructura de un Dynpro en su programa ABAP durante el evento PBO del Dynpro. Las únicas sentencias permitidas que se puede utilizar para modificar la pantalla son:
LOOP AT SCREEN es una sentencia propia, que no debe confundirse con un LOOP más sobre una tabla interna.
En reportes se utiliza la sentencia LOOP AT SCREEN en el evento AT SELECTION-SCREEN OUTPUT.
33
A
B
Change <-> Display
A
B
Change <-> Display
campos de salida campos de entraday salida
LOOP AT SCREEN.... MODIFY SCREEN....ENDLOOP.
Tabla SCREEN / Atributos modificables de campos
Atributos: Modificación de grupos
Se puede asignar un campo a cuatro grupos diferentes. Los nombres de grupos son de tres caracteres de longitud y pueden ser definidos libremente.
En el Screen Painter en atributos del campo y en la Parte “Groups”, podemos asignar un campo a cuatro grupos diferentes. En la gráfica se asigna el campo DEMO_CONN-CITYFROM al grupo “MOD”.
34
Ejemplo de Modificación dinámica de campos de pantallas.
Creamos un programa de diálogo con un dynpro 100.
En el Servidor, el programa ZNICAPII4A llama a este dynpro del ejemplo:
El dynpro 100 tiene siete campos de entrada, que hacen referencia a los campos de diccionario de la estructura DEMO_CONN.
Los campos DEMO_CONN–CARRID y DEMO_CONN–CONNID no están asignados a ningún grupo de modificación, el resto de campos de la estructura DEMO_CONN están asignados al grupo de modificación “MOD”
El botón “Alternar” en la pantalla y el botón el menú bar “Alternar/Modificar” tienen el mismo “Function code = ALT”.
35
El dynpro 100 tiene siete campos de entrada, que hacen referencia a los campos de diccionario de la estructura DEMO_CONN.
Los campos de entrada DEMO_CONN–CARRID y DEMO_CONN–CONNID no están asignados a ningún grupo de modificación,
El resto de campos de entrada de la estructura DEMO_CONN están asignados al grupo de modificación “MOD”
36
El botón “Alternar” en la pantalla y el botón el menú bar “Alternar/Modificar” tienen el mismo “Function code = ALT”.
Para el dynpro 100, se crea el STATUS 'SCREEN_100'.
En el “Application toolbar” se crea el “Function code = ALT”.
En el Screen Painter para el botón “Alternar” en el dynpro 100 se le asocia el “Function
code = ALT”.
37
Para el dynpro 100, en el STATUS 'SCREEN_100'.
En el “Standard toolbar” se crea el “Function code = OUT”, del tipo “E”. Para el módulo PAI “ MODULE cancel AT EXIT-COMMAND ”, el cual permite escapar de la pantalla ante cualquier validación .
El flow logic del Dynpro 100 correspondiente sería como el siguiente:
38
PROCESS BEFORE OUTPUT. MODULE status_0100.
PROCESS AFTER INPUT.* Function code = OUT, escapa de las validaciones MODULE cancel AT EXIT-COMMAND. MODULE user_command_0100.
La lógica del programa ZNICAPII4A (el cual contienen los Módulos necesarios) sería como el siguiente:
39
REPORT ZNICAPII4A.*************************************************************************CAPITULO II ** Modificación dinámica de campos de pantallas ** Ejemplo de LOOP AT SCREEN-- MODIFY SCREEN ** Responsable: Carlos Ancasi (7C) *************************************************************************
DATA: OK_CODE TYPE SY-UCOMM, FCODE TYPE SY-UCOMM.
DATA flag(1) TYPE C.
CALL SCREEN 100.*&---------------------------------------------------------------------**& Module STATUS_0100 OUTPUT*&---------------------------------------------------------------------*MODULE STATUS_0100 OUTPUT. SET PF-STATUS 'SCREEN_100'. SET TITLEBAR 'TIT_100'.* Modif. dinámica de campos de pantallas, PERMITIR O NO INGRESAR VALORES LOOP AT SCREEN. IF screen-group1 = 'MOD'. IF flag = ' '. screen-input = '0'. ELSEIF flag = 'X'. screen-input = '1'. ENDIF. MODIFY SCREEN. ENDIF. ENDLOOP.
ENDMODULE. " STATUS_0100 OUTPUT*&---------------------------------------------------------------------**& Module USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------*MODULE USER_COMMAND_0100 INPUT. fcode = ok_code. clear ok_code. CASE fcode. WHEN 'ALT'. IF flag = ' '. flag = 'X'. ELSEIF flag = 'X'. flag = ' '. ENDIF. WHEN 'SALIR'. LEAVE TO SCREEN 0. ENDCASE.ENDMODULE. " USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------**& Module cancel INPUT*&---------------------------------------------------------------------*MODULE cancel INPUT. LEAVE PROGRAM.ENDMODULE. " cancel INPUT
Finalmente, una vez grabado y activado el programa y sus elementos podemos ver como trabajan las sentencias LOOP AT SCREEN y MODIFY SCREEN.
Abrimos una sesión y ejecutamos el programa ZNICAPII4A y notaremos que los últimos 5 campos están bloqueados para ingresar valores.
Si damos click en el botón “Alternar” de la pantalla o en el botó“Alternar/Modificar”del menú bar notaremos que los últimos 5 campos ya no están bloqueados para ingresar valores.
40
Definición y Manejo de Tabstrip controls.
Tabstrips Controls
Definición de Tabstrip controls
Un control tabstrip pantalla es un objeto compuesto por dos o más fichas o pestañas. Cada ficha consta de un título y una zona para elementos de pantalla. Si la zona ocupada por el control tabstrip es demasiado estrecha para mostrar todos los títulos de la pestaña, aparece una barra de desplazamiento, lo que le permite llegar a los títulos que no se muestran. También hay un botón que le permite mostrar una lista de todos los títulos de ficha.
Pasos para creación un control tabstrip.
Cuando se crea un control tabstrip, usted debe:
1. Definir el área del tabstrip en la pantalla y los títulos de las pestañas. 2. Asignar un Subscreen para cada una de los títulos de las pestañas. 3. Programar el flow logic de la pantalla. 4. Programar la lógica de procesamiento ABAP.
Programación del flow logic
En el flow logic, todo lo que tiene que hacer a mano es incluir los correctos subscreens. El flujo de pantallas y el transporte de datos para el programa ABAP es el mismo que para subscreens normales.
El flow logic del Dynpro que contiene al tabstrip sería como el siguiente:
41
PROCESS BFORE OUTPUT. ... CALL SUBSCREEN: area1 INCLUDING [prog1] dynp1, area2 INCLUDING [prog2] dynp2, area3 INCLUDING [prog3] dynp3, ... ...
PROCESS AFTER INPUT. ... CALL SUBSCREEN: area1, area2, area3, ... ...
42
Ejemplo de Tabstrip Controls.
Creamos un programa con un dynpro 100, el cual contiene el tabstrip “w_tabstrip”.El tabstrip tiene tres pestañas, a las cuales se les asignará los subscreen 110, 120 y 130.(En el Servidor, el programa ZNICAPII5A llama a este dynpro del ejemplo).
Creamos el programa ZNICAPII5A en la Transacción SE80.
Crear el tabstrip en el screen painter.
Llamamos un dynpro 100 y lo creamos.
En el screen painter seleccionamos el icono “tabstrip control” y dibujamos el área que ocupará, por default nos aparecerán dos pestañas.
Nos pedirá el nombre del tabstrip (“w_tabstrip” para el ejemplo), y en la parte de Atributos en “Tab title” (número de pestañas) le ponemos 3.
43
Procedemos a definir las pestañas.
Definición pestaña 1.
Le damos doble clic en la primera pestaña y le colocamos los sgtes valores.
Debemos Asignar el Fct Code = PUSH1 con el Fct Type = P, los cuales permiten el traslado entre pestañas y el visualizar los subscreens de las pestañas.
En Atributos en el campo Ref. field irá el subscreen área (SUB1) que colocaremos dentro del área de la pestaña.
En el screen painter seleccionamos el icono subscreen área, el cual dibujamos dentro del área de la pestaña y le llamamos SUB1.
Si vemos de nuevo los atributos de la pestaña notaremos que el campo ha sido llenado con SUB1, y ya tenemos definida la pestaña.
En un paso posterior dibujaremos los campos del subscreen (110 para el ejemplo) que irá dentro del subscreen área SUB1.
44
Procedemos de igual forma para la segunda y tercera pestaña.Definición pestaña 2.En Atributos en el campo Ref. field irá el subscreen área (SUB2) que colocaremos dentro del área de la segunda pestaña.
En un paso posterior dibujaremos los campos del subscreen (120 para el ejemplo) que irá dentro del subscreen área SUB2.
Definición pestaña 3.En Atributos en el campo Ref. field irá el subscreen área (SUB3) que colocaremos dentro del área de la tercera pestaña.
En un paso posterior dibujaremos los campos del subscreen (130 para el ejemplo) que irá dentro del subscreen área SUB3.
45
Procedemos a definir los subscreens.
Definición subscreen 110.
En la transacción SE80 para el programa ZNICAPII5A.
Llenamos los campos respectivos y le damos clic en “crear” o F5.
En el “Layout” dibujaremos los campos del subscreen 110.
46
El subscreen 110 sería del siguiente modo.
Tiene un campo de entrada “input1” del tipo Numérico.
Definición subscreen 120.
Procedemos de igual modo que el subscreen 110, entonces el subscreen 120 sería del siguiente modo.
Tiene un campo de entrada “input2” del tipo Numérico.
47
Definición subscreen 130.
Procedemos de igual modo que el subscreen 110, entonces el subscreen 130 sería del siguiente modo.
Tiene un campo de entrada “input3” del tipo Numérico similar a “input2”.
Además tiene un botón “promediar” con el FctCode = PROM, el cual calcula el promedio de “input1” y “input2” y lo muestra en “input3”
La pantalla principal 100, la cual contiene al tabstrip tiene un botón “continue” el cual muestra un mensaje con la pestaña activa.
48
Procedemos a definir GUI STATUS
Definición GUI STATUS “SCREEN_100” .
En la transacción SE80 para el programa ZNICAPII5A.
Colocamos el nombre del GUI SATUS y le damos clic en “crear” o F5.
En el “Standard Toolbar” el Function code = CANCEL es del tipo “E” el cual se utiliza en los Eventos AT EXIT-COMMAND para escapar de todas la validaciones en pantalla.
49
La lógica del programa ZNICAPII5A (el cual contienen los Módulos necesarios) sería como el siguiente:
50
REPORT ZNICAPII5A .
CONTROLS w_tabstrip TYPE TABSTRIP.
DATA: ok_code TYPE sy-ucomm, save_ok TYPE sy-ucomm.
DATA: INPUT1(10) TYPE N,"CAMPO INPUT DE SUBSCREEN 110 INPUT2(10) TYPE N,"CAMPO INPUT DE SUBSCREEN 120 INPUT3(10) TYPE N."CAMPO INPUT DE SUBSCREEN 130
w_tabstrip-activetab = 'PUSH3'.
CALL SCREEN 100.*&---------------------------------------------------------------------**& Module STATUS_0100 OUTPUT*&---------------------------------------------------------------------*MODULE STATUS_0100 OUTPUT. SET PF-STATUS 'SCREEN_100'. SET TITLEBAR 'T100'.
ENDMODULE. " STATUS_0100 OUTPUT*&---------------------------------------------------------------------**& Module CANCEL INPUT*&---------------------------------------------------------------------*MODULE CANCEL INPUT. LEAVE PROGRAM.ENDMODULE. " CANCEL INPUT*&---------------------------------------------------------------------**& Module USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------*MODULE USER_COMMAND_0100 INPUT. save_ok = ok_code. CLEAR ok_code.
IF save_ok = 'OK'. MESSAGE i888(sabapdocu) WITH 'Pestaña Activa W_TABSTRIP-ACTIVETAB =' w_tabstrip-activetab. ENDIF.ENDMODULE. " USER_COMMAND_0100 INPUT*&---------------------------------------------------------------------**& Module UC_0130 INPUT*&---------------------------------------------------------------------*MODULE UC_0130 INPUT. save_ok = ok_code.* CLEAR ok_code. CASE SAVE_OK. WHEN 'PROM'. INPUT3 = ( INPUT1 + INPUT2 ) / 2. ENDCASE.
ENDMODULE. " UC_0130 INPUT
El flow logic del Dynpro 100 (el cual contiene el tabstrip) correspondiente sería como el siguiente:
El flow logic del subscreen 110 correspondiente sería como el siguiente:
El flow logic del subscreen 120 correspondiente sería como el siguiente:
El flow logic del subscreen 130 correspondiente sería como el siguiente:
51
PROCESS BEFORE OUTPUT. MODULE STATUS_0100.*DEFINE EL SUBSCREEN EN QUE SUBSCREEN AREA APARECERÁ CALL SUBSCREEN: SUB1 INCLUDING SY-REPID '0110', SUB2 INCLUDING SY-REPID '0120', SUB3 INCLUDING SY-REPID '0130'.
PROCESS AFTER INPUT. MODULE CANCEL AT EXIT-COMMAND.*LLAMA A LOS MODULOS PAI DE LOS SUBSCREENS CALL SUBSCREEN: SUB1, SUB2, SUB3. MODULE USER_COMMAND_0100.
PROCESS BEFORE OUTPUT.* MODULE STATUS_0110.*PROCESS AFTER INPUT.* MODULE USER_COMMAND_0110.
PROCESS BEFORE OUTPUT.* MODULE STATUS_0120.*PROCESS AFTER INPUT.* MODULE USER_COMMAND_0120.
PROCESS BEFORE OUTPUT.* MODULE STATUS_0130.*PROCESS AFTER INPUT.*MODULO QUE CALCULA EL PROMEDIO DE INPUT1 Y INPUT2 MODULE UC_0130.
Finalmente, una vez grabado y activado el programa y sus elementos podemos ver como se trabajan con los tabstrip.
Abrimos una sesión y ejecutamos el programa ZNICAPII5A y colocamos valores en las Pestañas A y B.
Luego vamos a la pestaña C y si damos click en el botón “Promediar” notaremos que en el campo aparece el promedio de los valores ingresados en las pestañas A y B.
52
53
