Dialog Programming Tutorial

GUI Programming

GUI programming allows for a user to interact with your programs, generally the user will supply parameters into a program and then receive the results via a screen or printed report, however there are more advanced GUI topics that we will also cover in this section.

Programming languages use many tools to interface to users, they could be web based interfaces, GUI specific interfaces or interfaces for other programs, in the below diagram you can see the many interfaces that SAP use to interact with the SAP solution.

We will be looking at the classical user interfaces and the classic dynpros (with implement the MVC (model-view-controller) model which I have briefly discussed in my JSP section).

General Dynpros

Dynpro stands for Dynamic Program, these are the classical user interfaces of an ABAP-based SAP system, it consists of the following

• The screen itself
• Dynpro flow logic
• Dynpro fields

A dynpro is always a component of a function group, an executable program or a module pool, they are created by using the Screen Painter tool, there are also special dynpros which are implicitly built by the runtime environment.

The screen part of the dynpro which is visible and functional for the user, the screen of a general dynpro is defined with the layout editor of the screen painter, where its screen elements are defined. The presentation of the screen is normally viewed in the SAP GUI which is installed on your PC. The screen is capable of using titles, menu bars, standard toolbars, application tool bars, status bar, scroll bars, etc, the screenshot below gives you an idea on what other elements you can use.

The dynpro flow logic is the procedural part of the dynpro and is written in a special language similar to ABAP, the dynpro flow logic is implemented in the ABAP runtime environment just like ABAP programs. There is no declaration part in the flow logic, like the implementation part of an ABAP program, this is divided into processing blocks as below

dynpro processing blocks

PROCESS BEFORE OUTPUT  ... PROCESS AFTER INPUT  ... PROCESS ON HELP-REQUEST  ... PROCESS ON VALUE-REQUEST  ...

• process before output (POB) - is executed directly before sending the screen output
• process after input (PAI) - is executed by each user action action on the screen associated with a function code.
• process on help-request (POH) & process on value-request (POV) - are executed when a user selects field help F1 or input help F4 for a screen element.

In these event blocks a small selection of statements can be used

• call dialog modules of the ABAP program
• control data transport to the ABAP program
• handle error messages
• execute loops through screen tables
• integrate subscreens

A dynpro is a component of an ABAP program which is identified by a unique dynpro number, every dynpro of a program can be called during the programs execution

During the processing of a dynpro, the dynpro controls the ABAP program because the dynpro flow logic calls the programs dialog modules. Dynpros have no parameter interface, instead there is a connection between the dynpro fields and the global data of the ABAP program, for every dynpro field there must be a global data object of the same name in the ABAP program, the transport will transport the data between the dynpro fields and the global data objects.

A dynpro is always part of a sequence, which means that each dynpro has a so-called next-dynpro, you can set this statically or it can be set dynamically in the ABAP program. As you can see in the diagram below you can jump to any screen within the sequence, each sequence (or screen) will be used to collect data from the user.

You can call dynpros outside from your ABAP program through a dialog transaction or within you ABAP program using the call screen statement, a dialog transaction is a transaction in which the transaction code is associated with a dynpro in an ABAP program. You can create dialog transaction in the object navigator using dialog transaction. using transaction code SE93, you can view a dialog transaction, here we can see from the screenshot below that demo_transaction is associated with dynpro 100 of the ABP program sapdemo_transaction (a module pool), this is the initial dynpro of the transaction. When calling a dynpro the PBO is started once the PAI has been reached and finished the next dynpro is called automatically and its PBO is then called this continues for all the sequence. You can use the system field sy-dynnr to obtain the currently active number of the dynpro.

The next dynpro is specified in the screen painter, however you can dynamically overwritten during the dynpro processing by using the below, you can call any dynpro or even itself.

set screen

SET SCREEN dynnr.

To terminate the dynpro sequence you use dynpro number 0, this indicates that you return to executing to the spot just after the location where the first dynpro in the dynpro sequence was called. You can set this number either using the above set screen statement or as the next static number. The shortest dynpro sequence is a single dynpro which is called by a dialog transaction and then branches directly to the next dynpro 0.

I have mentioned the call screen statement which then starts a dynpro sequence, you can have up to 50 dynpro sequences that can be in a single stack that is started by dialog transaction, however common sense will tell you that a program will become very complex the more dynpros in a sequence and hard to debug. You can call a dynpro and have it displayed in a modal dialog box, which means the original will remain visible you specify the starting and ending positions of the modal dialog box, you can stack up to 9 modal dialog boxes, however the next dynpro of 0 is recommended otherwise all dynpros sequence will be displayed in the dialog box.

