Hi ,

I created a module pool Program , I hav taken one parameter ..

How to do the validation for this paramater in screen .
And if Im taking a set of parameter - how to do the validation ..

Regards,
Narender

Subbu Re: validation in Reply

P Module pool
Program
Posts: 1,709 Posted: Jan 12, 2007
3:15 AM in
Registered: 4/29/05
Forum Points: 2,792 response to: Narender B

Hi,
Do the validation in the CHAIN...ENDCHAIN stmt.

Regards
Subramanian

Narender Re: validation in Reply

B Module pool
Program
Posted: Jan 12, 2007
Posts: 23
3:48 AM in
Registered: 9/18/06
Forum Points: 2 response to: Subbu P

hi Subramanian ,

Chain Endchain is used for a set of parameter , Just I want to

validate a single parameter ...

Regards,
Narender

muralikrishna Re: validation in Reply

k... Module pool
Program
Posts: 2,431 Posted: Jan 12, 2007
4:00 AM in
Registered: 9/11/06
Forum Points: 3,684 response to: Narender B

Naren,

Use FIELD field name MODULE MODULE_3.

Pls. Mark if useful.

Lindsay Re: Reply
Hoare validation
in Module
Posts: 16 pool
Registered: 5/26/05 Program
Forum Points: 36
Posted: Jan 12,
2007 4:02 AM
in response
to: Narender B

Hi, you just need to put a validation module in the PAI in the screen
flow logic. eg if your field is zzz-field1, use a statement in the PAI like
this:

FIELD ZZZ-FIELD1 MODULE VALIDATE_FIELD1.

or, to only process conditionally, use

FIELD ZZZ-FIELD1 MODULE VALIDATE_FIELD1 ON INPUT
or
FIELD ZZZ-FIELD1 MODULE VALIDATE_FIELD1 ON
REQUEST.

if your module then generates an error message this field will be

highlighted for action.

if you have several fields you need to chain them eg ZZZ-FIELD1 and
ZZZ-FIELD2:

CHAIN.
FIELD: ZZZ-FIELD1, ZZZ-FIELD2.
MODULE VALIDATE_FIELDS ON CHAIN-INPUT " (or ON
CHAIN-REQUEST)
ENDCHAIN.

Satya Re: validation in Reply

Priya Module pool
Vep... Program
Posted: Jan 12, 2007
4:02 AM in
Posts: 307
response to: Narender B
Registered: 5/13/06
Forum Points: 412 Hi Narender,
U need to do the validation in PAI event of the screen as below :

PROCESS AFTER INPUT.

MODULE user_command_0100.
*** input check for field cvp number
 FIELD : cvp_no. "Screen Field needs to be validated
MODULE show_cv_desc.

And the module definition is as follows :

MODULE show_cv_desc INPUT.

ws_repid = sy-cprog.
ws_num = '1000'.
i_dynfields-fieldname = 'CVP_NO'.
APPEND i_dynfields.

CALL FUNCTION 'DYNP_VALUES_READ'

EXPORTING
dyname = ws_repid
dynumb = ws_num
TABLES
dynpfields = i_dynfields
EXCEPTIONS
invalid_abapworkarea = 1
invalid_dynprofield = 2
invalid_dynproname = 3
invalid_dynpronummer = 4
invalid_request = 5
no_fielddescription = 6
invalid_parameter = 7
undefind_error = 8
double_conversion = 9
stepl_not_found = 10
OTHERS = 11.
IF sy-subrc EQ 0.
READ TABLE i_dynfields WITH KEY fieldname = 'CVP_NO'.
IF sy-subrc EQ 0.
cvp_no = i_dynfields-fieldvalue.
ENDIF.
ENDIF.
***********Validation
if cvp_no = '0013'.
message e000(zocm) with 'Wrong Entry'. " If the user enters 0013 for
cvp_no endif.
ENDMODULE. " show_cv_desc INPUT

Please do reward helpful answers.

Gopi Re: validation in Reply

Narendra Module pool
Program
Posts: 2,063 Posted: Jan 12, 2007
4:29 AM in
Registered: 5/22/06
Forum Points: 3,712 response to: Narender B

in the PAI..

module check_data.
select single * from <table>
where <tablefield> = <screenfield-value>.
if sy-subrc = 0.
else.
message E000(00) with '<ScreenField-Value> does not exit'.
endif.
endmodule.

in the flow logic for the screen. write as

chain.
field : <screenfield>.
module check_data.
endchain.

Regards
Gopi

Jayanthi Re: validation in Reply

Jayara... Module pool
Program
Posts: 3,763 Posted: Jan 12, 2007
4:35 AM in
Registered: 2/24/05
Forum Points: 5,420 response to: Narender B

Hi,

In PAI,

FIELD fieldname MODULE validate.

MODULE validate INPUT.

..do the validation here....

ENDMODULE. "Validate INPUT

Shiba Re: validation in Reply

Prasad Module pool
Du... Program
Posted: Jan 12, 2007
5:10 AM in
Posts: 2,911
response to: Narender B
Registered: 11/25/06
Forum Points: 5,492 in PAI you have to validate the field.

FIELD f1 MODULE m1 ON REQUEST.

things in sqare bracket are optional [].

in abap editor it will show

MODULE m1 input.
<do validation code>.
ENDMODULE.

regards
shiba dutta

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.

http://help.sap.com/saphelp_47x200/helpdata/en/d1/801ca2454211d189710000e8322d00/frameset.h
tm

Flow Logic Keywords

You define the flow logic in the flow logic editor of the Screen Painter, using the following keywords:

Keyword Description
CALL Calls a subscreen.
CHAIN Starts a processing chain.
ENDCHAIN Ends a processing chain.
ENDLOOP Ends loop processing.
FIELD Refers to a field. You can combine this with the MODULE and SELECT
keywords.
LOOP Starts loop processing.
MODIFY Modifies a table.
MODULE Identifies a processing module.
ON Used with FIELD assignments.
PROCESS Defines a processing event.
SELECT Checks an entry against a table.
VALUES Defines allowed input values.

For more information about transaction programming, see the ABAP User’s Guide

Example of Flow Logic Example

The following example shows some use of screen flow logic:

*------------------------------------------------

* Sample Code

*---------------------------------------------------

*Processing Before Screen Output

PROCESS BEFORE OUTPUT.

MODULE INIT_FIELDS.
* Self-programmed F1 Help

PROCESS ON HELP-REQUEST.

FIELD GSSG-BUKRG MODULE V-BUKRG.

* Processing after user input

PROCESS AFTER INPUT.

* Lock customer master record

CHAIN.

FIELD GSSG-KTNRG

MODULE ENQUEUE_CUSTOMER_MASTER.

* Read customer master record

MODULE READ_CUSTOMER_MASTER.

* Read business area

MODULE READ_GSSG.

ENDCHAIN.

* Process function code

FIELD OK-CODE MODULE OKCODE ON INPUT.