TAW10 - Introduction to Screen Programming

USER DIALOGS

A user dialog is a form of interaction between the user and the program.
User dialogs include actions, such as
entering data;

choosing a menu item;

clicking a button; or

selecting or double-clicking a list entry.



SAP PROGRAMMING MODEL

The SAP programming single-screen transaction combines the input screen and the data screen in a single window.
You can also switch between the three modes, Create, Change, and Display. You can directly access the objects to be edited, which is also an added advantage with the single-screen transaction feature. Another advantage is that the system retains the context after you save the data to the database.

EXAMPLE SCREEN LAYOUT: TRANSACTION FB60

The example screen layout depicts SAP Transaction FB60.
The screen consists of four divisions, and it is important to note that all the four divisions have different sets of functions:
Object Selection is the field where the user can edit the object by selecting the required object from the tree structure.

Object ID is the field in which you edit object attributes.

Details of Object is the area where you can select the subobjects for editing.

Application Functions is the field in which options are listed. You can choose options like Display (for showing and hiding screen areas), Create new object (with the templates), or Change session (to toggle between different sessions of a program).

EXCERCISE: SCREEN PROGRAMMING

This slide depicts various screens represented by numbers such as 100, 110, and 120.
In the SAP system, a screen is handled by the number by which it is represented.
Let us now look at the features of screen programming.
The Process flight screen consists of
two input fields;

radio buttons for the selection of the required criteria, based on which the required screen or data is processed or retrieved; and

a tabstrip, which has three tabs.

You can list the functions of each of the three tabs:
Selection of the tab Connection calls the screen 110 (View flight data).

Selection of the tab Aircraft calls the screen 120 (View technical details for aircraft).

Selection of the tab Bookings calls the screen 130 (Maintain bookings).

ABAP PROGRAM TYPES

ABAP has several program types, such as complete and incomplete. Types 1 and M, which can be executed, are of the former type. Incomplete types can be used within other programs, but they cannot be executed as such.
Type 1, the Executable program, runs directly from the ABAP Editor – SE38. A set of processing blocks is processed in a predefined chronological order. These programs usually create and display lists or output.
Type M, the Module pool program, is executed by means of a transaction code, in which you specify an initial screen or selection. You handle the subsequent screens, either statically in the screen attributes or dynamically in the program.
Some ABAP programs cannot be executed independently. They serve as containers for modularization units, which are called from other programs. Let us familiarize ourselves with these exceptions:
Type F, the Function group, contains function modules, local data declarations, and screens.

Type I, the Include program, contains any of the ABAP statements or declarations.

Type J, the Interface pool, contains global interfaces and local declarations.

Type K, the Class pool, contains global classes and local data declarations.



PROGRAM ORGANIZATION

While creating programs, you should keep certain points in mind, as they can affect program creation:
In the simplest of cases, your program consists of a single source that contains all the necessary processing blocks. However, you must use include programs. With these, your program code is easier to understand, and you can reuse parts of it in other programs, such as data declarations.

Whenever you create a program from the Object Navigator, the system proposes to create it With Top include, in order to create clearly structured programs.

When you create processing blocks, the system automatically asks you to name the specific Include program, in which it should place the corresponding source code.

If you specify an Include program that does not yet exist, the system creates it and inserts a corresponding INCLUDE statement in the main program.

TABLE OF FLIGHT DATA MODEL

The slide, Tables of the Flight Data Model, presents you with a view of the tables and fields, which share primary key and foreign key relationships.
All the columns in the table include the primary key MANDT, which is the client login.
The connection table – SPFLI – contains the connection data, listing some primary keys:
CARRID identifies the airline.

CONNID shows the connection code.

AIRFROM and AIRPTO identify the departure and arrival airports.

The field also contains other keys:
CITY TO and CITY FROM refer to the arrival and departure cities.

COUNTRYTO specifies the destination country.

COUNTRYFR indicates the country of origin of the flight.

FLTIME depicts the time of the flight.

The flight table – SFLIGHT – contains the flight data and lists primary keys, as well as other keys:
CARRID and CONNID

FLDATE

SEATSMAX and SEATSOCC (for maximum seating capacity and number of seats occupied, respectively)

PRICE

CURRENCY

PLANETYPE (for specifying the type of plane)

The table SBOOK lists important fields:
CARRID, CONNID, and FLDATE

BOOKID (for specifying the reservation number)

CUSTOMID (for indicating the customer number)

The last table – SAPLANE – lists apart from the primary key, PLANETYPE, technical data in other fields, such as SEATSMAX and WEIGHT.

SCREEN

Screens
are freely definable objects;

can be used to display or enter information through input and output fields, lists, and so on; and

are a form of dialog between the user and the ABAP program.

STRENGTHS OF SCREEN

Screens are one of the primary elements of module pool programming.
Screens allow you to Input and output data.
You can perform validation and consistency checks for the input data (referring the ABAP Dictionary), using screens.
You can also create user-friendly dialogs with push buttons, tabstrip controls, table controls, and other graphical elements, with the help of screens.

SCREEN IN DIALOG PROGRAM

