doublt in pbo,pai

[Former Member]

hai,

what is meant by pbo, pbi ,process on help-request, process on value-request.?

plz tell with simple example for each event?

regards

surender

[Former Member]

Hi,

In any processing the normal flow is

PBO

Screen

PAI

first PBO will come then Screen and then PAI. The data details which you want to show already on screen will come PBO.

Any modifications on screen will be coded under PAI.

POH

Calling Help Texts from Dialog Modules

If data element supplement documentation is insufficient for your requirements, or you want to display help for program fields that you have not copied from the ABAP Dictionary, you can call dialog modules in the POH event:

PROCESS ON HELP-REQUEST.

...

FIELD <f> MODULE <mod>.

...

After the PROCESS ON HELP-REQUEST statement, you can only use the MODULE statement together with the FIELD statement. When the user chooses F1 for a field <f>, the system calls the module <mod> belonging to the FIELD <f> statement. If there is more than one FIELD statement for the same field <f>, only the first is executed. However, the contents of the screen field <f> are not available in the module <mod>, since it is not transported by the FIELD statement during the PROCESS ON HELP-REQUEST event. The field help should not be dependent on the user input.

The module <mod> is defined in the ABAP program like a normal PAI module. The processing logic of the module must ensure that adequate help is displayed for the field in question. Instead of calling an extra screen with text fields, you should use one of the following function modules to display a suitable SAPscript document:

• HELP_OBJECT_SHOW_FOR_FIELD

This function module displays the data element documentation for components of any structure or database table from the ABAP Dictionary. You pass the name of the component and structure or table to the import parameters FIELD and TABLE.

• HELP_OBJECT_SHOW

Use this function module to display any SAPscript document. You must pass the document class (for example, TX for general texts, DE for data element documentation) and the name of the document to the import parameters DOKCLASS and DOKNAME. For technical reasons, you must also pass an empty internal table with the line type TLINE to the tables parameter of the function module.

For further information about how to create SAPscript documents, refer to the Structure link Documentation of System Objects documentation.

Example

Field help on screens.

REPORT DEMO_DYNPRO_F1_HELP.

DATA: TEXT(30),

VAR(4),

INT TYPE I,

LINKS TYPE TABLE OF TLINE,

FIELD3, FIELD4.

TABLES DEMOF1HELP.

TEXT = TEXT-001.

CALL SCREEN 100.

MODULE CANCEL INPUT.

LEAVE PROGRAM.

ENDMODULE.

MODULE F1_HELP_FIELD2 INPUT.

INT = INT + 1.

CASE INT.

WHEN 1.

VAR = '0100'.

WHEN 2.

VAR = '0200'.

INT = 0.

ENDCASE.

ENDMODULE.

MODULE F1_HELP_FIELD3 INPUT.

CALL FUNCTION 'HELP_OBJECT_SHOW_FOR_FIELD'

EXPORTING

DOKLANGU = SY-LANGU

DOKTITLE = TEXT-002

CALLED_FOR_TAB = 'DEMOF1HELP'

CALLED_FOR_FIELD = 'FIELD1'.

ENDMODULE.

MODULE F1_HELP_FIELD4 INPUT.

CALL FUNCTION 'HELP_OBJECT_SHOW'

EXPORTING

DOKCLASS = 'TX'

DOKLANGU = SY-LANGU

DOKNAME = 'DEMO_FOR_F1_HELP'

DOKTITLE = TEXT-003

TABLES

LINKS = LINKS.

ENDMODULE.

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

This graphic is explained in the accompanying text

The screen fields DEMOf1HELP-FIELD1 and DEMOF1HELP-FIELD2 from the ABAP Dictionary and the program fields FIELD3 and FIELD4 are assigned to the input fields. The pushbutton has the function code CANCEL with function type E.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.

PROCESS AFTER INPUT.

MODULE CANCEL AT EXIT-COMMAND.

PROCESS ON HELP-REQUEST.

FIELD DEMOF1HELP-FIELD2 MODULE F1_HELP_FIELD2 WITH VAR.

FIELD FIELD3 MODULE F1_HELP_FIELD3.

