Subscreens (SAP Library - BC - ABAP Programming)

Subscreens

Subscreens allow you to embed one screen within another at runtime. The term subscreen applies both to the screen that you embed, and the area on the main screen in which you place it. This section is about subscreen areas. The actual screens that you embed are called subscreen screens. When you use a subscreen, the flow logic of the embedded screen is also embedded in the flow logic of the main screen. Using subscreens on screens is like using includes in ABAP programs.

Subscreens allow you to expand the content of a screen dynamically at runtime. For example, screen exits, which are part of the enhancement concept, use the subscreen technique. Some complex screen elements, like tabstrip controls, also use them.

To use a subscreen, you must:

Define the subscreen area(s) on a screen

Define suitable subscreen screens

Include the subscreen screen in the subscreen area.

Defining Subscreen Areas

You define subscreen areas using the Screen Painter in the layout of the screen on which you want to embed a subscreen. Each subscreen area on a screen has a unique name, and a position, length, and height. Subscreen areas may not overlap either with each other or with other screen elements. You can also specify whether a subscreen area can be resized vertically or horizontally when the user resizes the window. If the area supports resizing, you can specify a minimum size for it. If the resizing attributes are selected, the PAI event is triggered whenever the user resizes the main screen.

Defining Subscreen Screens

You can create subscreen screens either in the same program or a different program. To create a subscreen screen, enter the screen type Subscreen in the screen attributes. The statically-defined next screen must be the number of the subscreen itself. Choose a size for the screen, making sure that it fits within the subscreen area into which you want to place it. If the subscreen screen is too big for the subscreen area, only the top left-hand corner of it will be displayed.

You create the layout, element list, and flow logic of a subscreen screen in the same way as a normal screen. Subscreens may also include other subscreens. However, the following restrictions apply:

You should arrange the screen elements so that they are not truncated if a subscreen area is too small.
If you want to create several subscreen screens in an ABAP program, you should make sure that the individual screen elements have names unique among the subscreens. If the subscreen screens belong to the same program as the main screen, you should also make sure that names are not used twice there. Otherwise, you must separate data transported from the screen in your ABAP program after each user action (see example).
Subscreens cannot have their own OK_CODE field. Function codes linked to user actions on subscreens are placed in the OK_CODE field of the main screen. This also applies to subscreen screens defined in a different program to the main screen.
The flow logic of a subscreen screen may not contain a MODULE ... AT EXIT-COMMAND statement. Type E functions may only be handled in the main screen.
The flow logic of a subscreen screen may not contain any dialog modules containing the statements SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN, or LEAVE TO SCREEN. Any of these statements causes a runtime error. You cannot change the GUI status of a main screen in a subscreen screen.

Including Subscreen Screens

You include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of the main screen.

To include a subscreen screen in the subscreen area of the main screen and call its PBO flow logic, use the following statement in the PBO event of the main screen:

PROCESS BEFORE OUTPUT.
...
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.
...

This statement assigns the subscreen screen with number <dynp> to the subscreen area called <area>. You can also specify the program in which the subscreen screen is defined (optional). If you do not specify the program explicitly, the system looks for the subscreen screen in the same ABAP program as the main program. If it does not find a corresponding subscreen screen, a runtime error occurs. The PBO flow logic of the subscreen screen is also included at the same point. This can call PBO modules of the ABAP program in which the subscreen screen is defined. At the end of the subscreen PBO, the global fields from the program are passed to any identically-named screen fields in the subscreen screen. The PBO flow logic of the subscreen screen can itself include further subscreens.

The name <area> of the subscreen area must be entered directly without inverted commas. You can specify the names <prog> and <dynp> either as literals or variables. If you use variables, you must declare and fill identically-named variables in the ABAP program. The screen number <dynp> must be 4 characters long. If you do not assign a subscreen screen to an area, it remains empty.

To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow logic of the main screen:

PROCESS AFTER INPUT.
...
CALL SUBSCREEN <area>.
...

This statement includes the PAI flow logic of the subscreen screen included in the subscreen area <area> in the PBO event. This can call PAI modules of the ABAP program in which the subscreen screen is defined. Data is transported between identically-named fields in the subscreen screen and the ABAP program either when the PAI event is triggered, or at the corresponding FIELD statements in the PAI flow logic of the subscreen screen.

You cannot place the CALL SUBSCREEN statement between CHAIN and ENDCHAIN or LOOP and ENDLOOP (see table controls). While a subscreen screen is being processed, the system field SY-DYNNR contains its screen number. Its contents therefore change when the CALL SUBSCREEN statement occurs and when you return to the main screen.

When you use subscreen screens, remember that the data from their input/output fields is transported to and from the programs in which they are defined. The function codes of user actions on the screen, on the other hand, are always placed in the OK_CODE field of the main screen, and transported into the program in which it is defined. You should therefore name the function codes of your subscreen screens differently from those of the main screen.