modal dialog box

CALL SCREEN dynnr  STARTING AT x1 y1  ENDING   AT x2 y2.

Normally the dynpro exists after finishing the PAI processing, however you can take control by executing one of the below statements, the leave screen exists the dynpro and then moves onto the next dynpro in the sequence, the leave to screen move to the specified screen

leave screen, leave to screen

LEAVE SCREEN. LEAVE TO SCREEN.

You can also use the system->status from the top menu bar to display a transaction dynpro screen number and program.

You can create a dynpro using the workbench (transaction code SE80), this is possible for function groups, executable programs or module pools.

When you create the dynpro you are asked for the screen number of this dynpro (left-hand screenshot), once the screen has been created you can change some of the properties like the type (we mentioned modal dialog box above), also you can enter the next dynpro sequence number, in our case it will be 0

if you use the layout button you can edit the dynpro using the layout editor of the screen painter. Here you can layout you screen

To add elements double click on a element (left-hand side) and drop it onto the screen, you name the elements using the name box and even add some text to elements, when you return the main screen and select the elements list tab you will be able to see them, you can then change the properties of them. I am not going to go through all the elements and will leave you to have a play around.

Within the layout editor you can double click on an element to also change the properties

The flow logic uses a programming language similar to ABAP, it consists of just a few keywords, statements that can be used in the events blocks of dynpro flow logic are

• module to call ABAP dialog modules
• field for control of data transport of dynpro fields to ABAP program and error handling
• chain and endchain to group module calls into processing chains
• loop and endloop for the execution of loops over table controls
• call subscreen for integration of a subscreen dynpro

You also have utilities to test and check a screen in the workbench, this allows to to test/check screens without running a separate ABAP program.

In the dynpro logic there are no explicit data declarations with the exception of the OK field which is implicitly generated when a dynpro is created. The data types of dynpro fields are determined either by reference to the ABAP dictionary or by reference to global data objects of the ABAP program. After PBO processing and before sending the screen, there is an automatic data transport of global data objects from the associated ABAP program into dynpro fields of the same name. After a user enters the data into the screen before or during PAI processing there is a data transport in the reverse direction, hence why you must assign unique names to all changeable elements on a screen.

I mentioned the OK field above, this is a 20 character field which is not displayed directly on the dynpro, it is always the last entry in the element list, it is used for actions like clicking a button to transfer the associated function code to the ABAP program. To evaluate the OK field you need a data object of the same name in the program whose type can be determined by referring to the global type sy-ucomm.

A function code is a string of 1 to 20 characters which can be assigned to specific elements of the GUI interface, when an PAI event is trigger the function code is passed to the ABAP program in the system field sy-ucomm or the OK field of the dynpro. You can associate the following with a function code

• Push Buttons
• Checkboxes
• Radio Buttons

You can also use the various bars and buttons of the SAP menu, to manage these you use the so-called GUI status, is a standalone component of the ABAP program and is managed using the menu painter tool, a GUI status manages functions and provides them to the user of the dynpro, all the status types can be defined at the same time in the same ABAP program. In the menu painter you define the functions by entering function codes and function texts and by associating them with the bars of the GUI status, you can even assign the function keys to function codes.

For example in the menu painter we see that F5 is assigned to the press demo function button(left-hand screenshot), this can also be seen when running the program (right-hand screenshot), you can assign other function keys, back, exit and cancel buttons.

To evaluate the function codes the code in the PAI module might look like something below

Function codes in a PAI module

MODULE user_command_0100 INPUT.  save_ok = ok_code.                      " save the existing ok code  CLEAR ok_code.                          " then clear it  CASE save_ok.                           " evaluate the save_ok    WHEN 'BACK'.      LEAVE TO SCREEN ...    WHEN 'EXIT'.      LEAVE PROGRAM.    WHEN 'CANCEL'.      LEAVE SCREEN.    WHEN 'PRESS'.      CALL METHOD screen_100=>handle_push_button.  ENDCASE. ENDMODULE.

You can also use context menus (right clicking on a screen), as well you should have a look at DEMO_DYNPRO program this is a good example of all the above.

A dialog module is the entry point for a dynpro into the ABAP program, during the processing events PBO, PAI POH and POV the dynpro flow logic calls suitable dialog modules in the program which in turn call the appropriate processing in the program, the dialog modules are processing blocks without parameter interfaces and without local data area, you must have the output qualifier for the PBO and input qualifier for the PAI