FIELD FIELD4 MODULE F1_HELP_FIELD4.

The components FIELD1 and FIELD2 of structure DEMOF1HELP both refer to the data element DEMOF1TYPE. This data element is documented, and also has two supplements with numbers 0100 and 0200.

The following field help is displayed:

• When the user chooses F1 on the input field for DEMOF1HELP-FIELD1, the data element documentation for DEMOF1TYPE is displayed, since the field does not occur in the PROCESS ON HELP-REQUEST event.

• If the user chooses F1 repeatedly for the input field DEMOF1HELP-FIELD2, the data element documentation is displayed, along with the supplement documentation for either 0100 or 0200 alternately. The variable VAR is filled in the dialog module F1_HELP_FIELD2.

• When the user chooses F1 on the input field for FIELD3, the data element documentation for DEMOF1TYPE is displayed, since this is called in the dialog module F1_HELP_FIELD3 by the function module HELP_OBJECT_SHOW_FOR_FIELD.

• When the user chooses F1 on the input field for FIELD4, the SAPscript documentation DEMO_FOR_F1_HELP is displayed, since this is called in the dialog module F1_HELP_FIELD4 by the function module HELP_OBJECT.

POV

Code to demonstrate how to perform a manual value help(F4) on a particular field using the PROCESS ON

VALUE-REQUEST statement and how to return values back to a table control on the screen. For standard

screen fields simply move the value to the appropriate screen field name.

• Screen flow logic........

PROCESS BEFORE OUTPUT.

*MODULE PBO_MODULE.

PROCESS AFTER INPUT.

*MODULE PAI_MODULE.

PROCESS ON VALUE-REQUEST. "F4

FIELD EKPO-EBELP MODULE help_ekpo.

• populate screen field from within PROCESS ON VALUE-REQUEST(F4) call

&----

---

*& Module help_responsibility INPUT

&----

---

• text

----

---

MODULE help_ekpo INPUT.

**Transport values to table dynpro/screen table control

DATA: l_stepl LIKE sy-stepl,

l_indx LIKE sy-stepl.

DATA: dynpfields LIKE dynpread OCCURS 5 WITH HEADER LINE.

• Adjust for scroling within table control

CALL FUNCTION 'DYNP_GET_STEPL'

IMPORTING

povstepl = l_stepl

EXCEPTIONS

stepl_not_found = 0

OTHERS = 0.

l_indx = tc_ekpotable-top_line + l_stepl - 1.

"tc_ekpotable should already have been declared

REFRESH dynpfields.

CLEAR dynpfields.

dynpfields-fieldname = 'EKPO-EBELN'.

dynpfields-fieldvalue = '00010' "wa_ekpo-ebeln.

dynpfields-stepl = l_stepl.

APPEND dynpfields.

dynpfields-fieldname = 'EKPO-EBELP'.

dynpfields-fieldvalue = '00020' "wa_ekpo-ebelp.

dynpfields-stepl = l_stepl.

APPEND dynpfields.

CALL FUNCTION 'DYNP_VALUES_UPDATE'

EXPORTING

dyname = 'SAPLZZ_EKKO' "Program name

dynumb = '0100' "Screen number

TABLES

dynpfields = dynpfields

EXCEPTIONS

OTHERS = 0.

ENDMODULE. " help_ekpo INPUT

reward if helpful

kushagra

[Former Member]

Hi Surender,

A dialog program consists of the following basic components:

Screens (dynpros)

Each dialog in an SAP system is controlled by dynpros. A dynpro (DYnamic PROgram) consists of a screen and its flow logic and controls exactly one dialog step. The flow logic determines which processing takes place before displaying the screen (PBO-Process Before Output) and after receiving the entries the user made on the screen (PAI-Process After Input).

The screen layout fixed in the Screen Painter determines the positions of input/output fields, text fields, and graphical elements such as radio buttons and checkboxes. In addition, the Menu Painter allows to store menus, icons, pushbuttons, and function keys in one or more GUI statuses. Dynpros and GUI statuses refer to the ABAP/4 program that control the sequence of the dynpros and GUI statuses at runtime.

ABAP/4 module pool

