MODULE REQUEST

[Former Member]

DIFF B/W MODULE ON REQUEST AND MODULE ON INPUT......

[Former Member]

HI Nisha..

You can ensure that a PAI module is only called when a

certain condition applies by using the following

statement:

<b>FIELD <f> MODULE <mod> ON INPUT|REQUEST|*-INPUT.</b>

The additions have the following effects:

<b>ON INPUT</b>

The ABAP module is called only if the field contains a

value other than its initial value. This initial value is

determined by the data type of the field: Space for

character fields, zero for numeric fields. Even if the

user enters the initial value of the screen as the

initial value, the module is not called. (ON REQUEST, on

the other hand, does trigger the call in this case.)

<b>ON REQUEST</b>

The module <mod> is only called if the user has entered

something in the field. This includes cases when the user

overwrites an existing value with the same value, or

explicitly enters the initial value.

In general, the <b>ON REQUEST</b> condition is triggered

through any form of "manual input". As well as user

input, the following additional methods of entering

values also call the module:

The element attribute PARAMETER-ID (SPA/GPA parameters).

The element attribute HOLD DATA

CALL TRANSACTION ... USING

Automatic settings of particular global fields

ON *-INPUT

The ABAP module is called if the user has entered a "*"

in the first character of the field, and the field has

the attribute *-entry in the Screen Painter. When the

input field is passed to the program, the * is removed. *

behaves like an initial field in the ON INPUT condition.

if it helps Reward with Points..

Regards,

Rk

null

[Former Member]

sorry u r wrong we tried it out......

[Former Member]

Hi,

What exactly u want nisha ?

Could u explain ur question in detail ?

<b>Just click on the link that I had provided(in above posts).OK.</b>

Message was edited by:

Raghavender Vadakattu

[Former Member]

hi,

MODULE mod [ AT {EXIT-COMMAND|CURSOR-SELECTION} ]

[ ON {CHAIN-INPUT|CHAIN-REQUEST} ]

[ SWITCH switch ].

1. ... AT EXIT-COMMAND

2. ... AT CURSOR-SELECTION

3. ... ON {CHAIN-INPUT|CHAIN-REQUEST}

4. ... SWITCH switch

Effect

The statement MODULE of the dynpro flow logic calls the dialog module mod of the ABAP program. You can use MODULE either as a keyword or as an addition of statement FIELD. When using it as an addition, the call of the dialog module depends on conditions for the screen fields.

As a keyword, the statement calls the dialog module mod of the respective ABAP program. At the event PAI, you can use the additions AT and ON to specify conditions for the call of the dialog module.

At the event PBO, you can call any dialog module defined in the ABAP program with the addition OUTPUT. At the events PAI, POH and POV, you can call any dialog module defined with the addition INPUT or without any addition. If the dialog module mod does not exist in the ABAP program, an untreatable exception is triggered. After processing a dialog module in the ABAP program, processing of the dynpro flow logic is resumed after the position of the call, unless the screen processing is completed within the dialog module.

You can use MODULE as a keyword only at the events PBO and PAI. At the events POH and POV, you can use MODULE only as an addition to the FIELD statement.

Note

Do not mix up the MODULE statement of the dynpro flow logic with the identically called statement MODULE for defining dialog modules in the ABAP program.

... AT EXIT-COMMAND

Addition AT EXIT-COMMAND at the event PAI causes module mod to be called exactly if:

The function used to trigger event PAI has function type "E"

Into the input field of the standard toolbar, the user entered a character string starting with "E" and confirmed it using ENTER.

The dialog module is called before the automatic input checks defined in the system or in the ABAP Dictionary and independent of its position in the event block. The only screen field transported to the ABAP program is the OK field. If the function that triggered the PAI event does not fulfill any of the above prerequisites, the MODULE statement is not executed.

If several MODULE statements have the AT EXIT COMMAND addition, only the first one is executed. If no MODULE statement has the addition AT EXIT COMMAND, a normal PAI processing is executed: The predefined input checks are executed and then the PAI event block is processed sequentially. Provided the screen processing is not terminated in the dialog module mod, after the return from the dialog module, the complete PAI processing is executed. You must not use the addition AT EXIT COMMAND in connection with the statement FIELD.