dialog modules

MODULE pbo_module OUTPUT.  ... ENDMODULE. MODULE pai_module INPUT.  ... ENDMODULE.

Data transport between the dynpro and the ABAP program can occur automatically or under program control, the data transport from the ABAP program happens at the PAI step, data transport to the ABAP is at the end of the dialog step, that is directly before the new screen is sent.

During the PAI event you can control the time when the data transport from the dynpro to the ABAP program by using the following statement

program control PAI

FIELD dynp_field.

You can also use conditional modules calls

conditional module calls

# call a module only when a dynpro field is not empty FIELD dynp_field MODULE mod ON INPUT. # to call a module only when the value of a dynpro field has changed since PBO time field dynp_field MODULE mod ON REQUEST.

You can check users input data before processing, the runtime environment supports this with a series of automatic input checks but you can also program you own, the checks are executed during the PAI event before data is transported to the ABAP program and before calling dialog modules. Any errors detected are displayed in the status bar, the user can then correct them and the PAI is triggered again, the PAI will only process when there are no errors.

The system executes the automatic input checks in the following order

1. Required inputs - inputs can be marked as required in the screen painter, these fields must be filled in before the PAI processing can start
2. Input format and value range - the input fields on screens are templates that expect character input in a format appropriate for their type, which can depend on predefined settings.
3. ABAP dictionary - if input fields were defined by taking them over from the ABAP dictionary, and the fields in the dictionary is associated with a check table through a foreign key relation, then the user may only enter values that exist as foreign keys in the check table.

To allow a user to leave a screen without checking you need function codes of type 'E', examples of this are BACK, EXIT and CANCEL. Functions with function types 'E' don't start normal PAI processing but instead jump immediately to the following module call in the dynpro flow logic, the OK field is transported.

Function type E

MODULE mod AT EXIT-COMMAND.

To code your own check you need to use the field statement and the module that will perform the checks, you can use the message statement to display any errors. Use the chain statement to perform multiple checks

own check modules

FIELD dynp_field MODULE mod. # perform multiple checks CHAIN.  FIELD: dynp_field1, dynp_field2    MODULE mod1.  FIELD: dynp_field3, dynp_field4    MODULE mod2.  ... ENDCHAIN.

You can add documentation to any field on the screen, normally you use F1 or F4 to display the help on a specific field, to display additional data element documentation you must create the following event block in the dynpro flow logic for the Process ON Help Request (POH) event, there is no data transportation during the POH and the POH event takes place outside the PAI event.

POH (process on help request)

# use the num for specific dynpro for the additional data element documentation PROCESS ON HELP-REQUEST.  FIELD dynpr_field WITH num. # you can also use your own dialog module PROCESS ON HELP-REQUEST.  FIELD dynpr_field MODULE mod.

You can then add the document via the goto -> document -> data element documentation

You can also add dropdown list boxes, using the input/output field you check the dropdown parameter to listbox, you can then change the visLength to determine the width of the box. The user will select the data in the dropdown box and then this data will be written to the dynpro field.

You can create a value list for the dropdown box as below, you can then write a module to populate the list

dropdown box

PROCESS ON VALUE-REQUEST  FIELD sdyn_conn-carrid MODULE create_dropdown_box.

Dynpros and Classes

So we have covered the following

• Dynpros display screens in the SAP GUI
• Dynpros from dynpro sequences which can be called from dialog transactions or from ABAP programs
• Dynpros have an event-based flow logic that calls dialog modules in ABAP programs
• Data transport between dynpros and the ABAP program takes place through program-global data
• Dynpros provide advanced options for input check

At the moment the conceptual fit between dynpros and classes is essentially nonexistent, class pools support neither dynpros nor dialog modules for the following reasons

• in class pools there are no global data declarations so no data transport is possible from and to dynpros
• class pools only support methods as processing blocks

To get around the above problems we can use function groups which can be viewed as a global class, where data in the decaralation part is equivalent to the private components and the function modules are equivalent to the public components which means that it is suitable for the wrapping of one or more dynpros in an application. This can be viewed in the below diagram, we can see how the logic flows via the function group this gives us the support to be able to uses classes, in the function group the global data and dialog modules required for dynpro processing are encapsulated with respect to the application. This separation of the application logic and presentation makes programs less error prone, easier to maintain and simpler to convert to other GUI technologies.