Each dynpro refers to exactly one ABAP/4 dialog program. Such a dialog program is also called a module pool, since it consists of interactive modules. The flow logic of a dynpro contains calls of modules from the corresponding module pool. Interactive modules called at the PBO event are used to prepare the screen template in accordance to the context, for example by setting field contents or by suppressing fields from the display that are not needed. Interactive modules called at the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.

All dynpros to be called from within one transaction refer to a common module pool. The dynpros of a module pool are numbered. By default, the system stores for each dynpro the dynpro to be displayed next. This dynpro sequence or chain can be linear as well as cyclic. From within a dynpro chain, you can even call another dynpro chain and, after processing it, return to the original chain.

Screen:

->Most general type of User dialog used in ABAP Programs.

->Created through screen painter

->Each screen contains

Input/ Output mask

The Layout of screen

Flow Logic

->The screen flow logic is divided into four components:

Process Before Output (PBO) event:

which is processed before the screen is displayed

Process After Input (PAI) event:

Which is processed after a user action on the screen

Process on help request (POH)

which is processed when F1 is pressed

Process on value request (POV)

which is processed when F4 is pressed

You can define screens for any program with type 1, M, or F.

The screen flow logic is primarily 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.

Dialog modules called in the PBO event are used to prepare the screen, for example by setting context-specific field contents or by suppressing fields from the display that are not needed. Dialog modules called in the PAI event are used to check the user input and to trigger appropriate dialog steps, such as the update task.

An R/3 transaction is a series of business-related, logically consistent dialog steps. In a typical dialog, the system displays a screen on which the user can enter or request information. As a reaction on the the user input or request, the program executes the appropriate actions: it branches to the next screen, displays an output, or changes the database.

Processing Transactions

For a SAP transaction, the graphical representation of the screen and related processing logic is called a dynpro (dynamic program). Each dynpro consists of a PBO/PAI module to prepare and process the data displayed or entered on the screen.

PBO (Process Before Output): A processing event which is called before the screen is displayed. Its tasks include the initialization of the screen fields and supply default data values for the screen.

PAI (Process After Input): A processing event taking place after you leave a screen. Its tasks are to process the input data or initiate the update of the database.

At beginning screen 100 of say program X is called by a transaction T1. Even before screen 100 is displayed to user, the PBO modules for screen 100 are processed and then only screen 100 becomes visible to user on his/her screen.

Later, after user inputs data and does any function say pressing any keyboard key or any button on screen 100, the system takes his input into Function code variable, and passes it to the Flow logic of screen. Function code thus can be considered as medium of communication between screen mask and processing logic which carries user actions performed on screen.

After user action say pressing ENTER key on screen is captured by function code, it passes to flow logic of Screen 100 and then PAI modules of screen 100 are processed. PAI processes of screen 100 then makes a formal call to screen 200 as defined in logical relationship.

Similar to previous screen, again PBO modules will be processed before displaying screen 200 to the user. The system dialog process in between takes care of database updation or validations that need to be performed based on user inputs.

The process of PBO and PAI is same for every screen being called from any screen thus it gives flexibility to developer to design the individual screen independently by putting appropriate validations or performs in PBO and PAI modules.

hope this is helpful.

regards,

sravanthi.

[Former Member]

process on help-request

To display data element supplement documentation, you must code the following screen flow logic in the POH event:

PROCESS ON HELP-REQUEST.

...

FIELD <f> [MODULE <mod>] WITH <num>.

...

After PROCESS ON HELP-REQUEST, you can only use FIELD statements. If there is no PROCESS ON HELP-REQUEST keyword in the flow logic of the screen, the data element documentation for the current field, or no help at all is displayed when the user chooses F1. Otherwise, the next FIELD statement containing the current field <f> is executed.

If there is screen-specific data element supplement documentation for the field <f>, you can display it by specifying its number <num>. The number <num> can be a literal or a variable. The variable must be declared and filled in the corresponding ABAP program.

You can fill the variables, for example, by calling the module <mod> before the help is displayed. However, the FIELD statement does not transport the contents of the screen field <f> to the ABAP program in the PROCESS ON HELP-REQUEST event.

