SCREEN ELEMENTS FOR INPUT AND OUTPUT IN SAP

An input field is a rectangular screen element in which users can enter data.

An output field is a rectangular screen element in which the system displays text or other data.

Input/output fields are also known as templates.

Input fields can have automatic input checks based on thir data type (for example, a date field will only allow you to enter a valid date).

Input fields that you create with reference to ABAP Dictionary fie lds may have built-in data consistency checks (foreign key checks, value sets).

Input fields may have possible values help (F4)

You can temporarily change the object attributes marked in gray using the system table SCREEN.

It may not be possible to activate all possible combinations of attributes. This depends on the format of the input/output fie ld.
Example: You cannot activate the Leading zeros attribute for a field with the data format CHAR, since it is only relevant for numeric fields.

You can create input/output fields in two ways:
By entering them directly in the layout editor. You determine the size of the field by the number of underscore characters in the object text attribute. For numeric values, you can specify a comma as a separator, and a period as a decimal point. As the last character in the input/output field, you can enter 'V' as a placeholder for a plus or minus sign.

By using a template from the ABAP Dictionary. Choose Dict/Program fields to do this.

If you want to use the contents of an input/output field in your ABAP program, you must declare the field globally using the DATA or TABLES statement.

You can save values in SAP memory using a parameter ID. These are user and terminal-session specific, but available to all internal sessions .

SET PARAMETER copies the corresponding field contents into SAP memory in the PAI processing block.

GET PARAMETER copies the corresponding field contents from SAP memory at the end of the PBO processing block (after data has been transferred from the program), but only if the screen field still has its initial value.

You can link an input/output field to an area of SAP memory in the ABAP Dictionary.

When you use an input/output field that is defined in the ABAP Dictionary, its parameter ID is displayed in the Dictionary attribute PID in the Screen Painter.

The SPA and GPA attributes allow you to enable the set and get parameter functions separately.

You can define parameter IDs in table TPARA.

After the screen has been displayed, but before the PAI modules are processed, the system automatically checks the values that the user has entered on the screen.

The first check is to ensure that all required fields have been filled.

The system can only perform a foreign key check if a screen field refers back to a ABAP Dictionary field for which a check table has been defined and the Foreign key check attribute has been set.

The F4 help function is also active. This enables users to display possible entries.

If the automatic field input checks are insufficient for your requirements, you can program your own in the PAI event. To do this, use the FIELD statement with the MODULE addition. This means that the module you specify is only processed for the field specified in the FIELD statement.

If an error or warning message occurs during the module, the system sends the screen again, but without processing the PBO module . The message is displayed, and only the field to which the check was applied is ready for input.

Note: It is the FIELD statement that is responsible for making the field ready for input again. If you use a message in a module that is not called from within a FIELD statement, the system displays the message, but does not make the field ready for input again.

If you want to ensure that more than one field is ready for input following an error dialog, you must list all of the relevant fields in the FIELD statement, and include both that and the MODULE statement in a CHAIN … ENDCHAIN block.

You can include individual fields in more than one CHAIN … ENDCHAIN block.

Note that the FIELD statement does not only make the field ready for input again; it also means that field contents changed during the current PAI processing are only visible if the field in question was also included in the FIELD statement of the current CHAIN block.

If the system sends an error or warning message, the current screen is sent again, but the PBO is not processed again.

Only the fields to which the module is assigned are ready for input again.

After the user has entered new values, the PROCESS AFTER INPUT module is not completely reprocessed, but restarted somewhere within the processing block.

The system finds out which field the user changed and resumes processing at the first corresponding FIELD statement.

If the user merely confirms a warning message (without changing the fields contents), the system restarts the PAI processing after the MESSAGE statement where the error was triggered.

There are six different categories of message: A, X, E, W, I, and S:

A Termination The processing terminates and the user must restart the transaction.
X Exit Like message type A, but with short dump MESSAGE_TYPE_X.
E Error Processing is interrupted, and the user must correct the entry.
W Warning Processing is interrupted and the user can correct the entries (works
like an E message). However, it is also possible to confirm the existing
entries by pressing ENTER (works like an I message)
I Information Processing is interrupted, but continues when the user has confirmed
the message (pressed ENTER).
S Success Displays information on the next screen

