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
Required inputs - inputs can be marked as required in the screen painter, these fields must be filled in before the PAI processing can start
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.
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
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
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
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.