If data element supplement documentation is insufficient for your requirements, or you want to display help for program fields that you have not copied from the ABAP Dictionary, you can call dialog modules in the POH event:

PROCESS ON HELP-REQUEST.

...

FIELD <f> MODULE <mod>.

...

After the PROCESS ON HELP-REQUEST statement, you can only use the MODULE statement together with the FIELD statement. When the user chooses F1 for a field <f>, the system calls the module <mod> belonging to the FIELD <f> statement. If there is more than one FIELD statement for the same field <f>, only the first is executed. However, the contents of the screen field <f> are not available in the module <mod>, since it is not transported by the FIELD statement during the PROCESS ON HELP-REQUEST event. The field help should not be dependent on the user input.

EXAMPLE CODE

REPORT DEMO_DYNPRO_F1_HELP.

DATA: TEXT(30),

VAR(4),

INT TYPE I,

LINKS TYPE TABLE OF TLINE,

FIELD3, FIELD4.

TABLES DEMOF1HELP.

TEXT = TEXT-001.

CALL SCREEN 100.

MODULE CANCEL INPUT.

LEAVE PROGRAM.

ENDMODULE.

MODULE F1_HELP_FIELD2 INPUT.

INT = INT + 1.

CASE INT.

WHEN 1.

VAR = '0100'.

WHEN 2.

VAR = '0200'.

INT = 0.

ENDCASE.

ENDMODULE.

MODULE F1_HELP_FIELD3 INPUT.

CALL FUNCTION 'HELP_OBJECT_SHOW_FOR_FIELD'

EXPORTING

DOKLANGU = SY-LANGU

DOKTITLE = TEXT-002

CALLED_FOR_TAB = 'DEMOF1HELP'

CALLED_FOR_FIELD = 'FIELD1'.

ENDMODULE.

MODULE F1_HELP_FIELD4 INPUT.

CALL FUNCTION 'HELP_OBJECT_SHOW'

EXPORTING

DOKCLASS = 'TX'

DOKLANGU = SY-LANGU

DOKNAME = 'DEMO_FOR_F1_HELP'

DOKTITLE = TEXT-003

TABLES

LINKS = LINKS.

ENDMODULE.

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

The screen fields DEMOf1HELP-FIELD1 and DEMOF1HELP-FIELD2 from the ABAP Dictionary and the program fields FIELD3 and FIELD4 are assigned to the input fields. The pushbutton has the function code CANCEL with function type E.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.

PROCESS AFTER INPUT.

MODULE CANCEL AT EXIT-COMMAND.

PROCESS ON HELP-REQUEST.

FIELD DEMOF1HELP-FIELD2 MODULE F1_HELP_FIELD2 WITH VAR.

FIELD FIELD3 MODULE F1_HELP_FIELD3.

FIELD FIELD4 MODULE F1_HELP_FIELD4.

The components FIELD1 and FIELD2 of structure DEMOF1HELP both refer to the data element DEMOF1TYPE. This data element is documented, and also has two supplements with numbers 0100 and 0200.

The following field help is displayed:

When the user chooses F1 on the input field for DEMOF1HELP-FIELD1, the data element documentation for DEMOF1TYPE is displayed, since the field does not occur in the PROCESS ON HELP-REQUEST event.

If the user chooses F1 repeatedly for the input field DEMOF1HELP-FIELD2, the data element documentation is displayed, along with the supplement documentation for either 0100 or 0200 alternately. The variable VAR is filled in the dialog module F1_HELP_FIELD2.

When the user chooses F1 on the input field for FIELD3, the data element documentation for DEMOF1TYPE is displayed, since this is called in the dialog module F1_HELP_FIELD3 by the function module HELP_OBJECT_SHOW_FOR_FIELD.

When the user chooses F1 on the input field for FIELD4, the SAPscript documentation DEMO_FOR_F1_HELP is displayed, since this is called in the dialog module F1_HELP_FIELD4 by the function module HELP_OBJECT.

PROCESS ON VALUE REQUEST

You can call dialog modules in the POV event using the event keyword PROCESS ON VALUE-REQUEST.