Note

The function type of a function is determined in the Screen Painter or Menu Painter. Usually those functions of the user interface are defined with function type "E" that are assigned to the icons Back, Exit and Cancel in the standard toolbar of the GUI status. Therefore, the called dialog module should terminate the screen processing and allow security checks, if required.

... AT CURSOR-SELECTION

The AT CURSOR-SELECTION addition at the event PAI causes the module mod to be called only if

The function used to trigger event PAI has function code "CS" and function type "S"

The cursor is placed on a single input or output field of the screen at the moment of the user action

The call occurs within the usual PAI processing, meaning that the automatic input checks defined in the system or in the ABAP Dictionary are executed and the MODULE statement is called according to its position in the event block. You can use the addition in connection with the FIELD statement.

If the PAI event is triggered under the above circumstances, the function code is not passed to sy-ucomm and the OK field. They keep their previous values.

Note

The function type and function code of a function are determined in the Screen Painter or in the Menu Painter. We recommend to assign function code "CS" in the Menu Painter to function key F2 in order to simultaneously assign the double-click function of the mouse to it. This allows you to assign dialog modules to the selection of input or output fields.

... ON {CHAIN-INPUT|CHAIN-REQUEST}

These conditions make sense only within chains using the CHAIN and ENDCHAIN statements. They check the individual conditions ON INPUT or ON REQUEST for all screen fields that are specified so far within the current chain after FIELD. The dialog module is called if at least on of the screen fields fulfills the respective condition.

...SWITCH switch

If the addition SWITCH is specified, the dialog module mod is called only if the switch specified by switch has the state on.

With switch, a switch defined in the Repository must be specified directly. If the specified switch does not exist, the dialog module will not be called.

You cannot specify the addition together with the statement FIELD. There, the switch assigned to the screen field in the Screen Painter applies.

Example

PROCESS BEFORE OUTPUT.

MODULE status_0100.

PROCESS AFTER INPUT.

MODULE leave_100 AT EXIT-COMMAND.

MODULE user_command_0100.

The relevant ABAP program must implement the dialog modules and may have a structure like the one below. Because dialog module have no local data, we recommend to handle the actual processing within procedures that you call depending on the function code.

DATA: ok_code TYPE sy-ucomm,

...

MODULE status_0100 OUTPUT.

SET PF-STATUS 'STATUS_0100'.

ENDMODULE.

MODULE leave_100 INPUT.

CASE ok_code.

WHEN 'BACK'.

...

WHEN 'CANCEL'.

...

WHEN 'EXIT'.

LEAVE PROGRAM.

...

ENDCASE.

ENDMODULE.

MODULE user_command_0100 INPUT.

CASE ok_code.

WHEN ...

CALL ...

...

ENDCASE.

ENDMODULE.

Regards

Gaurav

[Former Member]

MODULE

Syntax

MODULE mod {OUTPUT|[INPUT]}.

...

ENDMODULE.

Addition:

... OUTPUT|[INPUT]

Effect

The MODULE statement defines a mod dialog module. The naming conventions apply to the name mod. The functionality of a mod dialog module is implemented between the MODULE ad ENDMODULE statements.

A dialog module is called using the MODULE statement with the same name of the dynpro flow logic of any ABAP program dynpro.

Addition

... OUTPUT|[INPUT]

Effect

The OUTPUT and INPUT additions determine whether the dialog module can be called for the PBO event or for the PAI event. The INPUT addition is the default and can therefore also be omitted, although this is not recommended for the readability of the program. Two dialog modules with the same name can be defined in a program, if one of them has the OUTPUT addition and the other has the INPUT addition, which is not recommended again for reasons of readability.

Note

For data encapsulation reasons, it is recommended that you implement little functionality in dialog modules, and that you call procedures instead.

Conditional Module Calls

Simple module calls are processed in the sequence in which they appear in the screen flow logic. However, the syntax of the screen language also allows you to make PAI module calls dependent on certain conditions by using the MODULE statement together with the FIELD statement. You can apply conditions to both single fields and groups of fields. Conditional module calls can help you to reduce the runtime of your program, particularly with modules that communicate with database tables.

Conditions for Single Screen Fields

