When you are new at using the screen painter and/or the menu painter, a brief overall description can be useful. The screen painter is an editor for setting up a "DYNPRO" (originally called Dynamic Program). The DYNPRO is in effect a screen with fields and processing. The processing blocks for screens are set up as Processing Before Output is displayed on the screen, and Processing After Input has been entered on that screen.
The menu painter is an editor for the program's Interface which is build up out of several Statussus (menus). Menus can be "painted" for a DYNPRO, but they can just as well be used on a report (an interactive report) or e.g. a popup. On a normal screen, the menu incorporates the actual menus and drop downs, the system toolbar below it (with preset buttons like the 3-way-out (green/yellow/red), page-ing and the search functions). Then there's also the application toolbar with a potential button-row (which can also show text buttons). Last but not least: context-menu, click the right-mouse button and it shows...
To connect the menu painter to the screen painter, a special code field will have to be declared in the ABAP. The last field of a DYNPRO is a reserved field, that embodies the link to the menu painter, the The OKCODE. If you do not link it (by giving it a name), the DYNPRO will not be able to pass on the chosen menu actions from the menu painter. Result: no user interaction possible via the menu. Simply fill in OKCODE for this last field of a DYNPRO's field list (menu: from Screen painter: jump => field list).
This article briefly describes how screen painting hangs together.
Screens can be used with 2 different forms/types of ABAP's. The differences can be explained like this:
What you should do and not do when painting your screens and menus
- Do make sure screen painting and menu painting are done properly - the available tools (both painters) are packed with intelligent defaults which should be utilised. Remeber: this is about the look and feel of your application, which should adhere to SAP's look and feel...
- Don't create a new menu if only a small change is needed, menu's options can be activated and de-activated very easily (see online help on statement
ST PF-STATUS
... step by step. This will cover creating a screen in a series of steps.
As a business case to getting used to building a transaction, here's a nice challenge: create a popup with a traffic light (icon) and make it change colors...
This may be a bit unusual, but it could be a very handy tip. I tried to use the icon for a traffic light in a dynpro screen, which basically looked nice. You can display an icon in your dynpro as a picture, by not turning it into a button. Using the SCREEN table, you could change the attributes of that icon, thus you could make it visible or invisible. But, I wanted to actually change the icon, depending on a certain status.
To make your application move from screen to screen, a flow of screens needs to be coded. Here's how:
A screen flow can be set up using two ways or "jump to next screen" methods. When a transaction code is created for a module pool program, the first screen is filledin there. This is your starting point for the program. From there the possible screen jumps can be "Jump to the next screen (and come back afterwards)" (CALL SCREEN) or move to the next screen (LEAVE TO SCREEN). An example: LEAVE TO SCREEN 1100. or CALL SCREEN 1110 STARTING AT 5 6 ENDING AT 60 20.
Manipulating the look and feel of screen elements (fields) from PBO processing, changing the attributes of fields before they are placed on the screen. At runtime... The SCREEN table is an internal table that is available in ABAP runtime. It contains the attribute data for the screen fields. of the currently active screen. The field attributes of any field can be changed during runtime by manipulating the SCREEN table. An example for KNA1-KUNNR:
Some examples of the functionality of event PROCESS AFTER INPUT, also the statements MODULE, FIELD and CHAIN are covered.
- checking entered field values (calling error messages, start calculations, search in the database whether the entered value does actually exist, ...)
- catching menu actions, and starting related functions
- processing data entered
Setting up a simple popup from a report. WINDOWs!
In the land of ABAP's, screen-based applications and reporting applications are very different. But for a popup screen, it doesn't really matter. Basically you will need to create a screen (DYNPRO) of the type "Modal dialog box". Screens go with Process Before Output and Process After Input, and so does a popup. Make sure you cover the menu response module, to enable you to leave your popup again. Also make sure you fill in the OK-CODE field, otherwise the menu-code will simply never be passed on to the program and the only way to stop the program is to kill the session.
A popup can easily be used to inform your end user about something. If a message is not enough, if it's user input in the form of a selected option you need, consider the function modules that are available for popups. Even when it's OO you're into (like me) do consider these modules: OO has no clear answer for screens... A list of popup modules, with screenprint examples, in sequence of popularity:
There are some function modules available that accept input through input fields, which could be useful for your report. This article holds a practical example where a TVARVC variabele is made available to the end user. Further more the possible function modules that allow user input through popups is listed - for you to take your pick.
The field statement is a flow-logic statement which controls what happens with a field. Here's the overall suite of options....
Additions to the FIELD statement
A field check can be done in several ways. Not necessarily by using modules with routines. An overview:
The principle for the statements LOOP and ENDLOOP on a screen, representing repeating groups of fields (typically lines).
Whenever a LOOP is placed in the screen painter, the process logic has to be adapted as well. ABAP has a solution for repeating field groups in a DYNPRO. The statements LOOP and ENDLOOP indicate which fields are placed in the LOOP LOOP and ENDLOOP must be placed in bothPROCESS BEFORE OUTPUT and PROCESS AFTER INPUT. The loop lines are processed one by one in the flow logic. The ABAP developer thus only has develop a field check module for a singleLOOPline, which will be used for all lines.
Lists in DYNPRO's can (>3.0) be presented much like Excel. Table control are automatically represented in a new way. Selecting columns or lines is automatically taken care of by the system. The principle:
- The table control is declared in the ABAP; a table control is in fact a variable with a structure for controlling data for the screen table. This structure can be found in the
TYPE-POOL CXTAB. Declaration:CONTROLS cx_control TYPE TABLEVIEW USING SCREEN scrnr. - The table control area needs to be "painted" on the screen, version 4.0b's graphical screen painter should enable you to do this quite easily.
When the transaction grows, the concept of a subscreen can be introduced. Standard SAP transactions can't do without. Here's how they work...
A subscreen is a screen type for a DYNPRO that is included in another DYNPRO. The SUBSCREEN can be created as a screen of this type, with its own process logic with field checks etc. The following steps have to be taken to include/incorporate a subscreen in another DYNPRO:
... when creating a screen. Screen painter basics for setting up a screen. Checkboxes, radio buttons, frames, loops and subscreens.