PROCESS ON VALUE-REQUEST.

...

FIELD <f> MODULE <mod>.

...

After the PROCESS ON VALUE-REQUEST statement, you can only use the MODULE statement together with the FIELD statement. When the user chooses F4 for a field <f>, the system calls the module <mod> belonging to the FIELD <f> statement. If there is more than one FIELD statement for the same field <f>, only the first is executed. The module <mod> is defined in the ABAP program like a normal PAI module. However, the contents of the screen field <f> are not available, since it is not transported by the FIELD statement during the PROCESS ON HELP-REQUEST event. You can now program your own value lists in the module. However, this procedure is only recommended if it really is not possible to use a search help. Defining search helps is much easier than PROCESS ON VALUE-REQUEST, since the system takes over some of the standard operations, such as getting field contents from the screen. It also ensures that the F4 help has a uniform look and feel throughout the system. Furthermore, it means that you do not have to reassign input help to fields on each screen.

Despite the introduction of search helps (and search help exits), there are still cases in which you need to use parts of the standard F4 functions directly. In this case, there are some standard function modules that you can use in the POV event. They support search helps, as well as all other kinds of input help, and are responsible for data transport between the screen and the input help. These all have the prefix F4IF_. The most important are:

F4IF_INT_TABLE_VALUE_REQUEST

This function module displays a value list that you created in an ABAP program. The value list is passed to the function module as the table parameter VALUE_TAB. If you specify the import parameters DYNPPROG, DYNPNR, and DYNPROFIELD, the user’s selection is returned to the corresponding field on the screen. If you specify the table parameter RETURN_TAB, the selection is returned into the table instead.

EXAMPLE CODE

Input help in dialog modules

REPORT DEMO_DYNPRO_F4_HELP_MODULE.

TYPES: BEGIN OF VALUES,

CARRID TYPE SPFLI-CARRID,

CONNID TYPE SPFLI-CONNID,

END OF VALUES.

DATA: CARRIER(3) TYPE C,

CONNECTION(4) TYPE C.

DATA: PROGNAME LIKE SY-REPID,

DYNNUM LIKE SY-DYNNR,

DYNPRO_VALUES TYPE TABLE OF DYNPREAD,

FIELD_VALUE LIKE LINE OF DYNPRO_VALUES,

VALUES_TAB TYPE TABLE OF VALUES.

CALL SCREEN 100.

MODULE INIT OUTPUT.

PROGNAME = SY-REPID.

DYNNUM = SY-DYNNR.

CLEAR: FIELD_VALUE, DYNPRO_VALUES.

FIELD_VALUE-FIELDNAME = 'CARRIER'.

APPEND FIELD_VALUE TO DYNPRO_VALUES.

ENDMODULE.

MODULE CANCEL INPUT.

LEAVE PROGRAM.

ENDMODULE.

MODULE VALUE_CARRIER INPUT.

CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST'

EXPORTING

TABNAME = 'DEMOF4HELP'

FIELDNAME = 'CARRIER1'

DYNPPROG = PROGNAME

DYNPNR = DYNNUM

DYNPROFIELD = 'CARRIER'.

ENDMODULE.

MODULE VALUE_CONNECTION INPUT.

CALL FUNCTION 'DYNP_VALUES_READ'

EXPORTING

DYNAME = PROGNAME

DYNUMB = DYNNUM

TRANSLATE_TO_UPPER = 'X'

TABLES

DYNPFIELDS = DYNPRO_VALUES.

READ TABLE DYNPRO_VALUES INDEX 1 INTO FIELD_VALUE.

SELECT CARRID CONNID

FROM SPFLI

INTO CORRESPONDING FIELDS OF TABLE VALUES_TAB

WHERE CARRID = FIELD_VALUE-FIELDVALUE.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

RETFIELD = 'CONNID'

DYNPPROG = PROGNAME

DYNPNR = DYNNUM

DYNPROFIELD = 'CONNECTION'

VALUE_ORG = 'S'

TABLES

VALUE_TAB = VALUES_TAB.

ENDMODULE.

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

