Imp: Module pool Or Dialog programming

Question

Hi ,
I have got  a requirement to work on module pool programming.....Please help me with some documents which explains me about it from scratch clearly .
Awaiting for ur reply...........

Answer 1

basics of module pool
<u><i><b>OVERVIEW</b></i></u>
There are programs in every domain that require certain amount of user interaction .Such requirements in ABAP are fulfilled with the help of a user dialog and dialog programming which encapsulates the entire logic pertaining to the required user dialog.
One needs to take care that user interactions with the system are comfortable and user friendly along with being logically coherent.
<u><i><b>What is a user dialog?</b></i></u>
Any kind of user interaction with the system can be called as a user dialog:
1)     Entering data on the screen.
2)     Clicking a button.
3)     Navigation between screens.
<u><i><b>Need of dialog programming</b></i></u>
In a typical dialog, the system displays a screen on which the user can enter or request information. As a reaction on the user input or request, the program executes the appropriate actions: it branches to the next screen, displays an output, or changes the database.
Example
A travel agent wants to book a flight. The agent enters the corresponding data on the screen. The system either confirms the desired request, that is, the agent can book the flight and the customer travels on the desired day on the reserved seat to the chosen destination, or the system displays the information that the flight is already booked up.
To fulfill such requirements, a dialog program must offer:
• 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 database.
ABAP/4 offers a variety of tools and language elements to meet the requirements stated above in the dialog programs.
<u><i><b>
Why dialog programming is also known as module pool?</b></i></u>
Dialog Programming consists of screens and corresponding ABAP program. Screens call dialog modules in the associated ABAP program from their flow logic. Type M programs serve principally as containers for these dialog modules, and hence dialog programming is also known as module pools. A module pool program is a program type which is not executable directly. You can not just run by hitting F8 like a report program. You must tie a transaction code to a screen in order to start the program.
<i><b>VARIOUS COMPONENTS OF A DIALOG PROGRAM</b></i>
Unlike report, interface or any conversion development which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects none of which can be executed on its own. Instead all objects are linked hierarchically to the main program and are executed in a sequence dictated by the Dialog Main Program.
<u><i><b>
Components of a dialog program</b></i></u>
1)     Transaction
2)     Screen
3)     GUI status
4)     ABAP program
All these components are explained in detail below.
1)     TRANSACTION  :
The transaction starts a screen sequence. You create transaction codes in the Repository   Browser in the ABAP Workbench or using Transaction SE93. A transaction code is linked to an ABAP program and an initial screen. As well as using a transaction code, you can start a screen sequence from any ABAP program using the CALL SCREEN statement.
2) SCREEN
As a user of an R/3 system, one is always confronted with screens. From the moment one logs on, one can see a screen and one must perform actions on this screen. All those screens are components of ABAP programs. Generally, we define the screens of an ABAP program with the Screen Painter tool of the ABAP.
In the R/3 system, screens are program objects that consist of two parts. First, they have a layout that defines the front end appearance of the window that is presented to the user. Second, they have a flow logic that is executed on the backend by the application server. The screen flow logic is a program layer between the front end and the actual ABAP application program at the backend. The language used to program screen flow logic has a similar syntax to ABAP, but is not part of ABAP itself. Unlike ABAP programs, the screen flow logic contains no explicit data declarations. You define the screen fields by placing elements on the screen mask instead. When you define screen fields by referring to data types in the ABAP Dictionary, the runtime environment automatically creates dialogs for field help, input help, and error handling that depends on the semantics of the data type in the dictionary.
The screen flow logic is similar to an ABAP program in that it contains processing blocks. These processing blocks are event blocks that are triggered by the ABAP runtime environment. The most important event blocks are:
• PROCESS BEFORE OUTPUT
The respective event (PBO) is triggered after the PROCESS AFTER INPUT (PAI) processing of the previous screen and before the current screen is displayed.
• PROCESS AFTER INPUT
The respective event (PAI) is triggered when the user chooses a function on the current screen.
• PROCESS ON HELP REQUEST
This event is triggered when function key F1 is pressed.
• PROCESS ON VALUE REQUEST
This event is triggered when function key F4 is pressed.
The main task of these processing blocks is to call ABAP dialog modules using the MODULE statement. During the PBO event, you can call any dialog module in the ABAP program that is marked with the addition OUTPUT. In the PAI event, you can call any dialog module program that is marked with the addition INPUT. The screens of an ABAP program can share the dialog modules of that program. You use the dialog modules called during PBO to prepare the screen and the dialog modules called during PAI to react to the user input.
Each screen of an ABAP program has a unique screen number. The screens of an ABAP program can be combined to form screen sequences. Screen sequences are either built statically by setting the following screen in the Screen Painter or dynamically by overriding the static setting in the ABAP program. The last screen of a screen sequence is always the one where the following screen is set to zero.
ATTRIBUTES OF SCREEN
Like all objects in the R/3 Repository, screens have attributes that both describe them and determine how they behave at runtime. Important screen attributes for ABAP programming:
•     Program
The name of the ABAP program (type 1, M, or F) to which the screen belongs.
•     Screen number
A four-digit number, unique within the ABAP program that identifies the screen within the program. If your program contains selection screens, remember that selection screens and Screen Painter screens use the same namespace. For example, if you have a program with a standard selection screen, you may not contain any further screens with the number 1000. Lists, on the other hand, have their own namespace.
•     Screen type
A normal screen occupies a whole GUI window. Modal dialog boxes only cover a part of a GUI window. Their interface elements are also arranged differently. Selection screens are generated automatically from the definition in the ABAP program. You may not define them using the Screen Painter. A subscreen is a screen that you can display in a subscreen area on a different screen in the same ABAP program.
•     Next screen
Statically-defined screen number, specifying the next screen in the sequence. If you enter zero or leave the field blank, you define the current screen as the last in the chain. If the next screen is the same as the current screen, the screen will keep on calling itself. You can override the statically-defined next screen in the ABAP program.
•     Cursor position
Static definition of the screen element on which the cursor is positioned when the screen is displayed. By default, the cursor appears on the first input field. You can overwrite the static cursor position dynamically in your ABAP program by using SET CURSOR FIELD <f>
•     Screen group
Four-character ID, placed in the system field SY-DYNGR while the screen is being processed. This allows you to assign several screens to a common screen group. You can use this, for example, to modify all of the screens in the group in a uniform way. Screen groups are stored in table TFAWT.
•     Hold data
If the user calls the screen more than once during a terminal session, he or she can retain changed data as default values by choosing System -> User profile -> Hold data.
VARIOUS SCREEN ELEMENTS
A screen can contain a wide variety of elements, either for displaying field contents, or for allowing the user to interact with the program (for example, filling out input fields or choosing pushbutton functions). We use the Screen Painter to arrange elements on the screen.
We can use the following elements:
•     Text fields
Display elements, which cannot be changed either by the user or by the ABAP program.
•     Input/output fields and templates
Used to display data from the ABAP program or for entering data on the screen. Linked to screen fields.
•     Dropdown list boxes
Special input/output fields that allow users to choose one entry from a fixed list of possible entries.
•      Checkbox elements
Special input/output fields that the user can either select (value ‘X’) or deselect (value SPACE). Checkbox elements can be linked with function codes.
•     Radio button elements
Special input/output fields that are combined into groups. Within a radio button group, only a single button can be selected at any one time. When the user selects one button, all of the others are automatically deselected. Radio button elements can be linked with function codes.
•     Pushbuttons
Elements on the screen that trigger the PAI event of the screen flow logic when chosen by the user. There is a function code attached to each pushbutton, which is passed to the ABAP program when it is chosen.
•     Frame
Pure display elements that group together elements on the screen, such as radio button groups.
•     Subscreens
Area on the screen in which you can place another screen.
•     Table controls
Tabular input/output fields.
•     Tab strip controls
Areas on the screen in which you can switch between various pages.
•     Custom Controls
Areas on the screen in which you can display controls. Controls are software components of the presentation server.
•     Status icons
Display elements, indicating the status of the application program.
•     OK field
Every screen has a twenty-character OK_CODE field (also known as the function code field) that is not displayed directly on the screen. User actions that trigger the PAI event also place the corresponding function code into this field, from where it is passed to the ABAP program. You can also use the command field in the standard toolbar to enter the OK field. To be able to use the OK field, you need to assign a name to it.
All screen elements have a set of attributes, some of which are set automatically, others of which have to be specified in the Screen Painter. They determine things such as the layout of the screen elements on the screen. You can set the attributes of screen elements in the Screen Painter - either for a single element, or using the element list, which lists all of the elements belonging to the current screen. Some of the attributes that you set statically in the Screen Painter can be overwritten dynamically in the ABAP program.
Regards
navjot
reward points if helpfull