BASICS OF INTERACTIVE REPORTS XXXV

BASICS OF INTERACTIVE REPORTS:


When the user starts an executable (type 1) program, the program context and memory space for data objects (variables and structures) are made available on the application server. The subsequent program flow is controlled by the ABAP runtime system.

If the program contains a selection screen, the ABAP runtime system sends it to the presentation server at the start of the program.

Once the user has finished entering data on the selection screen, he or she chooses 'Execute' to tell the system to start processing the rest of the program. The data entered on the selection screen is automatically placed in the corresponding data objects. The ABAP runtime system takes over control of the program.

In this simple example, there is only one ABAP processing block to be processed by the runtime system.

This processing block contains a read access to the database. The program sends information to the database about the records that should be read.

The database returns the required database records and the runtime system ensures that the data is placed in the relevant data objects.

The list output is also programmed in the processing block. After the processing block finishes, the runtime system sends the list as a screen to the presentation server.

Selection screens allow users to enter ranges of values. They are normally used to define the set of data that needs to be read from the database.

As well as the normal graphical elements (group boxes, checkboxes, radio buttons, and so on) that you use in screens, selection screens also have input/output fields (PARAMETERS) and special groups of input/output fields (SELECT-OPTIONS).

You place a single input/output field on the selection screen using the PARAMETERS statement.

You can use the SELECT-OPTIONS statement to place a group of fields on the screen that allows users to enter complex selections. The selection may be a single value, or any form of interval (discrete or continuous). You can also use patterns. (See following slides).

You can create variants for selection screens.

If you declare an input field with reference to an ABAP Dictionary field, any search helps defined for the Dictionary field will be available on the selection screen.

Selection texts can be translated into other languages. They are then displayed in the user's logon language.

Selection ranges are stored in programs using an internal table.

The ABAP statement SELECT-OPTIONS FOR declares an internal table called , containing four fields - SIGN, OPTION, LOW, and HIGH. The fields LOW and HIGH have the same type as the field .

The SIGN field can take the value 'I' (for inclusive) or 'E' (for exclusive).

The OPTION field can contain relational operators, pattern operators, and operators that allow you to enter intervals.

For more information about selection ranges, choose Goto -> Selection screen help from any selection screen.

To define a selection screen, include the required PARAMETERS and SELECT-OPTIONS statements in your data declarations. If you define more selection screens than just the standard selection screen, you must enclose the additional definitions in the statements SELECTIONSCREEN BEGIN OF SCREEN and SELECTION-SCREEN END OF SCREEN where is the number of the selection screen.

For information about other graphical elements that you can place on a sele ction screen, such as group boxes, checkboxes, radio buttons, references to input fields on other selection screens and so on, see the keyword documentation for the SELECTION-SCREEN statement

The standard selection screen is displayed by the ABAP runtime system when the program starts.

User-defined selection screens are displayed when you use the statement CALL SELECTIONSCREEN . This statement sets the return code sy-subrc to zero if the user chooses 'Execute', and to 4 if the user chooses 'Cancel'.

You can also call a selection screen as a modal dialog box. To do this, use the syntax CALL SELECTION-SCREEN STARTING AT ENDING AT where and are the coordinates of the top left-hand corner of the screen. and are the coordinates of the bottom right-hand corner.

Selection screen processing is event-driven. Events are ABAP processing blocks that are called by the runtime system in a particular order and processed sequentially. In the program, each event is introduced by an event keyword. The processing block ends when the next event block starts, or the definition of a subroutine or dialog module occurs.

AT SELECTION-SCREEN OUTPUT is processed before the selection screen is displayed. You can use this event to modify the selection screen dynamically.

AT SELECTION-SCREEN ON HELP-REQUEST FOR and
AT SELECTION-SCREEN ON VALUE-REQUEST FOR allow you to define your own F1 and F4 help.

AT SELECTION-SCREEN is processed when the user presses ENTER or chooses another function on the selection screen. You can use this event to check the values the user entered on the screen. The addition ON... allows you to control which fields or groups of fields should accept input again in the event of an error.

An ABAP program consists of a sequence of processing blocks (events) that are processed by the runtime system in a particular order.

LOAD-OF-PROGRAM is triggered directly after the system has loaded a program with type 1, M, F, or S into an internal session. The processing block is executed once only for each program in each internal session.

INITIALIZATION is processed in executable (type 1) programs, directly before the selection screen is displayed. You can use the corresponding processing block to preassign values to the parameters and selection options on the selection screen.

START-OF-SELECTION is processed after the selection screen has been processed. If you are working with a logical database, the corresponding GET events are triggered after START-OFSELECTION.

END-OF-SELECTION is processed after all of the data has been read, and before the list is displayed.

TOP-OF-PAGE is an event in list-processing. The processing block is always executed when you start a new page in the list.

Once the basic list has been displayed, you can react to possible user actions. Detail lists allow you to distribute the information you want to display across several lists.

This makes the lists easier for the user to understand, and improves performance, since you can delay reading extra information from the database until the user actually requests it.

You can also use additional selection screens to allow the user to enter further restrictions.

For each basic list you can use up to 20 detail lists. Each list is stored in its own list buffer. When the user chooses 'Back' (green arrow) or 'Cancel' (red cross), he or she returns to the previous list.
This action initializes the list buffer of the list level the user just le ft.

When the user chooses 'Exit' (yellow arrow), the system terminates the list processing and returns to the standard selection screen.

The events START-OF-SELECTION, GET, END-OF-SELECTION, TOP-OF-PAGE and END-OFPAGE can be used only to create basic lists.

To create detail lists, use the events AT LINE-SELECTION or AT USER-COMMAND.

Use TOP-OF-PAGE DURING LINE-SELECTION for page headers on detail lists.

Each detail list event exists only once in the program and is shared by all detail lists. You must therefore ensure yourself, within the processing block, that the correct list is created. To do this, use a CASE structure that uses the system field sy-lsind. This system field contains the list index of the list that you are currently generating.

Use the statement HIDE global_field to store the contents of the global data field
global_field for the current line.

If the user selects the line, the data field is automatically filled with the value that you retained for the line.

You do not have to display the field on the list in order to retain its value using HIDE.

The field can be a structure. However, deep structures (structures containing internal tables as components) are not supported.

When the user selects a line on an interactive list, all of the global data fields whose values you stored using the HIDE statement while you were creating the basic list are filled with those values.

The line selection is based on the cursor position when the AT LINE-SELECTION and AT USERCOMMAND events occur. (system field sy-lilli).

If you choose a line using the READ LINE... statement, the values are placed back in the original fields according to the line numbers.

To check whether the user selected a valid line, you can use the fact that the hide area only contains data for valid lines. When you have finished creating the list, initialize a suitable test field. This allows you to check before you create the detail list whether a value from the hide area has been placed in the test field.

Once you have created the detail list, re-initialize the test field to ensure that the user cannot choose an invalid line once he or she returns from the detail list and attempts to select another line for a new detail list.

RELATED POSTS