The system transports data from screen fields into the ABAP fields with the same name in the PAI processing block. First, it transports all fields that are not contained in any FIELD statements. The remaining fields are transported when the system processes the relevant FIELD statement.

If an error or warning message occurs in a module belonging to a FIELD statement, the current values of all fields in the same CHAIN structure are automatically transported back into their corresponding screen fields.

Field input checks usually require access to the database. Consequently, avoiding them where possible improves the performance of your program.

If the user "strayed" onto the screen by mistake, he or she will not usually be able to make a consistent set of entries that will satisfy the input checks. You should therefore make it possible for a user to leave a screen without the field checks taking place.

To protect the user from losing data that he or she has already entered if they leave the screen unintentionally, you should program security prompts.

If you use the ON INPUT addition in a MODULE statement after FIELD, the module is only called if the field contents have changed from their initial value.

Within a CHAIN block, you must use the ON CHAIN-INPUT addition. The module is then called if the contents of at least one screen field within the CHAIN block have changed from their initial value.

You may only use the ON INPUT addition if the MODULE statement is contained in a FIELD statement.

If you use the ON REQUEST addition in a MODULE statement after FIELD, the module is only called if the user has entered a new value in that field.

Within a CHAIN block, you must use the ON CHAIN-REQUEST addition. The module is then called if the user has changed the contents of at least one screen field within the CHAIN block.

You may only use the ON REQUEST addition if the MODULE statement is contained in a FIELD statement.

The module with the addition AT EXIT-COMMAND is processed before the automatic field input checks. You can use it for navigation. You may only use the AT EXIT-COMMAND addition with one module. It may not have an associated FIELD statement.

If you do not leave the screen from this module, the automatic field checks are processed after it, followed by the rest of the PAI event.

Ensure that you process the contents of the OK_CODE field appropriately.
The SAP Style Guide contains details of how you should set the navigation functions

Back, Exit, and Cancel.

The BACK function (green left arrow) should lead one logical level backwards. From screens on the same level as the initial screen, it leads back to the initial screen. From screens that contain detailed information, it leads back to the screen that called the current screen.

The CANCEL function differs from BACK in its dialog behavior. For details, see the next page.

The EXIT function should return to where the processing unit was called.

On the initial screen of a program, all three functions Back, Exit, and Cancel lead back to the screen from which the current program was called.

If the user has entered data on the screen (sy-datar = 'X' or your own flag), you can avoid accidental loss of data by using a predefined security prompt.

As well as specifying the targets of the Back, Exit, and Cancel functions, the SAP Style Guide also contains information about the dialogs you should conduct with the user, and the sequence of dialogs and automatic field checks.

For the Exit and Cancel functions, you should first send a dialog box to the user. Then (in the case of the Exit function), the system checks the input on the screen. The functions in question must have function type 'E'.

In the case of the Back function, the input checks come before the dialog.

The R/3 System contains a series of function modules that you can use for the user dialogs.

You can help the user with input by using dropdown list boxes containing the possible entries.

Input help (F4 help) is a standard function in the R/3 System. It allows the user to display a list of possible entries for a screen field. If the field is ready for input, the user can place a value in it by selecting it from the list.

If a field has input help, the possible entries button appears on its right hand side. The button is visible whenever the cursor is placed in the field. You can start the help either by clicking the button or choosing F4.

As well as the possible entries, the input help displays relevant additional information about the entries. This is especially useful when the field requires a formal key.

Since the input help is a standard function, it should have the same appearance and behavior throughout the system. There are utilities in the ABAP Workbench that allow you to assign standardized input help to a screen field.

The precise description of the input help of a field usually arises from its semantics. Consequently, input help is usually defined in the ABAP Dictionary.

Dropdown list boxes allow the user to choose an entry from a pull-down list containing the possible entries. The user cannot enter values freely, but must choose a value from the list.

To create a dropdown list box for an input field, you must do the following in the
Screen Painter:

Set the Dropdown attribute to list box.
Change the visLength attribute to the displayed length of the descriptive text.
Set the Value list attribute to ' ' to use value help from the ABAP Dictionary.

If required, set the function code for the selection. Like a menu entry, this function code triggers the PAI, and you can interpret it using the OK_CODE field.

Important: The visible length of the field determines the width of the field including button) and the selection list, and you must normally change it when you convert the field to a dropdown box.

The values are filled automatically using the search help assigned to the ABAP Dictionary field. The Dictionary field must have a search help (check table) with two columns or a table of fixed values.

