INTRODUCITON TO SCREEN PROGRAMMINGN SAP

Screens allow you to enter and to display data.

One of their strengths is that they can combine with the ABAP Dictionary to allow you to check the consistency of the data that a user has entered.

Screens allow you to create user-friendly dialogs with pushbuttons, tabstrip controls, table controls, and other graphical elements.

Let us look at a simple dialog program with a selection screen as its initial screen and a screen for displaying information for a selected data record.

When the program starts, the system loads its program context and prepares memory space for the program data objects. The selection screen is displayed.

The user enters data on the selection screen and chooses Execute.

In a processing block, the program reads data from the database. To do so, it passes information about the data requested by the user to the database. The database fills a structure with the required data record.

The processing logic then calls a screen. This triggers a processing block belonging to the screen called Process Before Output (or PBO). Once the PBO has been processed, the data is transferred to a structure that serves as an interface to the screen. It is then transferred to the screen and displayed.

Any user action on the screen (pressing enter, choosing a menu entry, clicking a pushbutton, ... ) returns control to the runtime system. The screen fields are then transported into the structure that serves as the interface between screen and program, and the runtime system triggers another processing block belonging to the screen, which is always processed after a user interaction, and is called Process After Input (or PAI).

You can use the User settings icon (on the far right hand side of the standard toolbar) to configure the R/3 window according to your own preferences.

You can:

