A module pool is a collection of screens, flow logic, menu bars and ABAP code that you use to build an application. Typically the transaction code that calls the application will refer to the module pool and the initial screen number.
Or
Dialog Programming is a special type of programming in SAP ABAP. Dialog programming is used to create custom SAP screens as per business requirement. Dialog programs are executed using T-codes.
The flow logic Keyword at EXIT-COMMAND is a special addition to the MODULE statement in the Flow Logic .AT EXIT-COMMAND lets you call a module before the system executes the automatic fields checks.
When the User selects a function in a transaction ,the system copies the function code into a specially designated system field called SY-UCOMM.
This field is Global in ABAP/4 Module Pool.The F-CODE can then be evaluated in the corresponding PAI module.
The function code is always passed in exactly the same way, regardless of whether it comes from a screen push button, a menu option, function key or other GUI element.
The FIELD and CHAIN flow logic statements let you Program your own checks.
FIELD and CHAIN tell the system which fields you are checking and Whether the System should Perform Checks in the flow logic or calls an ABAP/4 Module.
The ABAP/4 module is called only if a field contains the Value other than the initial Value.
This initial Value is determined by the field’s data Type: blanks for character Fields.
Zeros for numerics. If the user changes the Fields Value back to its initial value, ON INPUT does not trigger a call.
The ABAP/4 Module is called only if the user has entered the value in the field value since the last screen display .
The Value counts as changed Even if the User simply types in the value that was already there .In general ,the ON REQUEST condition is triggered through any Form of” MANUAL INPUT’.
The ABAP/4 module is called if the user has entered the “*” in the first character of the field, and the field has the attribute *-entry in the screen Painter.
You can use this option in Exceptional cases where you want to check only fields with certain Kinds of Input.
No,. The system instead transfers data by comparing screen fields names with ABAP/4 variable names. If both names are the same, it transfers screen fields values to ABAP/4 programs fields and Vice Versa.This happens immediately after displaying the screen.
The flow control of a dynpro consists of a few statements that syntactically resemble ABAP/4 statements .However, we cannot use flow control keywords in ABAP/4 and vice-versa.
A GUI status is a subset of the interface elements used for a certain screen.
The GUI status for a transaction may be composed of the following elements:
Title bar.
Menu bar.
Application tool bar
Push buttons.
To create and edit GUI status and GUI title, use the Menu Painter (SE 41).
A transaction is a collection of screens and ABAP/4 routines, controlled and executed by a Dialog processor.
The Dialog processor processes screen after the screen, thereby triggering the appropriate ABAP/4 processing of each screen .
For each screen, the system executes the flow logic that contains the corresponding ABAP/4 processing.
The control passes from screen flow logic to ABAP/4 code and back.
When an action is performed, the system triggers the PROCESS AFTER INPUT event.The data passed includes field screen data entered by the user and a function code.
A function code is a technical name that has been allocated in a screen Painter or Menu Painter to a menu entry, a push button, the ENTER key or a function Key of a screen.
An internal work field (ok-code) in the PAI module evaluates the function code, and the appropriate action is taken.
A function code has to be defined in the screen attributes for the push buttons in a screen.
A transaction is dialog program that change data objects in a consistent way.
A user friendly user interface.
Format and consistency checks for the data entered by the user.
Easy correction of input errors.
Access to data by storing it in the data bases.
To have your own customized screens and processing.
Screens with their corresponding processing code, Menu, module pool program.
A dynpro (Dynamic Program) consists of a screen and its flow logic and controls exactly one dialog steps. The different components of the dynpro are:
Flow Logic: calls of the ABAP/4 modules for a screen.
Screen layout: Positions of the text, fields, and pushbuttons and so on for a screenScreen Attributes: Number of the screen, number of the subsequent screen, and others
Fields attributes: Definition of the attributes of the individual fields on a screen.
Normal report can be run straight away by executing it and usually has selection criteria –Attributes: 1 online program
Module pool program cannot be run straight away.
It first needs to display a screen – attributes: M module pool program.
“fctcode” attributes of the button.
Process before output. Code that is executed prior to the display of a screen.
Process after input. Code that is executed after a button on the screen has been pressed.
PBO – MODULE STATUS_0100 – Key / button definitions
PAI – * MODULE USER_COMMAND_0100 How do you handle the code behind the button that was pressed