Various things are required of input help for a screen field (the search field):

The input help must take into account information that the system already knows (the context). This includes both information that the user has entered on the current screen, and information from previous dialog steps. The input help normally uses the context to restrict the set of possible values.

The input help must find out the values that it will then present to the user for selection. It must also determine the data that will be displayed as additional information in the list of possible values. In determining the possible values, it must take into account restrictions that arise from the context, as well as those entered by the user as specific search conditions.

The input help must conduct a user dialog. This involves (at least) displaying the possible values with additional information, and allowing the user to choose a value from it. In many cases, the input help will also contain an input screen on which the user can specify conditions to restrict the number of possible entries displayed.

When the user selects a value, the input help must place it into the search field. In many cases, there are extra fields on the input screen (often only output fields), containing extra information about the search field. The input help should also update the contents of these fields.

The ABAP Dictionary object search help is a description of an input help. Its definition contains the information that the system requires to meet the user's needs.

The interface of the search help controls the data that is passed between the input screen and the F4 help. The interface determines the context data that is required and the data that can be placed back on the input screen when the user chooses a value.

The internal behavior of the search help describes the actual F4 process. This contains the selection method, which retrieves the values for display, and the dialog behavior, which describes the interaction with the user.

Similarly to function modules, search helps have an interface, which defines their capacity to exchange data with other software components, and an internal behavior (which, in the case of a function module, is its source code).

It is only worth defining a search help if there is a mechanism that allows you to address it from a screen. This mechanism is called a search help connection, and is described later.

Like the function module editor, the search help editor also allows you to test your objects. This allows you to check how a search help behaves before you assign it to a screen field.

A search help describes the process of an input help. In order for it to work, we need a mechanism that assigns the search help to the field. This is called the search help connection.

Connecting a search help to a field affects its behavior. It is therefore regarded as part of the field definition.

The semantic and technical attributes of a screen field (type, length, F1 help) are ormally not defined directly when you define the screen. Normally, you use a reference in the Screen Painter to an existing field in the ABAP Dictionary. The screen field then inherits the attributes of the ABAP Dictionary field.
The same principle applies when you define input help for a screen field. The link between the search help and the search field is established using the ABAP Dictionary field, not the screen field.

When you assign a search help, its interface parameters are asssigned to the screen fields that are filled by the search help, or which pass information to it from the screen. The search field must be assigned to an EXPORT parameter of the search help. You should also make the search field an IMPORT parameter, so that the search help can take into account a search pattern already entered in the field by the user.

A field can have input help even if it does not have a search help - there are other mechanisms for F4 help (for example, fixed values for a domain).

There are three ways to link a search help to a field in the ABAP Dictionary.

It can be assigned directly to a field of a structure or table. You define this link in very much the same way as you would define a foreign key. You should define the assignment here (between the interface parameters of the search help and the structure field). The system generates a proposal.

If the field has a check table, its contents are automatically proposed as possible values in the input help. The key fields of the check table are displayed. If the check table has a text table, the first nonkey character field is also displayed.
If the default display is insufficient for your requirements, you can attach a search help to the check table. This is then used for all fields that have that check table. When you link the search help, you must define the assignment between the search help interface and the key of the check table.

The semantics of a field and its possible values are defined by its data element. You can therefore also link a search help to a data element. The search help is then used by all fields that are based on that data element. When you link the search help, you must specify a single EXPORT parameter, which will be used to transfer the data.

Attaching a search help to a check table (or data element) increases its reusability. However, it does restrict your options for passing extra values to the search help interface.

To allow as many fields as possible to carry useful input help, the R/3 System contains a wide range of mechanisms with which you can define it. If it is possible to use more than one of these for a particular field, the one highest in the hierarchy is used.

As well as defining the input help for a field in the ABAP Dictionary (as we have already seen), you can also define it in the screen field. This method has the disadvantage that you cannot reuse it automatically.

The screen event POV (PROCESS ON VALUE-REQUEST) allows you to program input help for a field yourself. You can make this help appear in standard form by using the function modules F4IF_FIELD_VALUE_REQUEST or F4IF_INT_TABLE_VALUE_REQUEST.
However, you should first check to see whether you cannot program your own input help better using a search help exit.