This slide depicts the various screens that are available in a module pool program. It also shows the order in which the screens are processed.
We take the example of a dialog program with a selection screen as its initial screen and another screen for displaying the information, which is the output for a selected data record.
When the program is run through a transaction, the system loads its program context and prepares memory space for the program data objects. The selection screen is then displayed.
After giving the input on the selection screen, the user chooses the Execute option. The respective code, which is the processing block, reads the selection screen input data. Then the program, instructed by the input data, reads the data from the database based on the input data. Once this is done, based on the user input, the required structure is populated with the required data.
Subsequently, a screen is called by the processing logic. This triggers the PBO or Process Before Output event. After the processing of the PBO, the data is transferred to the structure that serves as the interface to the screen. From the structure the data is then transferred to the display screen.
Any user action performed on the screen, such as entering data, choosing a menu entry, or clicking a pushbutton, returns control to the run time. The screen fields are then transported into the structure that serves as the interface between the screen and the program. The runtime then triggers another processing block belonging to the screen, which is called PAI (Process After Input).
The PAI event is always processed after a user interaction.

ATTRIBUTE OF SCREEN ELEMENT (KEY)

The attributes of screen elements are derived from General, Dictionary, Program, or Display attributes.
The attributes of elements can be divided into three types:
Statically definable attributes that cannot be changed dynamically

Statically definable attributes that can be changed dynamically

Attributes that can only be changed dynamically

SCREEN: ATTRIBUTE

A screen has Administrative, Type, Size, Sequence, and Settings attributes.
Each of these attributes imparts a different functionality:
Admin attributes, such as Program and Screen number, identify screens by their numbers and the programs they belong to.
Examples of other admin attributes are Short description, Screen groups (sometimes certain screens are grouped together), Status, and Original language.

Type attributes, such as Normal, Subscreen, Modal Dialog Box, and Selection screen, describe the purpose of the screen.

Size is an attribute that defines whether the screen is Static or Dynamic.

Sequence defines the sequence in which the screen is meant to appear.

Settings attributes may be listed as Cursor position (which determines where the cursor should be on the screen), Hold data (which specifies whether the data is to be held or not), Runtime compression, Context menu, and so on.

DEFINING AND MANAGING SCREEN

You must keep some points in mind while using screens:
A screen consists of a screen image and its flow logic.

The flow logic controls the way the screen image is processed.

Screens have four components – screen masks, screen attributes, the element list, and the flow logic.

The flow logic contains the flow logic code and not ABAP statements.

Screens are containers for other screen elements.

CREATING SCREEN

Creating screens involves a specific process, as depicted in this slide:
A screen is created in the screen painter.

In the first step, you define the screen attributes.

Next, you can design the screen layout in the layout editor.

Use the field list to set the field attributes.

Finally, you write the flow logic in the flow logic editor.

CREATING SCREEN: SCREEN ATTRIBUTE

You can create a screen from the object list in the Object Navigator. You begin by creating a new development object with the type Screen.
Next, position the cursor on Screens and right-click.
The Object Navigator automatically opens the Screen Painter.
On creating the screen, enter the attributes, such as a screen number, short text, and a screen type.
You can specify the number of the next screen in the Next screen field.

CREATING SCREEN: LAYOUT

Field descriptions from the ABAP Dictionary Screen are the basis for defining screen elements.
However, you can also use the field descriptions that you defined in your program.
In the graphical layout editor, you can define the various screen elements (such as input/output fields, keyword texts, and boxes). You simply choose the element you require, and position it on the screen using the mouse.
You can choose Delete to delete a screen element.
You can drag and drop elements on the screen, using the mouse.

CREATING SCREEN: THE ELEMENT LIST

The Screen Painter contains an element list with six views to set the attributes of all the screen elements.
You can also display all the attributes for a single element from any of the lists, using the Attributes function.

CREATING SCREEN: FLOW LOGIC

Flow logic consists of module calls. The modules are components of the same ABAP program, which contains the ABAP statements that you want to execute.
A module can be created by double-clicking the module name in the flow logic editor. Then you can place your piece of code in the module that was created.
If you are using the Object Navigator – Transaction SE 80 for the application development – you can choose the PAI module or PBO module or both.

DATA VISIBILITY

The program flow within a module is handled by the ABAP processor.
The DYNP processor controls the flow logic and prepares the data to be displayed on the screen.
During this process, you see two sets of data. You can create global fields in the TOP include, using declaration statements such as TABLE or DATA.
The system recognizes fields from the element list, which help retrieve data to display on the screen, as well as to transport your changed data. This occurs automatically, when you get fields from the ABAP Dictionary or from the program in the layout editor.
A system program copies the data, generated from different sets of data fields. The system also compares the identically named fields of DYNP and ABAP.

DATA EXCHANGE: SCREEN - ABAP PROGRAMS

For a screen and its ABAP program to be able to communicate during dialog programming, the field names should be identical in the screen fields and the program fields.
After the processing of all the modules in the PBO, the contents of the fields in the ABAP work area are moved to the corresponding fields in the screen work area.
Before the first module in the PAI processing block, the data in screen fields is moved to the corresponding fields in the ABAP work area.
This ensures that the data being transported from the screen to the program and vice versa is exactly the data that you want.