The input fields have been adopted from the program fields CARRIER and CONNECTION. The pushbutton has the function code CANCEL with function type E.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.

MODULE INIT.

PROCESS AFTER INPUT.

MODULE CANCEL AT EXIT-COMMAND.

PROCESS ON VALUE-REQUEST.

FIELD CARRIER MODULE VALUE_CARRIER.

FIELD CONNECTION MODULE VALUE_CONNECTION.

When the user chooses input help for the individual fields, the following is displayed:

For the Airline field, the POV module VALUE_CARRIER is called. The function module F4IF_FIELD_VALUE_REQUEST displays the input help for the component CARRIER1 of the structure DEMOF4HELP from the ABAP Dictionary, namely the search help DEMOF4DE. The user’s selection is returned to the screen field CARRIER.

For the Flight number field, the POV module VALUE_CONNECTION is called. The function module DYNP_VALUE_READ transports the value of the screen field CARRIER into the program. The program then reads the corresponding values from the database table SPFLI into the internal table VALUES_TAB using a SELECT statement, and passes the internal table to F4IF_INT_TABLE_VALUE_REQUEST. This displays the internal table as input help, and places the user’s selection into the screen field CONNECTION.

PBO AND PAI

The flow logic code of a dialog screen consists of a few statements that syntactically resemble ABAP statements. You cannot use flow logic keywords in ABAP programs, or ABAP statements in screen flow logic. You enter the flow control code in the Screen Painter as one component of the screen.

The flow control for the screen in Transaction DEMO_TRANSACTION looks like this:

PROCESS BEFORE OUTPUT.

MODULE set_status_0100.

***

PROCESS AFTER INPUT

MODULE user_command_0100.

The PROCESS statement introduces the flow logic for the two events PBO and PAI. The MODULE statements each call one dialog module in the associated ABAP program. In this example, there is only one MODULE for each event PBO and PAI. However, the flow logic can, of course, contain more statements, calling more than one dialog module in each event. You can also call the same dialog module from more than one screen.

The flow logic syntax contains only a few statements. The most important are MODULE, FIELD, CHAIN, LOOP, and CALL SUBSCREEN. For information about flow logic syntax, choose Utilities Help on... from the flow logic editor. A dialog box appears, in which you select Flow logic keyword and then enter the keyword for which you want more information.

ABAP Program

In our example, the ABAP program has type M, that is, it is a module pool. When you create a type M program in the Repository Browser, the ABAP Workbench automatically organizes the program code into a series of include programs. If your ABAP program observes the naming convention SAPM<name>, the hierarchy tree in the Repository Browser allows you to create the following include programs:

Global fields: Global data declarations in the include M<name>TOP. This data is visible in all modules within the program.

PBO module: Dialog modules in the includes M<name>O<nn>, which are called before a screen is displayed.

PAI module: Dialog modules in the includes M<name>I<nn>, which are called after user actions on screens.

Subroutines: Subroutines within the program, stored in the includes M<name>F<nn>. These can be called from anywhere in the program.

List events: Event blocks for list processor events, stored in the includes M<name>E<nn>. These occur during list processing.

Include programs can contain several processing blocks. These normally all have the same type (for example, only PBO modules or only PAI modules). However, you could create a separate include program for each processing block, or combine various types of processing block in a single include program.

If you follow the working method suggested by the ABAP Workbench, the source code of your main program is empty apart from a series of INCLUDE statements that incorporate the individual includes into your program:

EXAMPLE PROGRAM

&----

---

*& Module pool SAPMDEMO_TRANSACTION *

*& *

&----

---

*& *

*& Display data of table SPFLI *

*& *

&----

---

• Global data

INCLUDE mdemo_transactiontop.

• PAI-Module

INCLUDE mdemo_transactioni01.

• PBO-Module

INCLUDE mdemo_transactiono01.

In this sample program the include programs look like this:

&----

---

*& Module pool SAPMDEMO_TRANSACTION *

*& FUNCTION: Display data of table SPFLI *

*& *

&----

---

----

---

• INCLUDE MDEMO_TRANSACTIONTOP (This is the TOP include: *

• The TOP module contains global data declarations) *

----

---