An high level code example would be below, you would create a transaction which is used to start the OO and assign it to a class (in this example the start class), the method can be seen in the right-hand box which is very simple

CLASS zcl_change_planetype DEFINITION PUBLIC  .. ENDCLASS CLASS zcl_change_planetype IMPLEMENTATION.  METHOD start.    CALL FUNCTION 'Z_CHANGE_PLANETYPE'.  ENDMETHOD.  ... ENDCLASS.

The function module called zcl_change_planetype belongs to the function group called z_change_flights and its implementation is also simple, it calls dynpro 100 of its function group, this call will start a dynpro sequence whose flow results from the user actions on the dynpro

function module	** The function calls a screen FUNCTION zcl_change_planetype.  CALL SCREEN 100. ENDFUNCTION.
Screen 100	PROCESS BEFORE OUTPUT.  MODULE set_status. PROCESS AFTER INPUT.  MODULE cancel AT EXIT-COMMAND.  FIELD demo_conn-fldate MODULE user_command_100.
Include program	******************************************************************* * System-defined Include-files. * ******************************************************************* INCLUDE LZ_CHANGE_FLIGHTSTOP. " Global Data INCLUDE LZ_CHANGE_FLIGHTSUXX. " Function Modules ******************************************************************* * User-defined Include-files (if necessary). * ******************************************************************* * INCLUDE LZ_CHANGE_FLIGHTSF... " Subroutines * INCLUDE LZ_CHANGE_FLIGHTSO... " PBO-Modules * INCLUDE LZ_CHANGE_FLIGHTSI... " PAI-Modules * INCLUDE LZ_CHANGE_FLIGHTSE... " Events * INCLUDE LZ_CHANGE_FLIGHTSP... " Local class implement. INCLUDE LZ_CHANGE_FLIGHTSO01. INCLUDE LZ_CHANGE_FLIGHTSI01. INCLUDE LZ_CHANGE_FLIGHTSP01.

The above steps have completed the separation of the concerns we mentioned above, a class-based application uses dynpro encapsulated in a function group. I just want to cover a few additional steps first GUI status, I covered this above but wanted to explain how to create a menu bar, here the top line is the top menu bar name (left-hand screenshot) , then by double clicking on the flight dates you can add the options underneath and associate them with the code, the menu can be seen in the right-hand screenshot.

The next that I wanted to cover is how do you stop displaying specific buttons on a, for example take the left-hand screenshot, to can use the code on the right to not display specific buttons, etc

MODULE set_status OUTPUT.  SET TITLEBAR 'TITLE_100-200'.                             " see below  CASE sy-dynnr.    WHEN 100.      SET PF-STATUS 'SCREEN_100_200' EXCLUDING 'UPDATE'.    " SCREEN_100_200 is the GUI status    WHEN 200.      SET PF-STATUS 'SCREEN_100_200' EXCLUDING 'CHANGE'.  ENDCASE. ENDMODULE.

Lastly you can create your own titlebars these are called GUI Title, as you can see they are very simple objects.

Dynpro controls is a software component of the ABAP runtime environment for the handling of complex screen elements, there are two types of controls that can be selected as a screen element in the screen painter

• The table control is a screen element for the display and editing of tabular data
• The tabstrip control is a screen element built of multiple tabstrip pages and is displayed as an register.

You declare both using the controls statement, you create them using a wizard and can be accessed in ABAP through the classes of the control framework. You have two options in the screen painter (left-hand screenshot) you can create with or without a wizard, you can see the wizard in the right-hand screenshot

The options in the wizard are

• Name of table control - enter a name for the table control
• Table name - a name for the internal program table and WA (work area)
• Definition of columns - select the desired columns for the table
• Table control attributes - specify the properties of the table (input)
• Select additional table maintenance functions - here you can select scroll
• Set includes - select the include programs in which the table control wizard should create it code, it will offer suitable include programs
• Finish table control - confirm completion

You first need to create function group (which declares the global internal table), then you can use the wizard to create control, if you notice the flow logic is populated for you, you can just tweak it a little if required.

FUNCTION-POOL z_table_control. DATA conn_tab TYPE TABLE OF demo_conn. DATA wa TYPE demo_conn. .....

If you look at the code the loop at statement assign the table control an internal table in the program and specifies a parallel loop execution over the table control lines shown on the screen and the internal table. During each pass through the loop the contents of the table control are transported between fields of the ABAP program and that of the table control that have the same name. The clauses into and with control are only needed in PBO and are not allowed during PAI. During a pass through loop the system field sy-step1 contains the current line in the table control, counting from the top line displayed and sy-loopc contains the current number of table control lines on the screen. The cursor clause can be used during PBO to control which line in the internal table should appear first on the screen display, so the you would add something like below to your top include of your function group