You can ensure that a PAI module is only called when a certain condition applies by using the following statement:

FIELD <f> MODULE <mod> ON INPUT|REQUEST|*-INPUT.

The additions have the following effects:

ON INPUT

The ABAP module is called only if the field contains a value other than its initial value. This initial value is determined by the data type of the field: Space for character fields, zero for numeric fields. Even if the user enters the initial value of the screen as the initial value, the module is not called. (ON REQUEST, on the other hand, does trigger the call in this case.)

ON REQUEST

The module <mod> is only called if the user has entered something in the field. This includes cases when the user overwrites an existing value with the same value, or explicitly enters the initial value.

In general, the ON REQUEST condition is triggered through any form of "manual input". As well as user input, the following additional methods of entering values also call the module:

The element attribute PARAMETER-ID (SPA/GPA parameters).

The element attribute HOLD DATA

CALL TRANSACTION ... USING

Automatic settings of particular global fields

ON *-INPUT

The ABAP module is called if the user has entered a "*" in the first character of the field, and the field has the attribute *-entry in the Screen Painter. When the input field is passed to the program, the * is removed. * behaves like an initial field in the ON INPUT condition.

The functions of the FIELD statement for controlling data transport also apply when you use MODULE.

Conditions for Multiple Screen Fields

To ensure that one or more PAI modules are only called when several screen fields meet a particular condition, you must combine the calls in the flow logic to form a processing chain. You define processing chains as follows:

CHAIN.

...

ENDCHAIN.

All flow logic statements between CHAIN and ENDCHAIN belong to a processing chain. The fields in the various FIELD statements are combined, and can be used in shared conditions.

CHAIN.

FIELD: <f1>, <f 2>,...

MODULE <mod1> ON CHAIN-INPUT|CHAIN-REQUEST.

FIELD: <g1>, <g 2>,...

MODULE <mod2> ON CHAIN-INPUT|CHAIN-REQUEST.

...

ENDCHAIN.

The additions ON CHAIN-INPUT and ON CHAIN-REQUEST work like the additions ON INPUT and ON REQUEST that you use for individual fields. The exception is that the module is called whenever at least one of the fields listed in a preceding FIELD statement within the chain meets the condition. So <mod1> is called when one of the fields <fi> meets the condition. <mod2> is called when one of the fields <f i> or <g i> meets the condition.

Within a processing chain, you can combine individual FIELD statements with a MODULE statement to set a condition for a single field within the chain:

CHAIN.

FIELD: <f1>, <f 2>,...

FIELD <f> MODULE <mod1> ON INPUT|REQUEST|*-INPUT

|CHAIN-INPUT|CHAIN-REQUEST.

MODULE <mod2> ON CHAIN-INPUT|CHAIN-REQUEST.

ENDCHAIN.

The module <mod1> is called when screen field <f> meets the specified condition for individual fields. <mod2> is called when one of the fields <fi> or <f> meets the condition. If you use the addition ON CHAIN-INPUT or ON CHAIN-REQUEST with FIELD <f>, the condition also applies to the entire chain and module <mod1> and <mod2> are both called.

In cases where you apply conditions to various combinations of screen fields, it is worth setting up a separate processing chain for each combination and calling different modules from within it.

The functions of the FIELD statement for controlling data transport also apply when you use processing chains. Within a processing chain, screen fields are not transported until the FIELD statement. Processing chains also have another function for the FIELDS statements that they contain. This is described in the section on validity checks.

Calling Modules after Cursor Selection

You can specify that a module should only be called if the cursor is positioned on a particular screen element. To do this, use the statement

MODULE <mod> AT CURSOR-SELECTION.

The module <mod> is called whenever the function code of the user action is CS with function type S. If you use this statement, it is best to assign the function code CS to function key F2. This also assigns it to the mouse double-click.

The module is called in the sequence in which it occurs in the flow logic. It does not bypass the automatic input checks. Data is transported from screen fields in the order in which it is defined by the FIELD statements. The function code is empty, and neither SY-UCOMM nor the OK_CODE field is affected. You can also combine this MODULE statement with the FIELD statement:

FIELD <f> MODULE <mod> AT CURSOR-SELECTION.

or, for more than one field:

CHAIN.

FIELD: <f1>, <f 2>,...

