

Screen program fields, function codes, and field checks

How to generate screen program fields, side effects of function codes, and field checks

This tip comes from ABAP/4: Programming the SAP R/3 System, by Bernd Matzke

How to generate screen program fields

You should always generate screen program fields with a reference to the Data Dictionary. This guarantees the fields are translated correctly. The Field attributes dialog box contains some data about the current Data Dictionary reference. However, the key field and the corresponding input screen may belong to different tables or it may happen that only the key field refers to the Data Dictionary in order to produce a translatable text and the input screen itself refers to another field within the program. You can also generate the Data Dictionary structures for screen programs that contain all the fields required in the screen program.

Side effects of function codes

The function code in a screen program is often stored in a global field in the module pool. Various screen programs use the module pool for this purpose. Problems may arise if you use the CALL command to call another screen program, for example as a dialog box, in the PAI part of a screen program. After you return from the object you found with CALL, the contents of the global field for the fucntion code will probably have changed. This can lead to problems if you have to evaluate this field again in the PAI part after you have used the CALL command. You can avoid such problems by storing all the function code's evaulations for one screen program in a subroutine. You do this by copying it into the local field there. After this, only the local field is involved in evaluations.

Field checks

You only need field checks when you want to save data or to evaluate it further in the next screen program. Therefore it is a good idea to test the transaction code in the modules responsible for field checks and only carry out the checks if these transaction codes really result in the storing of the data. This for example prevents the system from carrying out unnecessary error checks when you call a supplementary dialog box that automatically returns to the main screen.

If one module pool is used for several transactions, you should test the transaction code as well as the function code. If you do this, you can also suppress field checks for transactions that merely display the data.

To read more about these tips, pick up a copy of ABAP/4: Programming the SAP R/3 System.

Dig Deeper on SAP ABAP