To make your application move from screen to screen, a flow of screens needs to be coded. Here's how:
A screen flow can be set up using two ways or "jump to next screen" methods. When a transaction code is created for a module pool program, the first screen is filledin there. This is your starting point for the program. From there the possible screen jumps can be "Jump to the next screen (and come back afterwards)" (CALL SCREEN) or move to the next screen (LEAVE TO SCREEN). An example: LEAVE TO SCREEN 1100. or CALL SCREEN 1110 STARTING AT 5 6 ENDING AT 60 20.
Returning from the "called" screen can be done with LEAVE TO SCREEN 0. Leaving to screen 0 from a normal screen would stop the application.
The other thingto take into account is defining the starting point of a screen flow. You may have noticed that module pools (dynpro applications) require a transaction code to start off. The transaction code is also where the first screen to be called is set. So effectively the first line of code that is executed for a module pool application is the first Process Before Output module of the screen that is defined on the transaction code...
Screen flow or flow logic does not only describe how screens are linked to each other, it also describes the flow of (within) a single screen.
The principle of PBO - Process Before Output and PAI - Process After Input
The flow logic principle, "field handling within a screen", is divided in several events within ABAP, the most important events: PROCESS BEFORE OUTPUT and PROCESS AFTER INPUT. They contain the steps that have to be taken before activating the screen and after user interaction. PROCESS BEFORE OUTPUT is used for example to fill in or modify certain data fields, PROCESS AFTER INPUT to process what the user has entered.
A simple (minimal) example of PBO PAI implementation (in the flow logic of a DYNPRO).
*------------------------------------- PROCESS BEFORE OUTPUT. *------------------------------------- * Called before screen-display MODULE D1310_INIT. *------------------------------------- PROCESS AFTER INPUT. *------------------------------------- * Called after screen-display + user interaction MODULE D1310_MENU_RESPONS.
The event PROCESS BEFORE OUTPUT is always processed for every screen, but filled least in practice. A few examples:
- set the menu that should be used (
SET PF-STATUS ..) - set the title to be displayed (
SET TITLEBAR ..) - table control matters or ALV control matters
- switching off screen fields (or make them read-only)
- positioning a list using an ABAP variable counter
- calculating a variable that has to represent the total of three other fields.
Most processing for screen will be done after input is received, which makes the process before output less important than process after input.
The event PROCESS AFTER INPUT is also processed for every screen. A few examples of typical processing tasks:
- check field contents (an error message thrown in PAI will stop further processing and freeze the screen. Fields which are linked to the message (module processing for the screen or CHAIN of field processing for several fields) will remain available for input on the frozen screen.
- Processing (follow-up) on menu actions, which could lead to moving to the next screen.
An example for Process before output logic:
*------------------------------------- PROCESS BEFORE OUTPUT. *------------------------------------- MODULE D1310_INIT. "Called before screen-display *------------------------------------- PROCESS AFTER INPUT. *------------------------------------- * The fields within the chain are grouped CHAIN. FIELD MATNR_FROM MODULE D1310_MATNR_FROM. FIELD MATNR_TO MODULE D1310_MATNR_TO. FIELD ZTRM-TRMSRT MODULE D1310_TRMSRT. ENDCHAIN. MODULE D1310_CALCULATION. "Calculate stuff MODULE D1310_MENU_RESPONS. "Catch the end user's action