Input Help from the ABAP Dictionary  

The main input help available from the ABAP Dictionary is in the form of search helps. Search helps are independent Repository objects that you create using the ABAP Dictionary. They are used to present input help for screen fields. You can use link search helps to table fields and data elements. As well as search helps, you can still, in exceptional cases, use check tables, fixed values, or static input help.

Input Help Methods

There are two kinds of search helps: elementary and collective. An elementary search help represents a search path. It defines the location of the data for the hit list, how values are exchanged between the screen and the selection method, and the user dialog that occurs when the user chooses input help. A collective search help consists of two or more elementary search helps. Collective search helps cover a series of search paths for a field, all of which could be useful. The collective search help is the interface between the screen and the various elementary search helps.

The ABAP Dictionary allows you to define relationships between tables using foreign keys. A dependent table is called a foreign key table, and the referenced table is called the check table. Each key field of the check table corresponds to a field in the foreign key table. These fields are called foreign key fields. One of the foreign key fields is designated as the check field for checking the validity of values. The key fields of the check table can serve as input help for the check field.

You can restrict the values that a domain in the ABAP Dictionary may take by assigning fixed values to it. The fixed values can be used as input help for the fields that are defined using that domain. However, the value table of a domain is not used for input help. It is only used as a default value for the check tables of the fields that refer to the domain.

Fields with the types DATS and TIMS have their own predefined calendar and clock help that can be used as input help.

Input Help Hierarchy in the ABAP Dictionary

There are various ways of linking search helps with fields of database tables or components of structures. The input help available to a user depends on the type of link. The following list shows, in ascending order of priority, the input help that is used:

  1. Calendar and clock help

    2. If no other input help has been defined for a field with type DATS or TIMS, the calendar or clock help is displayed.

  2. Domain fixed values

    3. If a field has no check table or search help, any fixed values of the underlying domain are used.

  3. Search help of the data element

    4. Search helps from the ABAP Dictionary can be attached to a data element. If a field has no check table or search help of its own, the system uses the search help assigned to the underlying data element.

  4. Check table

    5. If the check table has no text table and no search help of its own, and a field has no search help of its own, the contents of the key fields of the check table are used as input help.

  5. Check table with text table

    6. You can define a text table for a table. If the check table for a field has a text table defined for it, the input help displays both the key fields from the check table and the corresponding text from the text table in the user’s logon language.

  6. Check table with search help

    7. Search helps can be attached to the check table of a field. The search help is displayed with the values from the check table. However, it allows you to transfer the values of more than one parameter.

  7. Search help for a field

Search helps can also be directly attached to a field of a structure or a database table. This has the highest priority, and is always displayed for input help. When you attach the search help, you should therefore ensure that it only offers values that are also in the check table, otherwise errors may occur in the automatic input checks.

Search Helps and Value Transport

Search helps have an interface (search help parameters), which determines which entries, already made by the user on the screen, should be used when compiling the hit list, and the screen fields that should be filled when the user chooses an entry. The parameters of a search help are divided into import and export parameters. Parameters can also be both import and export parameters simultaneously.

When the user starts the input help, the contents of the fields on the screen are passed to the import parameters of the search help. If a search help is assigned to a data element or directly to a screen field, only one search help parameter is assigned to the field, and values are only transported from the field to this parameter. If the search help is assigned to a table or structure field, or to the check table of the field, there may be more than one parameter of the search help that has to be filled with values. When the input help is started and the search help is assigned to a table or structure field, the system tries to find a field with the same name as each import parameter of the search help. Wherever it finds an identically-named field, the field contents are transferred to the search help parameter.

When the user selects a line from the hit list of the search help, the system transfers values from the export parameters of the search help to the corresponding screen fields. Values from the hit list are only returned to fields on the screen that are linked with an export parameter of the search help and are ready for input.

Changing Search Helps

In exceptional cases, you can modify the standard flow of an input help using a search help exit. A search help exit is a function module with a predefined interface. You can call it at defined points within the input help process. The search help exit allows you to store your own program logic that either steers the subsequent processing or replaces it altogether.

The function module can change the attributes of the search help, the selection options that are used to preselect the hit list, the hit list itself, and also the subsequent processing steps.

All search help exits must have the same interface as the function module F4IF_SHLP_EXIT_EXAMPLE. However, you can define any number of additional optional parameters, especially exporting parameters. For further information about the interface, refer to the function module documentation.

If you have assigned a search help exit to a search help, it is called by the help processor at the following points. They are the points at which the user can interact with the input help, since these are the points at which you can best change the flow of the search help in the interests of the user:

  1. Before the dialog box for selecting the search path is displayed.

    2. At the SELONE event (collective search helps only). This makes it possible to make the search help dependent on the transaction, on other system variables, or even on the state of the radio buttons on the screen. (This is the only event in which the search help exit is called for collective search helps. All other events call the search help exit for the selected elementary search help.)

  2. After an elementary search help has been selected (event PRESEL1).

    3. Here, you can change the assignment of the search help to the screen by, for example, changing the way in which the search help parameters are assigned to screen fields.

  3. Before the dialog box for entering search conditions is displayed.

    4. (PRESEL event). This enables you to change the contents of the dialog box, or to suppress it altogether.

  4. Before data is selected

    5. (SELECT event). Although the value selection contains no user interaction, it can still be overridden either partially or fully by the search help exit. This may be necessary if it not possible to read the data using a SELECT statement for a table or view.

  5. Before the hit list is displayed

    6. (DISP event). Here, you can affect how the hit list is displayed by, for example, suppressing certain lines or columns of the list depending on the authorizations of the user.

  6. Before the line selected by the user is returned to the screen

(RETURN event). This can make sense if the subsequent flow of the transaction is to depend on the value selected by the user. A typical use of this event would be to set SPA/GPA parameters.

Certain search help functions are requested repeatedly in similar ways. One example of this is the possibility to set the search help that will be used dynamically. Standard function modules have been written for these cases, which you can use either directly as search help exits, or call from within a search help exit. Such function modules all have the prefix F4UT_.

The Role of Domain Value Tables

Prior to Release 4.0, it was possible to use the value table of a domain to provide input help. This is no longer possible, primarily because unexpected results could occur if the value table had more than one key field. It was not possible to restrict the other key fields, which meant that the environment of the field was not considered, as is normal with check tables.

In cases where this kind of value help was appropriate, you can reconstruct it by creating a search help for the data elements that use the domain in question, and using the value table as the selection method.

Example

Input help from the ABAP Dictionary.

REPORT DEMO_DYNPRO_F4_HELP_DICTIONARY.

TABLES DEMOF4HELP.

CALL SCREEN 100.

MODULE CANCEL INPUT.
  LEAVE PROGRAM.
ENDMODULE.

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

The components of the ABAP Dictionary structure DEMOF4HELP 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.

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