declaration for a table control

CONTROLS flights TYPE TABLEVIEW USING SCREEN 0100. DATA g_flights_lines  TYPE sy-loopc. DATA ok_code          TYPE sy-ucomm.

The controls statement above declares a deep structure, this structure is a data type cxtab_control from the type group cxtab, you can access the properties lines current_line, top_line, sy-step1, etc. To call the table you could use the code below

call a table control

CLASS demo DEFINITION.  PUBLIC SECTION.    CLASS-METHODS main. ENDCLASS. CLASS demo IMPLEMENTATION.  METHOD main.    DATA spfli_tab TYPE TABLE OF spfli.    SELECT *      FROM spfli        INTO CORRESPONDING FIELDS          OF TABLE spfli_tab.    CALL FUNCTION 'Z_SHOW_TABLE_CONTROL'      EXPORTING flight_list = spfli_tab.  ENDMETHOD. ENDCLASS. START-OF-SELECTION.  demo=>main( ).

The dynpro control is tabstrip, this implements tabs that are based on subscreen technology, this helps with simplifying complex sequences of individual screens, a subscreen is a screen in a subscreen dynpro and can be integrated into the subscreen areas of other subscreens, you use the layout editor to create a tabstrip (left-hand screenshot), I prefer to use the wizard as it will automatically generate all the code for you, feel free to tweak, then all you need is to create a function module and call the screen "CALL SCREEN 100" and you should is the right-hand screen.

Selection Screens

Selection screens are a special dynpros defined within ABAP statements without the need to use the screen painter, when an ABAP program with selection screens is activated the runtime environment generates these dynpros with all their components including flow logic, no dialog modules need to be created for selection screens, instead user actions on selection screens result in special selection screen events which can be handled in event blocks.

The screen elements of selection screens are a subset of all the elements possible on dynpro including

• Text fields and frames
• Input/output fields, checkboxes and radio buttons
• Push buttons
• Subscreens
• Tabstrip controls

Selection screens have the following advantage over dynpro

• Fast implementation of small queries with the screen painter
• The user can store frequently used entries for each selection screen in so-called selection variants and reuse them.
• Selection criteria are stored in special internal tables and can be evaluated in logical expressions.

I have covered BDC sessions already in my classic section, but will dive into the basics a bit more.

Screen selections can be created with the following statements in the global declaration part of function groups, executable programs and module-pools, the screen number is defined between the two statements dynnr, each screen dynpro number should be unique, to can specify a title which you should use a text symbol. The as window can be used to prepare the screen for display in a modal dialog box.

selection screen declaration

SELECTION-SCREEN BEGIN OF SCREEN dynnr [TITLE title] [AS WINDOW]. ... SELECTION-SCREEN END OF SCREEN dynnr.

To define the screen elements of a selection screen the following statements are used

• parameters - defines a single input field for a so-called parameter which can also be displayed as a checkbox or radio button
• select-options - defines two related input fields and functions for a so-called selection criterion
• Additional variants of the selection-screen statement define the other screen elements and influence their arrangement

A parameter is a component of a selection-screen for which an input field on the selection-screen and a global variable of the same name in the ABAP program are created.

parameters syntax

PARAMETER para  [TYPE type LENGTH len]|[LIKE dobj] [DECIMAL dec]  [OBLIGATORY]  [AS CHECKBOX]  [RADIOBUTTON GROUP group]  [DEFAULT val]  [LOWER CASE]  [VALUE CHECK]  ...

The contents of the variable is transported into the input field during the PBO in the selection screen, and adopt its current value during the PAI. So lets create an example, first in the left-hand screenshot you can see what we are going to produce, its a simple screen composing of a input field and two screen blocks one with checkboxes and the other with radio buttons, the package details are in the middle screenshot and the exporting parameters in the function module z_parameters are displayed in the right-hand screen

Next we have the code in the left-hand screenshot we see the function group z_selection_screens this simply creates the screen dynpro 100 and two screen blocks which groups to together visually the different parameters and in the right-hand screenshot we see the function module z_parameters, you can see we use a if statement to see which radio button was selected. Obviously you can implement you own code or call other functions, etc.