• Change the colors of various elements of the R/3 interface
• Change the font of texts displayed in the system
• Modify the R/3 window (for example, hide the standard toolbar or restore the default window size • Show or hide grid lines in lists
• Change the cursor behavior

The changes you make to the user settings are stored on your presentation server, not in the R/3 System.

The screen objects text field, input/output field, status icon, group box, radio button, checkbox, and pushbutton all have general attributes, Dictionary attributes, program attributes, and display attributes.

The objects subscreen, tabstrip control and table control have general attributes, and special attributes relating to the respective object type.

We can divide the attributes of an object into Statically definable attributes that cannot be changed dynamically Statically definable attributes that can be changed dynamically Attributes that can only be changed dynamically.

At the beginning of the PBO, the runtime system reads the statically-created and dynamically modifiable attributes of each screen object on the screen into a system table with the line type SCREEN.

The slide shows the assignment of the fields in the system table SCREEN to the names of the statically created attributes of the screen objects.

When a screen is processed, the system table SCREEN contains an entry for each screen object that has been created in the Screen Painter for that screen.

It is initialized in the PBO of each screen, and is filled with the screen objects belonging to that screen.

You can change the dynamically-modifiable attributes of the elements on the screen using the construction

LOOP AT SCREEN. ... ENDLOOP.

in a PBO module. To do this, you use the structure SCREEN, which is created automatically by the system, and filled with the values of each successive line of the system table in the LOOP. Active attributes have the value '1', inactive attributes have the value '0'. To change the system table, use MODIFY SCREEN. within the LOOP.

To find the object whose attributes you want to modify, you can use a LOOP on the SCREEN table, and query one of the following fields: SCREEN-NAME, SCREEN-GROUP1 to SCREEN-GROUP4.

Dynamic changes to the attributes of screen objects are temporary.

Using this technique to modify the attributes of a screen object (for example, to change whether an input/output field is ready for input), you can replace long sequences of separate screens, which are more costly in terms of both programming time and runtime.

If you want to change the attributes of several attributes at once at runtime, you can include them in a modification group. To do this, enter the same three-character group name in one of the fields SCREEN-GROUP1 through SCREEN-GROUP4 of each element.

Each object can belong to up to four modification groups. You assign the group names in the element list or layout editor in the Screen Painter.

You must program your screen modifications in a module that is processed during the PROCESS BEFORE OUTPUT processing block.

You use a loop throught the table SCREEN to change the attributes of an object or a group of objects. (LOOP AT SCREEN WHERE . . . and READ TABLE SCREEN are not supported. )

To activate and deactivate attributes, assign the value 1 (active) or 0 (inactive), and save your changes using the MODIFY SCREEN statement.

Note that objects you have defined statically in the Screen Painter as invisible cannot be reactivated with SCREEN-ACTIVE = 1. However, objects that you have statically defined as visible in the Screen Painter can dynamically be made invisible. SCREEN-ACTIVE = 0 has the same effect as the following three statements:
SCREEN-INVISIBLE = 1, SCREEN-INPUT = 0, SCREEN-OUTPUT = 0.

A screen consists of the input/output mask (layout), the screen attributes, and the screen flow logic. For further information about how to program screen flow logic, refer to the ABAP User's Guide.

Screens have four components: the screen mask, the screen attributes, the element list, and the flow logic. The flow logic contains flow logic code (not ABAP statements).

Screens are containers for other screen objects.

Each screen has a set of administration attributes that specify its type, size, and the subsequent screen. It also has settings that influence other properties of the screen and of its components.

The administration attributes Program and Screen number identify the screen by its number and the program to which it belongs.

Screen numbers greater than 9000 are reserved for SAP customers. Screen numbers 1000 through 1010 are reserved for the maintenance screens of ABAP Dictionary tables and the standard selection screens of reports.

The screen type identifies the purpose of the screen. Certain other special attributes of a screen and its components depend on this attribute.

The "Next screen" attribute allows you to specify the screen that should be processed after the current screen in a fixed sequence.

When you create a screen, you must:
Set the general screen attributes (on the attribute screen)
Design the screen layout (in the layout editor)
Set the field attributes (in the field list)
Write the flow logic (in the flow logic editor).

To create a screen from the object list in the Object Navigator, create a new development object with the type Screen. Position the cursor on Screens and right-click.

The Object Navigator automatically opens the Screen Painter.

When you create a screen, you first have to enter its attributes. Enter a screen number, a short text, and a screen type. You will normally use the screen type Normal. You can specify the number of the next screen in the Next screen field.

If you enter 0 (or nothing) for the next screen, the system resumes processing from the point at which the screen was called once it has finished processing the screen itself.

You can also create a screen by writing a CALL SCREEN statement in the ABAP Editor and then double -clicking the screen number .

You usually define screen fields by adopting the corresponding field descriptions from the ABAP Dictionary. However, you can also use field descriptions that you have defined in your program. In order to do this, you must generate the program first.

You can use the key word texts and templates either together or separately.

The graphical layout editor provides an easy way of defining the various screen elements (such as input/output fields, key word texts, boxes, and so on). You simply choose the element you require, and position it on the screen using the mouse.

To delete a screen element, select it, and choose Delete.

You can move elements on the screen by dragging and dropping them with the mouse.

Note: The graphical layout editor is available under Windows NT, Windows 95 and UNIX.
If you use a different operating system, you must use the alphanumeric Screen Painter.

Screens have their own set of keywords that you use in the PBO and PAI events of the flow logic.

In the flow logic, you write MODULE calls. The modules are components of the same ABAP program. They contain the ABAP statements that you want to execute.

You can create a module by double -clicking the module name in the flow logic Editor.

To create a module from the object list in the Object Navigator, choose the development module 'PBO module' or 'PAI module'.

You can call the same module from more than one screen. If the processing depends on the screen number, you can retrieve the current screen number from the system field sy-dynnr.

Note that the modules you call in the PBO processing block must be defined using the MODULE OUTPUT statement; modules that you define using the statement MODULE... INPUT can only be called in the PAI event.

In order for a screen and its ABAP program to be able to communicate, the fields on the screen and the corresponding fields in the program MUST HAVE IDENTICAL NAMES.

After it has processed all of the modules in the PBO processing block, the system copies the contents of the fields in the ABAP work area to their corresponding fields in the screen work area.

Before it processes the first module in the PAI processing block, the system copies the contents of the fields in the screen work area to their corresponding fields in the ABAP work area.

You should use your own structures (SDYN_CONN, …) for transporting data between the screen and the ABAP program. This ensures that the data being transported from the screen to the program and vice versa is exactly the data that you want.

You can establish a static sequence of screens by entering a value in the Next screen field of the screen attributes.

If you enter 0 (or no value) as the next screen, the system resumes processing from the point at which the screen was initiated, once it has finished processing the screen itself.

The SET SCREEN statement temporarily overwrites the Next screen attribute.

The screen must belong to the same program.

The next screen is processed either when the current screen processing ends, or when you terminate it using the LEAVE SCREEN statement.

To specify the next screen and leave the current screen in a single step, use the
LEAVE TO SCREEN statement.

To interrupt processing of the current screen and branch to a new screen (or sequence of screens), use the CALL SCREEN statement. The screen must belong to the same program.

In the program, the system constructs a stack. The stack has to be destroyed before the end of the program.

To return to the statement following the CALL SCREEN statement, you can use either SET SCREEN 0, LEAVE SCREEN, or LEAVE TO SCREEN 0. The screen that called the other screen is then processed further.

If you use the above statements outside of a call chain, the program terminates, and control returns to the point from which it was called. You can also terminate a program using the ABAP statement LEAVE PROGRAM.

In the CALL SCREEN statement, you can use the STARTING AT and ENDING AT additions to specify the position and size of the screen that you are calling. The screen in the CALL SCREEN statement must be defined as a modal dialog box.

If you omit the ENDING AT statement, the size of the dialog box is determined by the Used size in its screen attributes.

If you use the ENDING AT addition, the system displays as much of the dialog box as will fit into the available space. If there is not enough room to show the entire dialog box, it appears with scrollbars.

The starting position (origin) of every SAP window is its top left-hand corner.

The values that you pass to lc, ur, rc, and lr in the statement
CALL SCREN STARTING AT lc ur ENDING AT rc lr
refer to the R/3 window in which you display the dialog box (on the slide, screen 100).

When the system displays a screen, it automatically places the cursor in the first input field. If you want the cursor always to appear in a different field, you can enter the corresponding object name in the Cursor position field of the screen attributes.

You can also tell the system in the PBO event to position the cursor in a particular field. This makes your application more user-friendly.

You can set the field in which the cursor should appear in the program.
To do this, use the ABAP statement SET CURSOR FIELD OFFSET .

can be a unique name in quotation marks, or a variable containing the object name. To place the cursor at a certain position within a field, use the OFFSET parameter, specifying the required position in .

The system then places the cursor at the corresponding offset position, counting from the beginning of the field.

A GUI status is made up of a menu bar, a standard toolbar, an application toolbar, and of function key settings. A single screen can have more than one status. You should use a module set_status_ in the PBO (Process Before Output) event of each of your screens to assign a GUI status and a GUI title to it.

There are three ways to create a status: from the object list in the Objet Navigator, from the Menu Painter, or by forward navigation from the ABAP Editor. The status type describes the technical attributes of the status. Choose Dialog status if you want use the status with a screen in fullscreen mode, and dialog box, if you are going to use it with a dialog box. Context menus are special menus that you can attach to the right-hand mouse button. They are described in a separate unit.

When you change a status, you must activate it before the changes become visible.

To ensure consistency, you should reuse existing menu bars, application toolbars, and key settings wherever possible. The Menu Painter administers the links you establish between these objects so that any changes apply to all other statuses that use them. There is also a set of standard menu entries that you can use as a template and modify.

When you assign functions to the reserved function keys in the standard toolbar, you should adhere to the SAP standards.

When the user triggers a function with type ' ' using a pushbutton, menu entry, or function key, the system places the relevant function code in the OK_CODE field of the screen.

To allow you to process this field in the PAI event, you must assign a name to the field, which you enter in the element list in the Screen Painter. You must then create a field in your ABAP program with the same name. During the automatic field transport at the beginning of the PAI event, the function code is passed from the screen to the corresponding field in the program.

To avoid the function code le ading to unexpected processing steps on the next screen (ENTER does not usually change the OK_CODE field), you should initialize the function code field in the ABAP program before leaving the screen, otherwise it will be transported back to the screen automatically in the PBO event.