module pool

[Former Member]

hi,

can any one please explain what is module pool , what is the purpose and steps to how to create a sample module pool program as i am a fresher please explain with steps to create a module pool.

please dont say to refer the links.

thanks in advance.

[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.

Thanx

bgan.

[Former Member]

The module pool consists of modularized ABAP/4 syntax which is placed inside include programs belonging to the dialog program.

These modules are invoked when called upon by flow logic.

Processing of flow logic and ABAP/4 modules is handled by different processors in the SAP system.

Flow logic is processed by the dialog processor while all ABAP/4 is processed by the ABAP/4 processor.

The ABAP/4 module pool consists of the following components:

The main program which will contain a series of include programs. Customer dialog programs should begin with SAPMZ or SAPMY.

Global data declarations in the form of a top include program. The program is named with the last five characters of the main program followed by ‘TOP’ (for TOP include). All data declarations will be placed within this program during development.

For modularization purposes, remaining ABAP/4 is developed using the following structure of include programs:

A PBO module include program is created to hold modules invoked by the PBO event of any of the screens in the dialog program. A PAI module include program is created to hold modules invoked by the PAI event of any of the screens in the dialog program. The proper naming convention uses the last five characters of the main program followed by either ‘O’ for PBO modules or ‘I’ for PAI modules, ending with a sequential number beginning with ‘01’. All PBO and PAI modules are placed inside their respective include program until the need for further modularization arises at which point a new include can be created using the next number in the sequence.

If further modularization is required a forms include program is created for subroutines name with the last 5 characters of the main program followed by ‘F’ for forms followed by a sequential number beginning with ‘01’.

Unlike report, interface, and 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 program.

Dialog programs are composed of the following main components:

Screens

Module pool

Subroutines

Menus/GUI statuses

Transaction codes

Screens are made up of the following components:

Screen attributes

Screen layout/screen elements

Fields

Flow logic

Flow logic is comprised of two events:

The process before output (PBO) event invokes any processing which is to occur before the screen is displayed to the user.

The process after input (PAI) event invokes any processing which is to occur after the user has completed interaction with the screen by invoking any one of the possible functions (I.E. Save, back, enter, etc.).

SAPMDEMO_TRANSACTION in SE80 Transaction

http://www.geocities.com/ZSAPcHAT

[Former Member]

Hi

u can find here

Checklist for simpe dialog program

Create the program

Create a new program in the repository browser (Transaction SE80) . Name standard for dialog programs is SAPMZ

In the attributes window:

- Module pool = M

- Application = Z

Create the screen

Create a new screen.

Add a pushbutton to the screen

In the attributes screen for the pushbutton, enter a function code

in the FctCode field ( In this example: 0020 ).

When you create a screen, SAP automathic creates a field with the type OK. The function code of the psuhbutton will be placed here when you push the button. However you have to supply the name of the OK field ( In this example: OK_CODE ).

You must also create a global variable in the program, to store the value of the OK field ( See below ).

Create global variables

DATA:

• Global variable to store OK code

ok_code(4),

• Temporary store the value of the OK code

save_ok_code(4).

Create code for the screen

PROCESS BEFORE OUTPUT.

MODULE status_0001.

PROCESS AFTER INPUT.

MODULE user_command_0001.

MODULE status_0001 OUTPUT.

SET PF-STATUS '0001'.

SET TITLEBAR '001'.

• Example of how deactivate a field on the screen

• ZCOSTAFSTM-ZAFSTEMNR is the name of the screen field we want to

• deactivate.

LOOP AT SCREEN.

CHECK screen-name = 'ZCOSTAFSTM-ZAFSTEMNR'.

screen-input = '0'.

MODIFY SCREEN.

ENDLOOP.

ENDIF.

ENDMODULE.

MODULE user_command_0001 INPUT.

• Here you can catch when user pushes a pushbutton

• Save the OK code in save_ok_code and clear it

save_ok_code = ok_code.

CLEAR ok_code.

CASE save_ok_code.

WHEN '0010'.

• Afstemninger

LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN 0.

PERFORM my_list.

WHEN '0020'.

CALL TRANSACTION 'ZCO1'.

WHEN 'RETU'.

LEAVE TO SCREEN '0000'.

ENDCASE.

ENDMODULE.

AT USER-COMMAND.

• Here you can catch when the user psuh a button on the menu bar or presses a function key

CASE sy-ucomm.

WHEN 'OPRT'.

PERFORM something.

ENDCASE.

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

Regards