FAQs: Field exits (CMOD)

1. The field exit was created with CMOD, but is not processed when the screen is called.

• Field exits can be defined only for data elements whose name is shorter than 19 characters. The name of the data element plus the prefix "FIELD_EXIT_" must not exceed the maximum length of a function module name (30).

• Since the field exit is not processed until PAI, an action must be triggered on the screen (choose enter, save, and so on).

• Set the profile parameter abap/fieldexit = YES and restart the system.

• After activating the function module FIELD_EXIT... and the field exit, leave the transaction on whose screen you want to execute the field exit. The relevant screen is only generated when the transaction is called.

• Do not work on different application servers since there may be some delay before the field exit is activated.

• The profile parameter must be set on all or no application servers.

• If the field exit is to only be active on specific screens, check whether you chose the correct program and the correct screen number (take care with subscreens).

• Use transaction SE51 to generate the screen on which the exit should be active. It is possible that it was not correctly generated. If you want to be sure that all screens that use the data element are regenerated, you can copy the report rsmodfdg from the correction instructions and start it with transaction SE38. The report uses the affected data element as the input parameter and regenerates all screens that use the data element.

• Use transaction SE51 and choose 'Field list' to check that the screen field actually has a reference to a data element. In the name of the field exit, use the name of the data element and not the field name.

• After the transport, field exits are marked as active but are not processed. Tip: First try to deactivate the field exit once more and then activate it again.

2. How is performance affected by setting abap/field exit?

• If a screen is generated and the profile parameter is set, a check is run on two tables (TDDIR, TDDIRS) to see whether a field exit must be generated for the respective field. The screen load is, in practice, only generated after an update when the screen is selected. The user should not notice any difference in the speed, as the screen generation is very fast.

3. Can you read the contents of other screen fields in the field exit?

• In principle, every field exit can store its value in the global variables of the function group (TOP) and make them available to other field exits. Note that field exits are always called, not only if an entry is made in the field or if the field is empty. In addition, it is not possible to make any assumptions about the order in which the field exits will be called in the future.

4. How does the field exit behave on step loop fields ?

• After the user has entered data, the field exit is called in PAI as often as there are visible fields in the step loop. The system variable SY-STEPL is incremented in this case. If a new value is assigned to the field, it is displayed in the module between LOOP. and ENDLOOP. This module is also called once for each visible step loop line.

5. Can field exits be debugged ?

• No. Field exits must be tested separately in the development environment. With errors that occur in the screen environment only, it is useful to write relevant variables to the file system using TRANSFER..., and then evaluate them there.

6. What should be done if the field contents are no longer transported to ABAP/4?

• Check whether you assign a value to the field OUTPUT.

7. When is the field exit called if a conversion exit is attached to the data element?

• The field exit is called after the conversion exit. This means that the INPUT field receives the data in the same format as the ABAP/4 program receives it.

8. Although a global field exit is inactive, a function module is called that does not exist (for example, FIELD_EXIT_PROGRAMM_@). This can lead to an ABAP dump error when function module FIELD_EXIT_<data element name> is called.

• This is an error in the kernel that no longer occurs as of Release 3.0C. As a temporary measure, you can assign a program and a screen that do not exist to the field exit, and then activate the field exit.

• Due to performance reasons, the active/inactive indicator is stored in the screenload. This can cause inconsistencies between source and load. Generate the affected screen with transaction SE51. If you want to be sure that all screens that use the data element are regenerated, you can transfer the report rsmodfdg from the correction instructions and start it with SE38. The report uses the affected data element as the input parameter and regenerates all screens that use the data element.

9. The field exit is not visible in CMOD, although it was created.

• If you want to create a field exit for a data element, a function module is proposed with the name FIELD_EXIT_<data_element>. This function module must exist for the field exit to work. If you do not create this function module, but create one with a suffix, the data element is not displayed in CMOD.

10. The field exit is not executed although it is active.

• Fields that do not have the 'Input field' attribute usually do not trigger a field exit. The field exit is designed to allow an extended input check. It is therefore only called for input fields, even if they are not ready for input at application runtime using LOOP AT SCREEN. This rule does not apply, however, if the field is located within a steploop. Here, the field exit will be always activated, even if the field is invisible.

• Field exits can only be executed for fields that are directly related to the dictionary. If the relation is indirect, for example using an ABAP declaration (<fieldname> LIKE <dictionary element>), the field exit cannot be executed.

11. Field exits do not work on selection screens.

• Results from the previous item, since selection screens use ABAP-internal fields and not the original dictionary fields.

12. Field exists do not work on check buttons.

• Field exits are only intended for input fields. Since check buttons are consideed graphical elements, you cannot install field exits on them.

13. How can all screens that use a data element be generated?

• If you want to be sure that all screens that use a specific data element are regenerated, you can transfer the report rsmodfdg from the correction instructions into a customer report (for example, zsmodfdg). The report regenerates all screens. You can therefore ensure that active field exits refer to screens, and that inactive exits cannot be called on any screen. The report uses the affected data element as the input parameter. The affected data element is in the name of the exit: FIELD_EXIT_<data element name>.

14. Restriction of usage

• The field exit technology was developed for input fields on screens and cannot be used for other/new screen elements. This means that this technology does not offer support for the new ScreenPainter elements such as graphical elements (for example, checkbuttons, radiobuttons, dropdown list boxes), controls (except for table controls, which are supported like a step loop), or selection screens.