Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

When error comes in table control

Former Member
0 Likes
1,125

Hi,

When user enters the wrong data in the table control then automatically table control will throw an error for that line, if user not sure about that error and he wants to delete the errored line then there is a flexibility to select the number of lines and delete. But when he gets an error he could not able to even select the line to delete till he rectify the error in the table control / clear all the mandatory fields in the table control for that line.

Do you have any solution on this.

Regards,

Jaya

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
643

Write your Module with in Chain...End chain.

The statements CHAIN and ENDCHAIN of the dynpro flow logic define processing chains. Between CHAIN and ENDCHAIN, the statements FIELD and MODULE can be executed. The statements between CHAIN and ENDCHAIN form a processing chain. Processing chains cannot be nested. The CHAIN statement can be specified in the event blocks at PAI and PBO , however, in the event block at PBO it has no effect.

A processing chain allows the joint processing of all the screen fields stated between CHAIN and ENDCHAIN after FIELD statements:

The contents of all screen fields combined to a processing chain by the FIELD statements can be checked in the shared conditions ON CHAIN-INPUT and ON CHAIN-REQUEST of the MODULE statement.

A warning or error message in a module called within a processing chain resets all input fields whose screen fields are combined in this processing chain using FIELD statements to ready-for-input. After a user input, the PAI processing resumes at the CHAIN statement at the latest.

Example

Call dialog modules to check input values. The screen fields input1 and input2 are checked in individual dialog modules check_1 and check_2. The screen fields input3 to input5 are checked in a processing chain in a shared dialog module check_chain. Warning or error messages in the dialog modules either make only one input field input1 or input2 ready for input again or all three input fields input3 to input5.

PROCESS AFTER INPUT.

MODULE leave_dynpro AT EXIT-COMMAND.

FIELD input1 MODULE check_1 ON REQUEST.

FIELD input2 MODULE check_2 ON REQUEST.

CHAIN.

FIELD input3.

FIELD input4.

FIELD input5.

MODULE check_chain ON CHAIN-REQUEST.

ENDCHAIN.

MODULE handle_user_command.

Hope this helps

Vinodh Balakrishnan

2 REPLIES 2
Read only

Former Member
0 Likes
644

Write your Module with in Chain...End chain.

The statements CHAIN and ENDCHAIN of the dynpro flow logic define processing chains. Between CHAIN and ENDCHAIN, the statements FIELD and MODULE can be executed. The statements between CHAIN and ENDCHAIN form a processing chain. Processing chains cannot be nested. The CHAIN statement can be specified in the event blocks at PAI and PBO , however, in the event block at PBO it has no effect.

A processing chain allows the joint processing of all the screen fields stated between CHAIN and ENDCHAIN after FIELD statements:

The contents of all screen fields combined to a processing chain by the FIELD statements can be checked in the shared conditions ON CHAIN-INPUT and ON CHAIN-REQUEST of the MODULE statement.

A warning or error message in a module called within a processing chain resets all input fields whose screen fields are combined in this processing chain using FIELD statements to ready-for-input. After a user input, the PAI processing resumes at the CHAIN statement at the latest.

Example

Call dialog modules to check input values. The screen fields input1 and input2 are checked in individual dialog modules check_1 and check_2. The screen fields input3 to input5 are checked in a processing chain in a shared dialog module check_chain. Warning or error messages in the dialog modules either make only one input field input1 or input2 ready for input again or all three input fields input3 to input5.

PROCESS AFTER INPUT.

MODULE leave_dynpro AT EXIT-COMMAND.

FIELD input1 MODULE check_1 ON REQUEST.

FIELD input2 MODULE check_2 ON REQUEST.

CHAIN.

FIELD input3.

FIELD input4.

FIELD input5.

MODULE check_chain ON CHAIN-REQUEST.

ENDCHAIN.

MODULE handle_user_command.

Hope this helps

Vinodh Balakrishnan

Read only

Former Member
0 Likes
643

got my own