FUNCTION-POOL z_selection_screens. SELECTION-SCREEN BEGIN OF SCREEN 100 AS WINDOW TITLE text-100.  PARAMETERS p_input TYPE c LENGTH 16 DEFAULT 'Parameter'.  SKIP.  SELECTION-SCREEN: BEGIN OF BLOCK b1 WITH FRAME TITLE text-110.                  PARAMETERS: p_check1 AS CHECKBOX,                                  p_check2 AS CHECKBOX,                                  p_check3 AS CHECKBOX.  SELECTION-SCREEN: END OF BLOCK b1.  SKIP.  SELECTION-SCREEN: BEGIN OF BLOCK b2 WITH FRAME TITLE text-120.                      PARAMETERS: p_radio1 RADIOBUTTON GROUP rad,                                  p_radio2 RADIOBUTTON GROUP rad,                                  p_radio3 RADIOBUTTON GROUP rad.  SELECTION-SCREEN: END OF BLOCK b2. SELECTION-SCREEN END OF SCREEN 100.

FUNCTION Z_PARAMETERS. *"----------------------------------------------------------- *"*"Local Interface: *" EXPORTING *" REFERENCE(CHECK1) TYPE CHAR1 *" REFERENCE(CHECK2) TYPE CHAR1 *" REFERENCE(CHECK3) TYPE CHAR1 *" REFERENCE(INPUT) TYPE CHAR16 *" REFERENCE(SELECTION) TYPE I *"----------------------------------------------------------- CALL SELECTION-SCREEN 100 STARTING AT 10 10. input = p_input. check1 = p_check1. check2 = p_check2. check3 = p_check3. IF p_radio1 = 'X'. selection = 1. ELSEIF p_radio2 = 'X'. selection = 2. ELSEIF p_radio3 = 'X'. selection = 3. ENDIF. ENDFUNCTION.

It is possible to have selection criteria in your screens, the screen elements can have a wide range of input options to the user, a selection criterion is represented by a special internal table a so-called selection table.

SELECT-OPTIONS syntax

SELECT-OPTIONS select FOR dobj  ..  [NO INTERVALS]  [NO-EXTENSION]  .. # example DATA g_carrid TYPE scarr-carrid. SELECT-OPTIONS s_carrid FOR g_carrid.

The above statement creates an internal table with the special structure of a selection table, two input fields are created on the selection screen named <int_tab_name>-low and <int_tab_name>-high, the for dobj replaces the type or like clause.

A selection table is a four-column internal table (with header line), they represent a logical condition which can be composed of the conditions of multiple lines, all selection tables have the following components

• sign - this data type is c with length 1, the possible values are I and E, these determine if the result of the condition in the line should be included in or excluded from the overall result
• option - the data type is c with length 2, possible values are EQ, NE, GE, GT, LE, LT, CP and NP for single values or BT and NB for intervals.
• low, high - the data type is determined by the for dobj clause. Either low will be filled or both low and high will be filled

Here is an example

DATA g_carrid TYPE scarr-carrid. SELECTION-SCREEN BEGIN OF SCREEN 200 TITLE text-200.   SELECT-OPTIONS s_carrid FOR g_carrid. SELECTION-SCREEN END OF SCREEN 200.

FUNCTION Z_SELECTION_CRITERTION. *"---------------------------------------------------------------------- *"*"Local Interface: *"     EXPORTING *"        REFERENCE(SELTAB) TYPE TABLE *"        REFERENCE(RC) TYPE SYST-SUBRC *"---------------------------------------------------------------------- CALL SELECTION-SCREEN 200. IF sy-subrc = 4.  rc = sy-subrc.  RETURN. ELSE.  seltab = s_carrid[]. ENDIF. ENDFUNCTION.

REPORT Z_DEMO_SCREEN_REPORT. class Z_DEMO_CRITERIA definition.   public section.     class-methods MAIN . ENDCLASS. CLASS Z_DEMO_CRITERIA IMPLEMENTATION.   method MAIN.     DATA: selection TYPE RANGE OF scarr-carrid,              scarr_tab TYPE TABLE OF scarr,              alv TYPE REF TO cl_salv_table,              subrc TYPE syst-subrc.     CALL FUNCTION 'Z_SELECTION_CRITERTION' IMPORTING seltab = selection.     IF subrc = 4.       RETURN.     ENDIF.     SELECT * FROM scarr INTO TABLE scarr_tab WHERE carrid IN selection.     TRY.        cl_salv_table=>factory(                                         IMPORTING r_salv_table = alv                                         CHANGING t_table = scarr_tab ).         alv->display( ).     CATCH cx_salv_msg.                 MESSAGE 'ALV display not possible' TYPE 'I' DISPLAY LIKE 'E'.     ENDTRY. endmethod. ENDCLASS. START-OF-SELECTION.   Z_DEMO_CRITERIA=>main( ).