PROGRAM sapmdemo_transaction.

TABLES: spfli.

DATA ok_code(4).

----

---

• INCLUDE MDEMO_TRANSACTIONO01 (This is a PBO include.) *

----

---

&----

---

*& Module STATUS_0100

&----

---

• Define GUI status and title for screen 100 *

----

---

MODULE status_0100.

SET PF-STATUS ‘ TZ0100 ’ .

SET TITLEBAR ‘ 100 ’ .

ENDMODULE.

----

---

• INCLUDE MDEMO_TRANSACTIONI01 (This is a PAI include.) *

----

---

&----

---

*& Module USER_COMMAND_0100 INPUT

&----

---

• Get data from SPFLI or leave transaction *

----

---

MODULE USER_COMMAND_0100 INPUT.

CASE ok_code.

WHEN ‘ SHOW ’ .

CLEAR ok_code.

SELECT SINGLE * FROM spfli WHERE carrid = spfli-carrid

AND connid = spfli-connid.

WHEN space.

WHEN OTHERS.

CLEAR ok_code.

SET SCREEN 0. LEAVE SCREEN.

ENDCASE.

ENDMODULE.

A table work area for database table SPFLI is created in include program MDEMO_TRANSACTIONTOP with the TABLES statement. The table work area serves as an interface for passing data between the screen and the ABAP program, since the input/output fields on the screen were created with the same ABAP Dictionary reference. The OK_CODE field is used to receive function codes from the identically-named screen field.

The PBO module for screen 100 sets dialog status STATUS_0100 and GUI title 100 in the include program MDEMO_TRANSACTIONO1. This GUI status and this GUI title remain valid for all subsequent screens until a new dialog status or GUI title is set. It is important that you set a dialog status, since the system otherwise uses an empty status that does not allow the user to leave the program.

In the include program MDEMO_TRANSACTIONI01, the PAI module USER_COMMAND_0100 checks which pushbutton the user chose (CASE OK_CODE.). The Display pushbutton has the function code ‘SHOW’. If the user chooses this function, the program reads the entries from database table SPFLI that correspond to the details entered by the user. In the WHERE condition of the SELECT statement, the system compares the fields SPFLI-CARRID and SPFLI-CONNID (filled in on the screen by the user) with the key fields CARRID and CONNID of database table SPFLI.

Before the screen is next displayed, the data from the table work area is passed to the corresponding screen fields, and therefore appears on the screen

FOR A DETAILED EXPALNATION

LINK http://help.sap.com/saphelp_nw04/helpdata/en/9f/db9ce935c111d1829f0000e829fbfe/content.htm

DO REWARD IF USEFUL

[Former Member]

hi,

The screen flow logic is like an ABAP program in that it serves as a container for processing blocks. There are four event blocks, each of which is introduced with the screen keyword PROCESS:

PROCESS BEFORE OUTPUT (PBO) is automatically triggered after the PAI processing of the previous screen and before the current screen is displayed. You can program the PBO processing of the screen in this block. At the end of the PBO processing, the screen is displayed.

PROCESS AFTER INPUT (PAI) is triggered when the user chooses a function on the screen. You can program the PAI processing of the screen in this block. At the end of the PAI processing, the system either calls the next screen or carries on processing at the point from which the screen was called.

PROCESS ON HELP-REQUEST (POH) and PROCESS ON VALUE-REQUEST (POV) are triggered when the user requests field help (F1) or possible values help (F4) respectively. You can program the appropriate coding in the corresponding event blocks. At the end of processing, the system carries on processing the current screen.

[Former Member]

Hi,

These four are the events in modulepool programming.

PBO means Process before output. It triggers before the display of the selection screen. So whatever logic we write under this will be triggered before processing of selection screen.

PAI means Process after input. It triggers after user enters the values in to the selection screen. Here we mainly write the validations.

POH means Process on help request. It triggers when user press the F1 key. If user not used that then it won't trigger at all.

POV means Process on value request. It triggers when user press the F4 key for the possible values that feild can take. If user not used that key then this event also won't trigger.

Here PBO and PAI are mandatory events in any modulepool programming.

Thanks

Sarada