module pool

[Former Member]

Hi,

what is module pool program?

Regards

[former_member156446]

Module pool programs are created in abap development work bench (TCODE: SE80).

Here we can do all the works whatever you can do in abap.

Module pool programs are also called dialog programs.

The module Pool are reports prepared for different screens and to manage the sequence of events of these screens, in the transaction SE80 you can see all the dynpros that you have for this kind of report, add new ones, add all types of element to the report.

Process Before Output is the part of the dynpro code that is processed before the user can do anything with the data in the screen

Process After Input is the part of the dynpro code that is processed after the interaction with the user.

module pool programs are excuted using Tcodes

PROGRAM YMPSKEL MESSAGE-ID YL.
*-----------------------------------------------------------------------
* DESCRIPTION
* written by !
*-----------------------------------------------------------------------
* TABLES:

DATA: OK_CODE(4), " ok code - screen 1
OK_CODE2(4).
DATA C LIKE SY-INDEX. " Index for screen loop
*&---------------------------------------------------------------------*
*& Module USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------------*
* process after input for screen 0100 *
*----------------------------------------------------------------------*
MODULE USER_COMMAND_0100 INPUT.

CASE OK_CODE.
WHEN 'SAVE'.
*
WHEN 'DISP'.
*
WHEN 'LIST'.
C = 0. "reset loop control
*
WHEN OTHERS.
*
ENDCASE.
CLEAR OK_CODE.
ENDMODULE. " USER_COMMAND_0100 INPUT
*&---------------------------------------------------------------------*
*& Module STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
* process before output for screen 0100 *
*----------------------------------------------------------------------*
MODULE STATUS_0100 OUTPUT.
SET PF-STATUS 'AMEND'. " set gui status
SET TITLEBAR '100'. " set title
ENDMODULE. " STATUS_0100 OUTPUT
*&---------------------------------------------------------------------*
*& Form SAVE data
*&---------------------------------------------------------------------*
* Save screen details
*&---------------------------------------------------------------------*
FORM SAVE.
*
CLEAR OK_CODE.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form DISPLAY
*&---------------------------------------------------------------------*
*----------------------------------------------------------------------*
FORM DISPLAY.
*
*

ENDFORM.
*&---------------------------------------------------------------------*
*& Module EXIT_COMMAND INPUT
*&---------------------------------------------------------------------*
* exit commands are processed before validation *
* defined by E against function in menu painter(function list)
*----------------------------------------------------------------------*
MODULE EXIT_COMMAND INPUT.

CASE OK_CODE.
WHEN 'EXIT'. CLEAR OK_CODE. SET SCREEN 0. LEAVE SCREEN.
WHEN 'CANC'. CLEAR OK_CODE. SET SCREEN 0. LEAVE SCREEN.
WHEN 'BACK'. CLEAR OK_CODE. SET SCREEN 0. LEAVE SCREEN.
ENDCASE.
ENDMODULE. " EXIT_COMMAND INPUT
*&---------------------------------------------------------------------*
*& Form list
*&---------------------------------------------------------------------*
* text *
*----------------------------------------------------------------------*
FORM LIST.


CLEAR OK_CODE. SET SCREEN 200. LEAVE SCREEN.

ENDFORM. " LIST
*&---------------------------------------------------------------------*
*& Module EXIT_COMMAND_200 INPUT
*&---------------------------------------------------------------------*
* exit command processing for screen 200 *
* defined by E against function in menu painter(function list)
*----------------------------------------------------------------------*
MODULE EXIT_COMMAND_200 INPUT.

CASE OK_CODE2.
WHEN 'EXIT'. CLEAR OK_CODE2. SET SCREEN 0. LEAVE SCREEN.
WHEN 'CANC'. CLEAR OK_CODE2. SET SCREEN 0. LEAVE SCREEN.
WHEN 'BACK'. CLEAR OK_CODE2. SET SCREEN 100. LEAVE SCREEN.
ENDCASE.
ENDMODULE. " EXIT_COMMAND_200 INPUT
*&---------------------------------------------------------------------*
*& Module STATUS_0200 OUTPUT
*&---------------------------------------------------------------------*
* process before output for screen 200 *
*----------------------------------------------------------------------*
MODULE STATUS_0200 OUTPUT.
SET PF-STATUS 'POPUP'.
* SET TITLEBAR 'xxx'.

ENDMODULE. " STATUS_0200 OUTPUT

award points if helpful..

[Former Member]

Hi,

Module pool programs are also called dialog programs.

The module Pool are reports prepared for different screens and to manage the sequeence of events of these screens, in the transaction SE80 you can see all the dynpros that you have for this kind of report, add new ones, add all types of element to the report.

Process Before Output is the part of the dynpro code that is precessed before the user can do anithing with the data in the screen

Process After Input is the part of the dynpro code that is preocessed after the interaction with the user.

module pool programs are excuited using Transaction codes

ABAP program with the program type 'M'.

In the Object Browser, the module pool code belongs to one of the following categories:

Global fields: data declarations that can be used by all modules in the module pool

PBO modules: modules that are called before displaying the screen

PAI modules: modules that are called in response to the user input

Subroutines: subroutines that can be called from any position within the module pool ,