If, for encapsulation reasons, you define subscreen screens in other ABAP programs, you must ensure that the required global data of your ABAP programs is transported into the program of the calling screen after you have called their PAI flow logic.

For example, you can define subscreen screens in function groups and pass their global data to and from function module parameters. You must then call the function modules in appropriate dialog modules in the main program to transport the data.

You can also export the global data from the main program as a data cluster to ABAP memory before the PBO of a subscreen screen and import it into a PBO module of the subscreen.

Example

Subscreens

REPORT DEMO_DYNPRO_SUBSCREENS.

DATA: OK_CODE LIKE SY-UCOMM,
SAVE_OK LIKE SY-UCOMM.

DATA: NUMBER1(4) TYPE N VALUE '0110',
NUMBER2(4) TYPE N VALUE '0130',
FIELD(10), FIELD1(10), FIELD2(10).

CALL SCREEN 100.

MODULE STATUS_100 OUTPUT.
SET PF-STATUS 'SCREEN_100'.
ENDMODULE.

MODULE FILL_0110 OUTPUT.
FIELD = 'Eingabe 1'(001).
ENDMODULE.

MODULE FILL_0120 OUTPUT.
FIELD = FIELD1.
ENDMODULE.

MODULE FILL_0130 OUTPUT.
FIELD = 'Eingabe 2'(002).
ENDMODULE.

MODULE FILL_0140 OUTPUT.
FIELD = FIELD2.
ENDMODULE.

MODULE CANCEL INPUT.
LEAVE PROGRAM.
ENDMODULE.

MODULE SAVE_OK INPUT.
SAVE_OK = OK_CODE.
CLEAR OK_CODE.
ENDMODULE.

MODULE USER_COMMAND_0110 INPUT.
  IF SAVE_OK = 'OK1'.
     NUMBER1 = '0120'.
     FIELD1 = FIELD.
     CLEAR FIELD.
  ENDIF.
ENDMODULE.

MODULE USER_COMMAND_0130 INPUT.
  IF SAVE_OK = 'OK2'.
     NUMBER2 = '0140'.
     FIELD2 = FIELD.
     CLEAR FIELD.
  ENDIF.
ENDMODULE.

MODULE USER_COMMAND_100 INPUT.
  CASE SAVE_OK.
    WHEN 'SUB1'.
      NUMBER1 = '0110'.
    WHEN 'SUB2'.
      NUMBER1 = '0120'.
      CLEAR FIELD1.
    WHEN 'SUB3'.
      NUMBER2 = '0130'.
    WHEN 'SUB4'.
      NUMBER2 = '0140'.
      CLEAR FIELD2.
  ENDCASE.
ENDMODULE.

The next screen (statically defined) for screen 100 is itself. It has the following layout:

There are four pushbuttons with the function codes SUB1 to SUB4, and two subscreen areas AREA1 and AREA2.

In the same ABAP program, there are four subscreen screens 110 to 140. Each of these fits the subscreen area exactly. The layout is:

The input/output field of all four subscreen screens has the name FIELD. The function codes of the pushbuttons on the subscreen screens 110 and 130 are OK1 and OK2.

The screen flow logic for screen 100 is as follows:

PROCESS BEFORE OUTPUT.
  MODULE STATUS_100.
  CALL SUBSCREEN: AREA1 INCLUDING SY-REPID NUMBER1,
                  AREA2 INCLUDING SY-REPID NUMBER2.

PROCESS AFTER INPUT.
  MODULE CANCEL AT EXIT-COMMAND.
  MODULE SAVE_OK.
  CALL SUBSCREEN: AREA1,
                  AREA2.
  MODULE USER_COMMAND_100.

The screen flow logic of subscreen screens 110 and 130 is:

PROCESS BEFORE OUTPUT.
MODULE FILL_0110|0130.

PROCESS AFTER INPUT.
MODULE USER_COMMAND_0110|0130.

Die Bildschirmablauflogik der Subscreen-Dynpros 120 und 140 ist:

PROCESS BEFORE OUTPUT.
MODULE FILL_0120|0150.

PROCESS AFTER INPUT.

When you run the program, a screen appears on which subscreens 110 and 130 are displayed. The pushbuttons on the main screen allow you to choose between two subscreen screens for each screen area. The pushbuttons on the subscreens allow you to transfer the data from subscreens 110 and 130 to subscreens 120 and 140.

Since the same field name FIELD is used on all subscreens, the identically-named ABAP field is transferred more than once in each PBO and PAI event of the main screen. For this reason, the values have to be stored in the auxiliary fields FIELD1 and FIELD2 in the ABAP program.

The pushbuttons on the subscreen screens have different function codes, and they are handled normally in an ABAP field. If the function codes had had the same names, it would again have been necessary to use auxiliary fields.