MODIFYING ATTRIBUTE DYNAMICALY: EXAMPLE

The technique to dynamically modify the attributes of a screen element helps you to replace long sequences of separate screens. For example, you can change the attribute of a screen element to decide whether an input/output field is ready for input.

DYNAMICALY MODIFIABLE STATIC ATRIBUTES

This slide depicts the fields or attributes of the screen table.
These screen attributes have their own individual meanings:
Screen-Name is the unique identifier for a screen element on one screen.

Screen-Groups 1, 2, 3, and 4 refer to a group of fields related logically and grouped together. You can set this attribute dynamically.

Screen-Length defines the length of the field on the screen.

Screen-Input and Screen-Output are program attributes that assign the input and output fields on the screen.

Screen-Required defines a mandatory field on the screen.

Screen-Intensified is for intensifying the display of any field on the screen.

Screen-Invisible is also a display attribute, used when certain fields are made visible only under certain conditions, or after entering the correct input in some logically related fields.

Screen-Active enables the screen to be active or inactive on the basis of requisite inputs or certain conditional requirements.

THE SCREEN SYSTEM TABLE

The SCREEN system table is the system table with line type SCREEN. It contains an entry for each element created in the Screen Painter while the screen was being processed.

INITIALIZING SCREEN SYSTEM TABLES

As a first step, a system program copies the statically defined attributes of the individual screen elements into the SCREEN system table.
As a result, the SCREEN system table is initialized at the start of the event PBO for the current screen.
You can change the dynamically modifiable attributes on the screen in a module at the event PBO, using the requisite statements.

MODIFICATION GROUP ATTRIBUTE

The Screen Painter helps you group the screen elements (whose attributes you want to change) together in a modification group.
You can change the attributes of these elements simultaneously at runtime.
In the Screen Painter, you can group together the elements that you want to change within a single processing step.
You enter a group name for each of the relevant elements in one of the fields, Group 1 to Group 4.
Choose any three-character sequence for the group name.
Assign the elements to a modification group either in the element list or in the layout editor of the Screen Painter.
Each element can belong to four modification groups at the most.

MODIFYING ATTRIBUTES DYNAMICALY: PROGRAM

You can code for screen modifications in a module of the PBO processing block.
To change the attributes of an element or a group of elements, you use a loop through the table screen.
Assign the value 1 to activate and the value 0 to deactivate a particular attribute for a screen element.
You save the changes using the MODIFY SCREEN statement.

DETERMINING THE NEXT SCREEN

Complex applications may involve multiple screens. The initial screen is defined when the transaction code is created.
The next screen is usually dynamically determined, depending upon the user input.

STATIC SCREEN SEQUENCES

To maintain a static sequence of screens, you enter a value in the Next screen field of Screen Attributes.

SETTING THE NEXT SCREEN DYNAMICALY

To set the sequence dynamically, you use specific statements or commands:
SET SCREEN temporarily overwrites the Next screen attribute.

LEAVE SCREEN helps you terminate a program, after which the next screen is processed.

LEAVE TO SCREEN enables you to specify the next screen and leave the current screen in a single step.

INSERTING THE SCREEN SEQUENCE

You use a CALL SCREEN statement, to insert a screen sequence.
This will add another layer to the stack.

INSERTING A SEQUENCE OF SCREEN DYNAMICALLY

The statement CALL SCREEN helps you to branch into a new screen from the current screen without processing the current screen.
To recover control after the CALL SCREEN statement, you use the statements SET SCREEN 0, LEAVE SCREEN, or LEAVE SCREEN 0.
This ensures that the screen that called the other screen is processed further.
The latter three statements, outside the call chain, terminate the program.
Control returns to the point at which you used the CALL SCREEN statement.
The statement LEAVE PROGRAM will also terminate the program.

CALLING DIALOG BOX DINAMICALLY

You set the Screen Attributes for type in the Modal dialog box, while creating the screen in the Screen Painter.
To specify the position and the size of the screen called in the CALL SCREEN statement, you use the additions STARTING AT and ENDING AT.
If you do not use the ENDING AT addition, the size of the dialog box is determined by Used size or Occupied size in its screen attributes.

WINDOW COORDINATES

The starting position or origin of every SAP system window is its top left-hand corner. This screenshot depicts the statement,
CALL SCREEN <screen 101>
STARTING AT left_col upper_row.
ENDING AT right_col lower_row.
The values that are used for the variables left_col, upper_row, right_col, and lower_row in the statement relate to the R/3 system screen (100 in this case), from which you display the second screen (101) with the statement CALL SCREEN.

SETTING THE CURSOR POSITION DYNAMICALLY

One method to set cursor position dynamically is by instructing the system in the PBO event to position the cursor in a particular field.
This makes your application easier to use.
A specific ABAP statement also serves the same purpose:
SET CURSOR FIELD <object_name> OFFSET <position>
Choose a unique name (in quotation marks) for <field_name>. You can also use a variable containing the object name.