Screens are the most general type of user dialog that you can use in ABAP programs. You do not define them in ABAP programs, but instead in the Screen Painter. A screen consists of the input/output mask and the flow logic. You can define screens for any program with type 1, M, or F.

The screens in a single ABAP program can be combined to form screen sequences. You can call single screens or screen sequences either using a transaction code from outside the ABAP program, or by using the CALL SCREEN statement in the corresponding ABAP program. When you call a screen or screen sequence, the screen flow logic takes control of the ABAP program execution. You can define screen sequences dynamically by setting the next screen attribute for a screen dynamically in the ABAP program.

A screen consists of the input/output mask and the flow logic. The screen flow logic is divided into the Process Before Output (PBO) event, which is processed before the screen is displayed, and the Process After Input (PAI) event, which is processed after a user action on the screen.

The following diagram shows the place of screens between the GUI status and the ABAP program:

The screen flow logic calls dialog modules in the ABAP program, either to prepare the screen for display (PBO event) or to process the user's entries (PAI event). Screens are dynamic programs, and have their own data objects, called screen fields. These are linked to the input/output fields that appear on the screen itself. When the screen is displayed, and when it finishes processing, the system passes data between the screen fields and data objects in the ABAP program. Data is copied between identically-named fields.

Each screen has a GUI status, containing a menu bar, standard toolbar, and an application toolbar. Like screens, GUI statuses are independent components of the ABAP program. You create them in the ABAP Workbench using the Menu Painter. You assign GUI statuses to screens dynamically in your ABAP programs. Each screen is linked to the current GUI status by a special screen field into which the corresponding function code is placed whenever the user chooses a function. The screen passes the function code to the ABAP program just like any other screen field. You can then read it in the program.

Screen Attributes

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.

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.

Screen Attributes

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.

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.

http://www.geocities.com/ZSAPcHAT

http://abapcode.blogspot.com/search/label/Dialog%20Programs

[Former Member]

Hi

Module pool programs are created in abap development work bench (TCODE: SE80).

Here we can do all the works whatever you can do in abap.

Module pool programs are also called dialog programs.

The module Pool are reports prepared for different screens and to manage the sequence of events of these screens, in the transaction SE80 you can see all the dynpros that you have for this kind of report, add new ones, add all types of element to the report.

Process Before Output is the part of the dynpro code that is processed before the user can do anything with the data in the screen

Process After Input is the part of the dynpro code that is processed after the interaction with the user.

module pool programs are excuted using Tcodes

Also plz refer::

http://sap.mis.cmich.edu/sap-abap/abap09/sld011.htm

Thanks

Mohinder Singh Chauhan

[Former Member]

Hi,

Module Pools

Module pools are directly created using the ABAP Editor and are introduced with the PROGRAM statement. With the exception of reporting event blocks and function modules, module pools can contain all processing blocks supported in ABAP and as many local classes as required. While they are executed, all events of the ABAP runtime environment may be triggered.

The most important technical attribute of a module pool is that it can only be controlled using screen flow logic. You must start them using a transaction code, which is linked to the program and one of its screens (initial screen). Another feature of these programs is that you must define your own screens in the Screen Painter (although the initial screen can be a selection screen).

When you start a program using a transaction code, the runtime environment starts a processor that calls the initial screen. This then calls a dialog module in the corresponding ABAP program. The remainder of the program flow can take any form. For example, the dialog module can:

· return control to the screen, after which the processing passes to a subsequent screen. Each screen has a following screen, set either statically or dynamically. Screens and their subsequent screens are components of freely definable screen sequences.

· call other screen sequences, selection screens or lists, from which further processing blocks in the ABAP program are started.

· call other processing blocks itself, either internally or externally.

· call other application programs using CALL TRANSACTION or SUBMIT.

It is appropriate to use module pools when you write dialog-oriented programs using a large number of screens whose flow logic largely determines the program flow of screen sequences.

Regards,

Renjith Michael.

http://www.sourceveda.com/

[Former Member]

hi,

To allow a module pool to be executed, you must assign a transaction code to it.

You assign a dialog transaction to a module pool. The following steps occur when you run a dialog

transaction:

First, the LOAD-OF-PROGRAM event is triggered. Once this event block has been executed, the ABAP

processor passes control to the screen processor. For an example of how to use this new event, refer to

the example in the Function Groups and Function Modules unit.

The screen processor processes the intial screen specified in the transaction definition. The initial

screen can be a selection screen (regardless of the program type).

The PROCESS BEFORE OUTPUT

event is triggered and control passes to the ABAP processor, which processes the first PBO module.

The ABAP processor executes the processing block and returns control to the screen processor. Once

all PBO modules have been processed, the contents of any

ABAP fields with identically-named

corresponding fields on the screen are transported to the relevant screen fields. Then the screen is

displayed (screen contents, active title, active status).

Once the user has chosen a dialog function (such as ENTER), the contents of the screen fields are

transported back to the corresponding identically-named fields in the ABAP program, and the processing

blocks that belong to the PROCESS AFTER INPUT event are processed. The system then continues

by processing the next screen.

The only processing logic that is processed in a dialog transaction are the statements belonging to the

LOAD-OF-PROGRAM event and those occurring in the various modules.

However, you can also use the statement LEAVE TO LIST-PROCESSING. This makes all of the list

processing events available to you.

Hope this helps, Do reward.