Processing Blocks in Dialog Programming

The following sections explain the different processing blocks in Dialog Programming and how they are called.

Dialog Modules

You call dialog modules from the screen flow logic (screen command MODULE). You can write a dialog module in an ABAP program for each state (PBO, PAI; user input) of any of the screens belonging to it. The PAI modules of a screen together with the PBO modules of the subsequent screen form a dialog step. The interaction between the flow logic and the screen is controlled by a dialog processor.

Dialog modules are introduced with the MODULE statement and concluded with the ENDMODULE statement.

Fields on a dialog screen have the same name as a corresponding field in the ABAP program. Data is passed between identically-named fields in the program.

Event Blocks for Selection Screens

A selection screen is a special kind of dialog screen that you create using ABAP commands in the declaration part of the program. The different events in a selection screen (PAI, PBO, user input), are controlled by a selection screen processor. You can program processing logic for these events in your program. The selection screen processor controls the flow logic of the selection screen.

You do not have to create the screen flow logic yourself, neither can you create your own dialog modules for the PBO or PAI events . Data is passed between selection screen and ABAP program using the fields (parameters and selection tables (ranges)) which you create in the selection screen definition in the declaration part of the ABAP program.

Event Blocks for Lists

Lists are special screens which output formatted data. You can create them in any processing block in an ABAP program using a special set of commands (such as WRITE, NEW-PAGE and so on). The list processor displays the list on the screen and handles user actions within lists. The list processor controls the flow logic of the list. You do not have to create the screen flow logic yourself, neither can you create your own dialog modules for the PBO or PAI events .

You can call various event blocks while the list is being created which are used in page formatting. The above illustration contains the event block TOP-OF-PAGE, which is called from the ABAP program itself. When the list is displayed, the user can carry out actions which trigger event blocks for interactive list events (such as AT LINE-SELECTION). You can program processing logic for the interactive list events in your program. Data is transferred from list to ABAP program via system fields or an internal memory area called the HIDE area.

Event Blocks for Executable Programs (Reports)

When you run an executable program (type 1), it is controlled by a predefined process in the runtime environment. A series of processors is called, one after the other. These processors trigger events, for which you can define event blocks. Type 1 programs are event-driven.

The process is as follows:

1. The runtime environment creates the INITIALIZATION event and calls the corresponding event block (if it has been defined in the ABAP program).
2. If there is a selection screen defined in the program, control returns to the selection screen processor. This generates the corresponding events and calls their event blocks.
3. Control then passes to the reporting processor. It creates the START-OF-SELECTION event and calls the corresponding event block (if it has been defined in the ABAP program).
4. The logical database, if you are using one, calls further event blocks at this point.
5. The reporting processor creates the END-OF-SELECTION event and calls the corresponding event block (if it has been defined in the ABAP program).
6. If the program contains a list description, control now passes to the list processor. The list processor displays the list defined in the ABAP program. It converts user actions on the list into events and calls the corresponding event blocks.

Subroutines

You call subroutines from ABAP programs using the PERFORM statement.

Subroutines are introduced with the FORM statement and concluded with the ENDFORM statement.

You can define subroutines in any ABAP program. You can either call a subroutine that is part of the same program or an external subroutine, that is, one that belongs to a different program. If you call an internal subroutine, you can use global data to pass values between the main program and the subroutine. When you call an external subroutine, you must pass actual parameters from the main program to formal parameters in the subroutine.

Function Modules

Function modules are external functions with a defined interface. You call function modules from ABAP programs using the CALL FUNCTION statement.

Function modules are introduced with the FUNCTION statement and concluded with the ENDFUNCTION statement.

You can only create function groups within special ABAP programs called function groups using the Function Builder. This means that you can only call them externally from other ABAP programs. Unlike subroutines, you always pass data to function modules using an explicit parameter interface.

Methods

Methods describe the functions of classes in ABAP Objects. Like function modules, they have a defined interface. You call methods from ABAP programs using the CALL METHOD statement.

Methods are introduced with the METHOD statement and concluded with the ENDMETHOD statement.

Methods can only be defined in the implementation parts of classes. You can either do this globally in the Class Builder, or locally within ABAP programs. Methods can work with the attributes of their class and with data that you pass to them using their explicit parameter interface.

Chain ... End Chain

Sometimes you want to check several fields as a group. To do this, include the fields in a FIELD statement, and enclose everything in a CHAIN-ENDCHAIN block.

Example

**** Screen flow logic: ****
CHAIN.

FIELD: SPFLI-CARRID, SPFLI-CONNID.

 MODULE CHECK_FLIGHT.

ENDCHAIN.

When an error is found, the screen is re-displayed, and all fields found anywhere in the chain are input-enabled (because of FIELD .. MODULE statement). All non-chain fields remain disabled (Without FIELD as declaration).