Show TOC

SubscreensLocate this document in the navigation structure

Use

Subscreen technology enables one screen to be embedded within another screen of a dynpro at runtime. The term subscreen applies both to the screen where it is embedded and the area on the main dynpro in which it is placed. This section is about subscreen areas. The actual screens that are embedded are called subscreen dynpros. When subscreens are embedded, the flow logic of the subscreen dynpro is also embedded. Using subscreens on dynpros is like using includes in ABAP programs.

Subscreens enable the content of a dynpro to be expanded dynamically at runtime. For example, dynpro exits, which are part of the enhancement concept, use the subscreen technique. Some complex screen elements, like tabstrips, are also based on subscreens.

The following must be done before using subscreens:

  1. Subscreen areas must be defined on a screen.

  2. Suitable subscreen dynpros must be defined.

  3. The subscreen dynpros must be embedded dynamically in the subscreen areas.

Defining Subscreen Areas

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

Defining Subscreen Dynpros

Subscreen dynpros can be created either in the same ABAP program or a different program. Subscreen dynpros are created by entering the dynpro type Subscreen in the dynpro attributes. The static next dynpro must be the dynpro number of the subscreen itself. The size of the screen must be chosen to make sure that it fits within the subscreen area where it is placed. If the subscreen dynpro is too big for the subscreen area, only the top left-hand corner of it is displayed.

The layout, element list, and flow logic of a subscreen dynpro are created in the same way as a regular dynpro. Subscreen dynpros may also include other subscreens. However, the following restrictions apply:

  • The screen elements should be arranged so that they are not truncated if a subscreen area is too small.

  • If multiple subscreen dynpros are created in an ABAP program, the individual screen elements must have names unique among the subscreens. If the subscreen dynpros are part of the same program as the main dynpro, the names cannot be used twice there. Otherwise, data transported from the screen in the ABAP program must be separated after each user action (see example).

  • Subscreen dynpros cannot have their own OK_CODE field. Function codes associated with user actions on subscreens are placed in the OK_CODE field of the main dynpro. This also applies to subscreen dynpros defined in a different program to the main dynpro.

  • The flow logic of a subscreen dynpro cannot contain module calls using AT EXIT-COMMAND. Type E function codes can only be handled in the main dynpro.

  • The flow logic of a subscreen dynpro cannot contain any dialog modules containing the ABAP statements SET TITELBAR, SET PF-STATUS, SET SCREEN, or LEAVE SCREEN or LEAVE TO SCREEN. Any of these statements produces a runtime error. This means that the GUI status of a main dynpro cannot be modified in a subscreen dynpro.

    Selection screens can also be defined as subscreens.

Including Subscreen Dynpros

Subscreen dynpros are included using the statement CALL SUBSCREEN in the flow logic of the main dynpro.

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

PROCESS BEFORE OUTPUT.
...
   CALL SUBSCREEN area INCLUDING prog dynp.
...

This statement assigns the subscreen dynpro with number dynp to the subscreen area called area. prog must must specify the ABAP program in which the subscreen dynpro is defined. If it does not find a corresponding subscreen dynpro, a runtime error occurs. The PBO flow logic of the subscreen dynpro is also included at the same point. This can call PBO modules of the ABAP program in which the subscreen dynpro is defined. At the end of the subscreen PBO, the global fields from the program are passed to any identically named fields in the subscreen dynpro. The PBO flow logic of the subscreen dynpro can itself include further subscreen dynpros.

The name area of the subscreen area must be entered directly without quotation marks. The names prog and dynp can be specified either as literals or variables. If variables are used, identically named variables must be declared and filled in the ABAP program. The dynpro number dynp must be four digits long. If a subscreen dynpro is not assigned to a subscreen area, it remains empty.

To call the PAI flow logic of the subscreen dynpro, the following statement is used in the PAI flow logic of the main dynpro:

PROCESS AFTER INPUT.
...
   CALL SUBSCREEN area.
...

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

The statement CALL SUBSCREEN cannot be placed between CHAIN and ENDCHAIN or LOOP and ENDLOOP (see Table Controls). While a subscreen dynpro is being processed, the system field sy-dynnr contains its dynpro number. Its contents therefore change when the statement CALL SUBSCREEN is executed and when the processing of the main dynpro resumes.

When subscreen dynpros are used, the data from their input/output fields must be transported to and from the ABAP programs in which they are defined. The function codes of user actions on the dynpro, on the other hand, are always passed to the OK_CODE field of the main dynpro, and transported into the ABAP program in which it is defined. The function codes of included subscreen dynpros should therefore be distinguishable from each other..

If, for encapsulation reasons, subscreen dynpros are defined in other ABAP programs, the required global data of their ABAP programs must be transported to the program of the calling dynpro after their PAI flow logic is called.

  • For example, subscreen dynpros can be defined in function groups and and their global data assigned to function module parameters and back. The function modules must then be called in appropriate dialog modules in the main program to transport the data.

  • The global data from the main program can be exported as a data cluster to the ABAP memory before PBO of a subscreen dynpro and imported to a PBO module of the subscreen dynpro. The reverse happens at PAI time.

Subscreens



REPORT demo_dynpro_subscreens.
DATA: ok_code TYPE sy-ucomm,
      save_ok TYPE sy-ucomm.
DATA: number1(4) TYPE n VALUE '0110',
      number2(4) TYPE n VALUE '0130',
      field(10) TYPE c, field1(10) TYPE c, field2(10) TYPE c.
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 static next dynpro number of dynpro 100 is 100. 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 dynpros, numbered 110 to 140. Each of these fits the subscreen area exactly. The layout is:

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

The screen flow logic for dynpro 100 is as follows:



  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 dynpros 110 and 130 is:

PROCESS BEFORE OUTPUT.
   MODULE fill_0110|0130.
PROCESS AFTER INPUT.
   MODULE user_command_0110|0130.

The screen flow logic of subscreen dynpros 120 and 140 is:

PROCESS BEFORE OUTPUT.
   MODULE fill_0120|0150.
PROCESS AFTER INPUT.

When the program is executed, a screen appears on which subscreens 110 and 130 are displayed. The pushbuttons on the main dynpro allow the user to choose between two subscreen dynpros for each screen area. The pushbuttons on the subscreen dynpros 110 and 130 allow data to be passed to the subscreen dynpros 120 and 140.

Since the same field name field is used on all subscreen dynpros, the identically named ABAP field is passed more than once in each PBO and PAI event of the main dynpro. 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 dynpros have different function codes and they are handled in the standard way in an ABAP field. If the function codes had the same names, it would be necessary to use multiple auxiliary fields here as well.