The TOP function include would contain the below

DATA g_carrid TYPE scarr-carrid. SELECTION-SCREEN BEGIN OF SCREEN 200 TITLE text-200.  SELECT-OPTIONS s_carrid FOR g_carrid. SELECTION-SCREEN END OF SCREEN 200.

The screen is as below, here to can set a low and high (left-hand screenshot), you also have a selection button at the end which also you to select single values, ranges, etc (right-hand screenshot), this allows you to build complex conditional statements.

There are additional selection-screen variants which I will leave you to investigate

• selection-screen skip - create virtual spacing
• selection-screen uline - creates horizontal lines
• selection-screen comment - creates output fields
• selection-screen pushbutton - creates buttons
• selection-screen begin|end of line - arranges multiple elements on a line
• selection-screen begin|end of block - organizes multiple elements into a block, optionally with frame and title
• selection-screen begin|end of tabbed block - creates tabstrip control
• selection-screen begin of screen dynnr as subscreen - selection screen defined as a subscreen.

To call a screen you use the call statement

Call screen

CALL SELECTION-SCREEN dynnr  [STARTING AT x1 y1]  [ENDING   AT x2 y2].

During the processing of selection screen the flow logic is encapsulated, no dialog modules are called, instead the selection screen process triggers a series of selection screen events for which events blocks are programmed. During the PBO the at selection-screen output event is triggered, during the PAI processing a series of at selection-screen events are triggered which reflect the different situations of the general PAI processing of a general dynpro. The below are the screen events with a brief description

Event	Trigger	Description
AT SELECTION-SCREEN OUTPUT	PBO	here you prepare the screen by assigning values to data objects of parameters and selection criteria and making dynamic screen modifications
AT SELECTION-SCREEN ON para | selcrit	PAI	the contents of the input fields of parameters para or a line of a selection criterion selcrit were passed to the ABAP program, here you can implement an input check for individual fields
AT SELECTION-SCREEN ON END OF selcrit	PAI	After a user action in the dialog box for multiple selection, the entire selection table selcrit was passed to the program, here you can implement an input check for the entire table
AT SELECTION-SCREEN ON BLOCK block	PAI	when all input fields in a block block of the selection screen were passed to the ABAP program, here you can implement an input check for all the input fields in the block
AT SELECTION-SCREEN ON RADIOBUTTON GROUP group	PAI	when all the input fields in a radio button group group on the selection screen were passed to the ABAP program, here you can implement an input check for the entire radio button group
AT SELECTION-SCREEN	PAI	when all the input fields in the selection screen were passed to the ABAP program, here you can implement an input check for the entire selection screen
AT SELECTION-SCREEN ON HELP-REQUEST FOR ... AT SELECTION-SCREEN ON VALUE-REQUEST FOR ...	POH POV	when field help F1 or input help F4 is called for the input field of a parameter or one of the input fields of a selection criterion, other selection screen events are not triggered, here you can implement a self-defined field or input help.
AT SELECTION-SCREEN ON EXIT-COMMAND	PAI	If a user selects one of the functions back, exit or cancel, you can take care of any clean-up tasks in the event block

Standard selection screens are a specialty of execute programs, every executable program (but no other type of program) has a predefined standard selection screen with dynpro number 1000 which need not be defined with selection-screen begin of screen 1000, no other program can have the number 1000. During the execution of an executable program via submit the standard selection screen is automatically called between the reports events initialization and start-of-selection. If the clause via selection-screen is used when calling the selection screen is displayed otherwise the selection screen processing runs transparently to the user.

REPORT Z_DEMO_SCREEN_REPORT. DATA g_carrid TYPE scarr-carrid.        " moved from TOP function SELECT-OPTIONS s-carrid FOR g_carrid.   " moved from TOP function class Z_DEMO_CRITERIA definition.   public section.     class-methods MAIN . ENDCLASS. CLASS Z_DEMO_CRITERIA IMPLEMENTATION.   method MAIN.     DATA: selection TYPE RANGE OF scarr-carrid,              scarr_tab TYPE TABLE OF scarr,              alv TYPE REF TO cl_salv_table,              subrc TYPE syst-subrc.     CALL FUNCTION 'Z_SELECTION_CRITERTION' IMPORTING seltab = selection.     IF subrc = 4.       RETURN.     ENDIF.     SELECT * FROM scarr INTO TABLE scarr_tab WHERE carrid IN selection.     TRY.        cl_salv_table=>factory(                                         IMPORTING r_salv_table = alv                                         CHANGING t_table = scarr_tab ).         alv->display( ).     CATCH cx_salv_msg.                 MESSAGE 'ALV display not possible' TYPE 'I' DISPLAY LIKE 'E'.     ENDTRY. endmethod. ENDCLASS. START-OF-SELECTION.   Z_DEMO_CRITERIA=>main( ).