MODULE <mod> AT CURSOR-SELECTION.

ENDCHAIN.

The module <mod> is only called if the cursor is positioned on an input/output field <f> or an input/output field <fi> in the processing chain. You can only apply this statement to input/output fields.

The call hierarchy of the different combinations is as follows:

If a MODULE... AT CURSOR-SELECTION statement is executed that was combined with FIELD, a statement without FIELD is not executed.

If a statement using FIELD appears more than once for the same screen field <f>, only the first statement is executed.

If a statement without FIELD occurs more than once, only the last statement is executed.

It is irrelevant whether the statements occur within a CHAIN ... ENDCHAIN block or not.

Conditional module calls

PROGRAM DEMO_DYNPRO_ON_CONDITION.

DATA: OK_CODE LIKE SY-UCOMM,

INPUT1(20), INPUT2(20), INPUT3(20),

FLD(20).

CALL SCREEN 100.

MODULE INIT_SCREEN_100 OUTPUT.

SET PF-STATUS 'STATUS_100'.

ENDMODULE.

MODULE CANCEL INPUT.

LEAVE PROGRAM.

ENDMODULE.

MODULE CURSOR INPUT.

GET CURSOR FIELD FLD.

MESSAGE I888(BCTRAIN) WITH TEXT-001 FLD.

ENDMODULE.

MODULE MODULE_1 INPUT.

MESSAGE I888(BCTRAIN) WITH TEXT-002.

ENDMODULE.

MODULE MODULE_2 INPUT.

MESSAGE I888(BCTRAIN) WITH TEXT-003.

ENDMODULE.

MODULE MODULE_* INPUT.

MESSAGE I888(BCTRAIN) WITH TEXT-004 INPUT3.

ENDMODULE.

MODULE C1 INPUT.

MESSAGE I888(BCTRAIN) WITH TEXT-005 '1'.

ENDMODULE.

MODULE C2 INPUT.

MESSAGE I888(BCTRAIN) WITH TEXT-005 '2' TEXT-006 '3'.

ENDMODULE.

The next screen (statically defined) for screen 100 is itself. It has the following layout:

The screen fields INPUT1, INPUT2, and INPUT3 are assigned to the input fields. The function code of the pushbutton is EXECUTE.

In the GUI status STATUS_100, the icon (F12) is active with function code CANCEL and function type E. The function key F2 is also active with function code CS and function type S. The F8 key is active with the function code EXECUTE and no special function type.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.

MODULE INIT_SCREEN_100.

PROCESS AFTER INPUT.

MODULE CANCEL AT EXIT-COMMAND.

CHAIN.

FIELD: INPUT1, INPUT2.

MODULE MODULE_1 ON CHAIN-INPUT.

FIELD INPUT3 MODULE MODULE_* ON *-INPUT.

MODULE MODULE_2 ON CHAIN-REQUEST.

ENDCHAIN.

FIELD INPUT1 MODULE C1 AT CURSOR-SELECTION.

CHAIN.

FIELD: INPUT2, INPUT3.

MODULE C2 AT CURSOR-SELECTION.

ENDCHAIN.

MODULE CURSOR AT CURSOR-SELECTION.

The program uses information messages to show which modules are called following user interaction and which data is transported.

Whenever one of the input fields 1 or 2 is not initial, the system calls the module MODULE_1 for any user interaction.

Whenever one of the three input fields is changed, the system calls the module MODULE_2 for any user interaction.

Whenever input field 3 contains a * entry, the system calls module MODULE_* for any user interaction.

If the user chooses F2 or double-clicks a text field on the screen, the system calls the module CURSOR.

If the user chooses F2 or double-clicks input field 1, the system calls the module C1.

If the user chooses F2 or double-clicks input field 2 or 3, the system calls the module CURSOR. Module C2 is never executed, since the MODULE ... AT CURSOR SELECTION statement occurs twice, and only the last is processed.

[Former Member]

<b>Hi Nisha,</b>

Just Click on the below..........

http://www.esnips.com/doc/b7f68c8e-3563-404f-bdd8-11e33b54ae46/INPUT_FIELD-HELP

Reward,if helpful to you.

Message was edited by:

Raghavender Vadakattu