You can also attach a search help to a screen field in the Screen Painter. However, the functional scope of this technique is more restricted in comparison to attaching a search help in the ABAP Dictionary.

You should no longer use input checks programmed directly in the flow logic (and from which input help can be derived).

In the context menu (right-click) for the hit list, there is a function Technical info. This tells you which mechanism is being used in a particular case.

Use radio buttons when you want to allow a user to choose only a single element from a group of fields.

Use checkboxes when you want to allow the user to choose one or more elements from a group of fields.

With radio buttons, one selection rules out all other options within the group. When the user selects one, all of the others are automatically deselected.

When the user selects a radio button, control is not immediately passed back to a work process on the application server. As with checkboxes (but in contrast to pushbuttons), it is still possible to make further entries before pressing a pushbutton or choosing a menu option.

Checkboxes allow the user to select more than one element at once. Control is not returned to a work process on the application server. This does not happen until the user chooses a pushbutton or menu entry.

Checkboxes and radio buttons must have an object name.

As well as the input/output field, you can display text and icons for them. The text is contained in the Object text field in the attributes. To display an icon, enter its name in the Icon name attribute. You can enter quick info for the icon in the appropriate field.

You can change the Input field and Invisible attributes using the system table SCREEN.

You create checkboxes in the fullscreen editor of the Screen Painter. To do this, choose the checkbox object from the object list and place it on the screen. You must assign names to checkboxes. In the ABAP program, create a field with the same name, type C, and length 1.

You can find out whether a user has chosen a checkbox in the ABAP program by querying the field contents. If a checkbox is not selected, its field value is initial.

You can assign a function code and function type to a checkbox. When the user selects it, the PAI event is triggered as though the user had chosen a menu entry.

You create radio buttons in the layout editor of the Screen Painter. There are two steps involved:

Create the radio buttons as individual elements. Choose "radio button" from the bject list and place it on the screen. You must assign names to radio buttons. In the ABAP program, create a field with the same name, type C, and length 1.
Combine a collection of radio buttons into a radio button group. To do this, select the radio buttons in the layout editor and then choose Edit -> Group -> Radio button group -> Define.


You can find out which radio button a user has chosen by querying the field contents in the ABAP program. If a radio button is not selected, the field value is initial.

You can assign a function code and function type to a radio button group. When the user selects one of its radio buttons, the PAI event is triggered as though the user had chosen a menu entry.

A pushbutton triggers a particular function. When the user chooses it, the system tells the program which function has been chosen. At this point, control of the program passes back to a work process on the application server, which processes the PAI processing block.

Pushbuttons may contain text (Object text attribute), an icon, or both. You can either specify an icon statically, or dynamically, using the function module ICON_CREATE.

You can change the visible length , output field , and invisible attributes dynamically using the system table SCREEN.

You can change the text on a pushbutton dynamically. To do this, you must have set the Output field attribute in the Screen Painter to active, and created a global field with the same name in your ABAP program. Because the Screen Painter field and the program field have the same name, any changes to the field contents will be immediately visible on the screen (similarly to input/output fields).

When you create a pushbutton, you must:

Create the pushbutton itself. Choose the Pushbutton object from the Screen Painter object list, place it on the screen, and assign a name to it in the "Object name" attribute. You can enter a static text in the "Object text" attribute. Enter a function code for the pushbutton in the "Function code" attribute. This is placed in the OK_CODE field automatically when the user chooses the pushbutton on the screen.
Activate the OK_CODE field on the screen by assigning a name to the OK_CODE field object in the Screen Painter field list and creating a field in your ABAP program that has the same name. You m,ust give the field a name in the element list of the Screen Painter, then declare an identically-named field in the ABAP program with reference to the system field sy-ucomm.


When the user chooses a function on the screen, the system places the corresponding function code into the OK_CODE field. You can then query the field and use the result to trigger the appropriate processing block.

Pushbuttons have a function code and a function type.

If the user chooses a pushbutton that has the function type ' ', the PAI event is processed. The system places the function code that has been triggered into the OK_CODE field, which you can then query in the module.

If the user chooses a pushbutton whose function has the function type "E", the system processes a module with the addition AT EXIT-COMMAND. This happens before the automatic field transport and the field input checks. The system places the function code that has been triggered into the OK_CODE field, which you can then query in the module.

After the AT EXIT-COMMAND module, the system continues processing the screen normally (field input checks, followed by PAI processing).