From the example we used above we have moved the selection screen into the same program, the reason for this breach of separation concerns is because selections screens are also useful as parameter interfaces to executable program, when an executable program is started using submit, the silent processing of the selection screen, the display of the selection screen therefore must be forced by specifying via selection screen.

You can use silent screen processing for background processing of executable programs, to execute a program in the background you can schedule as follows as a background task num in a background request job

background task

SUBMIT ... VIA JOB job NUMBER num ... # pass parameters SUBMIT prog WITH selcrit IN seltab.

Here is an example piece of code that demostrates the submit background process

background task example

REPORT z_submit_job. CLASS demo DEFINITION.  PUBLIC SECTION.  CLASS-METHODS main. ENDCLASS. CLASS demo IMPLEMENTATION.  METHOD main.    DATA: selection   TYPE RANGE OF scarr-carrid,          subrc       TYPE syst-subrc,          number   TYPE tbtcjob-jobcount,          name        TYPE tbtcjob-jobname VALUE 'GET_FLIGHT_LIST',          pripars     TYPE pri_params,          valid_flag  TYPE c LENGTH 1.    CALL FUNCTION 'Z_SELECTION_CRITERION'          IMPORTING              seltab = selection              rc     = subrc.    IF subrc = 4.      RETURN.    ENDIF.    CALL FUNCTION 'GET_PRINT_PARAMETERS'       IMPORTING               out_parameters    = pripars             valid             = valid_flag       EXCEPTIONS             invalid_print_params = 2             others                    = 4.    IF sy-subrc <> 0 or valid_flag <> 'X'.      RETURN.    ENDIF.    CALL FUNCTION 'JOB_OPEN'      EXPORTING             jobname = name      IMPORTING             jobcount = number      EXCEPTIONS           others = 4.    IF sy-subrc = 0.    SUBMIT z_submitable WITH s_carrid IN selection                    TO SAP-SPOOL                    SPOOL PARAMETERS pripars                    WITHOUT SPOOL DYNPRO                    VIA JOB name NUMBER number                    AND RETURN.       IF sy-subrc = 0.         CALL FUNCTION 'JOB_CLOSE'           EXPORTING               jobcount = number               jobname = name               strtimmed = 'X'           EXCEPTIONS               others = 4.                   IF sy-subrc = 0.             MESSAGE 'Job submitted' TYPE 'I'.          ENDIF.       ENDIF.    ENDIF.  ENDMETHOD. ENDCLASS. START-OF-SELECTION.  demo=>main( ).

For more details on background processing see background jobs in my Basis section.

Messages

You have probably come across some messages in my previous examples, they are short single line texts which can be displayed from an ABAP program using the message statement in dialog boxes or in the status line of the current window of the SAP GUI. You can inform users about informational or error in your program.

Messages are generally repository objects connected to the Change and Transport System (CTS) and translation, which are edited using transaction code SE91 or from the ABAP workbench SE80, messages are stored in the table T100 which has the following columns

• one character language key
• twenty character message class, which assigns its message to a work area or package
• three character message number where the range from 900 to 999 is reserved for customer development
• a short text of no more than 73 characters as the actual message displayed

You can send messages using the message statement, you can use the messages from table T100 or your own text, you must also specify a message type

A	Termination
E	Error
I	Informational
S	Status (handled in PBO)
W	Warning
X	Exit

Here is the syntax for each messages type

Messages

# use table T100 id, t = message type, n = message number MESSAGE tn(ID).                 # mid = message class, mtype = message type, num = message number MESSAGE ID mid TYPE mtype NUMBER num. # use an exception object MESSAGE oref TYPE mtype. # free text MESSAGE 'text' TYPE mtype. # placeholder MESSAGE ..... WITH text1 ... text4. # display type MESSAGE ... DISPLAY LIKE dtype.

There is not much more to discuss regarding messages, have a look through my ABAP section as various examples.