A dynpro refers to the screen + flow logic. With screen painter you can develop screen and flow logic. The relationship between screen, flow logic, and program can be shown as follows:
Dynpro, as figure indicates consist of screen and flow logic and places exactly one call to module pool program. A transaction consists of many screens and for each screen flow logic is attached. When the transaction is executed, the screen places a call to flow logic and flow logic in turn places a call to module pool program.
• A module program is usual ABAP/4 program that consist of modules and data declaration.
• ABAP/4 is an event driven language. In module pool program too, events get triggered and these events are handled in flow logic. Flow logic editor is subset of ABAP/4 editor. The system automatically displays the two important events for the flow logic.
• Screen is the important component of dynpro and can be created, designed by screen painter.
Screen Painter
A screen painter can be started by
Development workbench Screen Painter
Or
SE51 transaction code.
Using Screen Painter
The process of creating a dynpro includes the creation and definition of all the needed screen components.
The steps involved in creating the dynpro are as follows:
• Create screen and attributes by using screen attribute screen.
• Select and place the needed fields within the screen by using dict/program fields.
• Establish the field attributes to which the screen belongs by using field list.
• Define the flow logic respect to the transaction to which it belongs by using flow logic.
Creating a new Screen
Steps involved are as follows:
• Enter the name of program and number of the screen
• Click on Create
• On “screen attribute” screen enter short description
• Enter screen type. Normally, you select NORMAL option for usual R/3 screen. Other options available are SUBSCREEN & MODAL DIALOG BOX. Modal dialog box is used to establish independent and interactive dialog box while subscreen is screen within screen.
• Next attribute to be passed is NEXT SCREEN. Here you need to specify the next screen number, which must be processed after the current one.
Designing of Screen
Screen can be designed by using FULL SCREEN EDITOR. You can go to full screen editor.
From screen attribute screen
By pressing full screen editor pushbutton
Or
From initial screen of screen painter.
There are two modes available with full screen editor.
• Graphical mode. The graphical mode works similarly to typical window application.
• Alphanumeric mode (rarely used).
Elements of screen
• Text – Standard text or field labels.
• Entry - display field.
• Radiobutton – All radiobutton must be associated with one group.
• Checkbox – Normally used for YES/NO operations.
• Pushbutton – Used for activating particular function.
• Boxes – grouping together many screen elements.
• Subscreens – This is a screen area in which you can display another screen.
• Table controls – This area of screen is similar to table but should be treated as a loop.
• Status - Display output fields containing icon.
All these elements are on the control bar of full screen editor and can be placed on the screen work area by clicking and placing them wherever needed.
Selecting Screen Fields
Screen field can be either dictionary objects or program fields. Steps involved in the placing of fields on the screen are as follows:
Click the pushbutton Dict/program fields on the full screen editor
Or
Goto dict/prog fields.
• Enter table name.
• Click Get from dictionary.
• Select fields.
• Click copy pushbutton.
• Position the cursor where you want those fields to be placed.
To adjust various screen elements, you can use drag and drop facility for screen elements.
Attributes of Screen Elements
The entire element of a screen has some attributes, which determines their behavior.
• General – These attributes are directly managed by the screen painter like name of the element, or text of element or column width and various things associated with the screen.
• Dictionary – These attributes are applicable to fields, which are from dictionary. Various components of dictionary can be attached to this element like search help, foreign key.
• Program.
• Display – Behavior of the element with respect to their display feature.
Attribute dialog box can be displayed by
• Clicking on the ATTRIBUTE push button on the application tool bar.
• Double clicking on the element.
Field List
This list displays a list of all screen elements together with their screen attributes. One important element of Field list is OKCODE. Any pushbutton is associated with function code as in menu item in menu painter. When the user clicks the pushbutton this code is stored in OKCODE. This OKCODE is created by system without a name and is not visible on the screen. In ABAP/4 this field is work field and is nothing but an area wherein system stores the variable and is the last field of the field list and is invisible, hence user needs to give the name OKCODE. It is not mandatory to give the name OKCODE; developer can give any name to this field.
Screen Flow Logic
You can go to this screen either by
Initial screen of Screen painter Flow logic
Or
From Screen attribute screen Flow logic
When transaction is executed, the screen is displayed, user enters few fields, selects few functions. Later the screen is processed and processing of screen is done by flow logic. The events that are associated with screen are as follows:
• Process before Output (PBO)
• Process after input (PAI)
• Process on value request (POV)
• Process on help request (POH)
The system automatically displays two very important events or modules in flow logic i.e. PAI and PBO
PBO event
This event is triggered before the screen is displayed. The processing of screen before the display of screen is done in this event. For example, filling in default values in the screen fields.
PAI event
This event is responsible for processing of screen after the user enters the data and clicks the pushbutton. The processing of screen can include displaying another screen, or just displaying list or quitting the transaction itself and many more things. Usually it is displaying another screen. These operations can be carried out in the PAI event. OKCODE plays an important role in this operation.
POV event
Process on value request is triggered when the user clicks F4 key. You can handle this event when the user presses F4 key by writing code for the same in module pool program. Normally when the user presses F4, list of possible values is displayed. The standard list produced by system is adequate for applications you develop yourself. However, you can also have the option of setting up your own documentation and lists of possible values that are more detailed.
POH event
Normally when the user places the cursor on the field and presses F1 function key, the system displays its own Help for that particular field. You can add your own functionality to the Help button by writing code for the same in the POH event.
No comments:
Post a Comment