1. Dialog Programming

2. Used to Read, Insert,Update Data. User interface is designed by screen painter. Contains fields as : simple field, table field, checkboxes, radiobuttons etc. Contains Various types of controls in the screen. Screen navigation is controlled by screen flow logic, the program is controlled by ABAP flow logic. A single program can consist of a number of screens.

3. Screen Flow Logic Contains the procedural part of a screen. Created by flow logic editor, similar to the ABAP Editor. Language used to program screen flow logic has a similar syntax to ABAP, but is not part of ABAP itself. Contains no explicit data declarations. Serves as a container for processing blocks. Four processing blocks are present, all of which starts with the word PROCESS PROCESS BEFORE OUTPUT(PBO). PROCESS AFTER INPUT(PAI). PROCESS ON HELP-REQUEST(POH). PROCESS ON VALUE-REQUEST(POV) You capture your code in various modules and attach them in various event blocks.

4. Dialog Modules Dialog modules are called from the screen flow logic (screen command MODULE). A dialog module is written in an ABAP program for each state (PBO, PAI; POH,POV) of any of the screens belonging to it. The PAI modules of a screen together with the PBO modules of the subsequent screen form a dialog step. The interaction between the flow logic and the screen is controlled by a dialog processor. Dialog modules are introduced with the MODULE statement and concluded with the ENDMODULE statement.

7. Event Block For Dialog Modules

8. Module called in PBO Events are declared as :- MODULE OUTPUT.... ENDMODULE. Module called in PAI Events are declared as :- MODULE INPUT.... ENDMODULE. For other events, viz., POH, POV, on exit- command, at field, at chain input etc, they are written as :- MODULE.... ENDMODULE.

9. Types of Module Calls :- There are various ways of calling the dialog modules in the flow logic. The syntax of the flow logic allows to call dialog modules conditionally, and to control the transfer of data between the screen and the ABAP program. Simple Module Calls Controlling the Data Transfer Calling Modules Unconditionally Calling Modules Conditionally

10. Simple Module Calls To call a module, use the flow logic statement MODULE. The system starts the module, which must have been defined for the same event block in which the call occurs.

11. Controlling the Data Transfer Data is passed from screen fields to ABAP fields with the same names once in each dialog step. All of the data is transferred in the PAI event before PAI processing starts. The FIELD statement in the screen flow logic allows to control the moment at which data is passed from screen fields to their corresponding ABAP fields. FIELD. Data is not transported from the screen field into the ABAP field until the FIELD statement is processed. Only screen fields that do not appear in a FIELDS statement are transferred at the beginning of the PAI event. The FIELD statement has further functions in connection with conditional module calls and validity checks.

12. Calling Modules Unconditionally In the PAI event, the PAI modules are called in the sequence in which they occur in the screen flow logic, after the automatic field checks. This means that the input on the screen must satisfy the automatic checks before the first module can be called. In particular, all required fields must be filled, and any checks against value lists or check tables defined for the field in the ABAP Dictionary must be successful. In some cases, the user may have to enter a considerable amount of data merely in order to be able to leave the screen. To avoid this, you can use special function codes with a special module call, which calls the module regardless of what the user enters on the screen.

13. If the user chooses a pushbutton or a function of function code ‘E’, system bypasses the automatic field checks and calls a special module in the screen flow logic. MODULE AT EXIT-COMMAND. Regardless of where it occurs in the screen flow logic, this statement is executed immediately, and before the automatic checks for the field contents on the screen. Before the module is executed, the contents of the OK-CODE field are transported to the ABAP field with the same name. However, no other screen fields are transported to the program at this stage

14. Conditional Module Calls Screen language also allows you to make PAI module calls dependent on certain conditions by using the MODULE statement together with the FIELD statement. You can apply conditions to both single fields and groups of fields. Conditional module calls can help you to reduce the runtime of your program, particularly with modules that communicate with database tables.

15. Screens : User Interface

16. Provides interface to user for interaction. Defined by screen painter for programs (executables, module pools and function modules). Consist of Screen flow logic with various events ( PBO,PAI,POH,POV), each event contains one or more dialog modules written in ABAP for execution. Screens consist of input/output fields, with identically named fields in the ABAP program. Data interchange between them occurs in PBO and PAI events. Characteristics

17. Each screen has a GUI status, consisting of : Menu Bar, Standard Toolbar and Application Toolbar.A GUI status is independent components of ABAP program, defined using Menu painter and attached to the screen dynamically. Each screen is linked to the current GUI status by a special screen field into which the corresponding function code is placed whenever the user chooses a function which is passed to the ABAP program and read by the program.

18. Attributes of A Screen Properties describing identity of a Screen and determine how will They behave at runtime

19. Program The name of the ABAP program (type 1, M, or F) to which the screen belongs. Screen number A four-digit number, unique within the ABAP program, that identifies the screen within the program. Screen type A normal screen occupies a whole GUI window. Modal dialog boxes only cover a part of a GUI window. Selection screens are not generally defined by screen painter, but defined by the program. A subscreen is a screen that is displayed in a subscreen area on a different screen in the same ABAP program.

20. Next screen Statically-defined screen number, specifying the next screen in the sequence. If it is zero or blank, the screen is the last in the screen sequence. This next screen number can be changed at runtime. Cursor position Static definition of the screen element on which the cursor is positioned when the screen is displayed. By default, the cursor appears on the first input field. You can overwrite the static cursor position dynamically in your ABAP program.

21. Screen group Four-character ID, placed in the system field SY-DYNGR while the screen is being processed. Allows to assign several screens to a common screen group, for example, to modify all of the screens in the group in a uniform way. Screen groups are stored in table TFAWT. Hold data If the user calls the screen more than once during a terminal session, he or she can retain changed data as default values by choosing System  User profile  Hold data.

22. Screen Elements Text FieldsDisplay elements, which cannot be changed either by the user or by the ABAP program. Input/ output fields Used to display data from the ABAP program or for entering data on the screen. Linked to screen fields. Dropdown List Boxes Special input/output fields that allow users to choose one entry from a fixed list of possible entries. CheckBoxSpecial input/output fields which the user can select (value ‘X’) or deselect (value SPACE). RadiobuttonOnly one field among more than one related fields can be selected

23. PushButtonsElements on the screen that trigger the PAI event of the screen flow logic when chosen by the user. There is a function code attached to each pushbutton, which is passed to the ABAP program when it is chosen. BoxDisplay element, used for visual grouping of related elements on the screen SubscreensArea on the screen in which you can place another screen. Table ControlsTabular input/output fields Tabstrip controls Areas on the screen in which you can switch between various pages.

24. Custom ControlContainer on the screen in which you can display another control. Status IconsDisplay elements, indicating the status of the application program OK_CODE fieldEvery screen has a twenty-character OK_CODE field (also known as the function code field), which is not displayed on the screen. User actions that trigger the PAI event also place the corresponding function code into this field, from where it is passed to the ABAP program. One can also use the command field in the standard toolbar to enter the function code. There should be a name to the OK_CODE field to be able to use it for a particular screen.

25. Attributes Of Screen Elements All screen elements have a set of attributes, some of which are set automatically, others of which have to be specified in the Screen Painter. They determine things such as the layout of the screen elements on the screen. You can set the attributes of screen elements in the Screen Painter - either for a single element, or using the element list, which lists all of the elements belonging to the current screen. Some of the attributes that you set statically in the Screen Painter can be overwritten dynamically in the ABAP program. Attributes of individual screen elements will be discussed when the topic will be discussed.

26. Defining the Element Attributes After adding screen elements to your screen, you must provide attributes for each element. The system sets some of these attributes automatically. You can set the attributes either in the Attributes window or in the element list. The Attributes Dialog Box To display the Attributes dialog from the full screen editor, choose Attributes or double-click an element. The Attributes dialog lists the attributes for a specific element.

27. These can be divided into General attributes Dictionary attributes Program attributes Display attributes. When you use table controls, tabstrip controls, or other controls, there are some special sets of attributes: Table control attributes Tabstrip control attributes Custom Control Attributes

28. General Attributes

29. Field type Identifies a screen element type (for example, keyword or group box). Name Identifies an element. You use this name to address a field from a module pool. Field names can not exceed 40 characters and must begin with a letter or an * (asterisk). The only special characters allowed are # (pound sign), / (forward slash), - (dash), _ (underscore) and $ (dollar sign). Text Specifies a field's text. If you want to use an icon instead of text, leave this field blank.

30. Dropdown This attribute only applies to input/output fields. If you choose List box, you can display a list of entries for the field, from which the user can select one. With icon Sets an icon value. Only use this attribute for output fields. Icon name Identifies an icon for a keyword. If you specify an icon that is not allowed for a field, the system returns an error message. Scrollable Sets the scroll function. Use this attribute if the DefLg value is greater than the VisLg value.

31. Line : Specifies the line where the screen element appears. Column : Identifies the column where the element begins Height : Specifies the height of an element in lines. Text labels and entry elements always have a height of 1. DefLg : Defined length. Identifies the actual length of the field in the Dictionary or your program. VisLg : The length of an element displayed on the screen. Set this attribute if you want the screen element to have a length different from its defined length.The attribute Scrollable must be set if visible length less than the defined length.

32. Groups : Modification groups, allows you to update several fields at once. Up to four modification groups can be assigned to a field. Each modification group is a three character code, referred in program as screen-group1, screen-group2 etc. FctCode : Function code: This attribute is only for pushbuttons and input/output fields with the Dropdown List box attribute FctType : Specifies the event at which the field is processed (for example, AT EXIT-COMMAND).

33. Dictionary Attributes

34. Format : Data type. From Dict. Specifies the current ABAP Dictionary reference. The system sets this attribute if you created this field by copying it from the Dictionary. Modified : The system sets this attribute if it detects a difference between the Dictionary definition for the field and the way it is used in the screen Conv.Exit : If you want the system to use a non-standard conversion routine for the conversion of field input, specify a four-character code here. There are two supported conversion routines: CONVERSION_EXIT_ _INPUT CONVERSION_EXIT_ _OUTPUT

35. Search help : Allows the user to specify a search help as input to the element. Enter a four-character search help file name or the name of a field that contains the file name. In the latter case, prefix your input with a : (colon). Reference Field : For tabstrip controls: Establishes the link between a tab title and a subscreen area.For currencies and quantities: Specifies a currency or unit key. Parameter ID ID for a SET/GET parameter (up to 20 characters long). This attribute is used with either the SET parameter or GET parameter attribute.

36. SET parameter and GET parameter If Set Parameter is chosen, the system stores the value entered by the user in the relevant Parameter ID parameter. If Get Parameter is chosen, the system displays the value in Parameter ID in the element instead of the initial value. Foreign key check Determines whether the system performs a foreign-key check for the field from the ABAP Dictionary. Upper/Lower case Set this attribute if your program handles the user's input as a literal. If not, the input is converted to all upper-case.

37. Program Attributes

38. Input field Defines an element as an input field. If the output field attribute is not set, the data in this element is processed during the transaction, but not displayed. However, you can set both, as is the default when creating a new template. Output field Defines an element as an output field. Choose this attribute for text templates that the program can use to display output. You cannot input data in these elements unless the input field attribute has also been set Output field only Prevents display-only elements from being changed into input elements at runtime.

39. Required field The field with this attribute on is mandatory for an entry. Easily identified in the screen as some (?) mark or some () sign is placed on those fields. PossEntry This attribute can only be set (and is only displayed) for input/output fields with the attribute Dropdown and the entry List box. You use it to determine how and when the value list for a dropdown list box is generated. There are two possible entries:

40. Space The system provides standard help. The help processor is started in the PBO and fills the value table automatically before sending it to the Value Request Manager. The sources are domain fixed values, value tables, and search helps. If the input/output field is linked to a PROCESS ON VALUE REQUEST module, this takes priority over the automatic process described above. A from program The application itself determines the values in a PBO module and passes the table and ValueID (Name attribute) to the Value Request Manager using the function module VRM_SET_VALUES.

41. Poss Entr. button Specifies whether a possible entries pushbutton should appear beside the element. The attribute does not appear for listbox elements with the dropdown attribute. If the element has possible entries, you can enforce or suppress the display of the entries button using this field. The system sets this field automatically for fields that specify foreign key checking or value lists in the ABAP Dictionary. This field is also set automatically for fields of type TIMS or DATS. Right-justified Right justifies numerical fields in an element. With leading zeros Left justifies values in numerical fields with leading zeroes.

42. *-entry Allows the user to enter an * (asterisk) in the first position of the element. The first-character asterisk triggers a flow logic module you declare with: FIELD... MODULE... ON *-INPUT. Without reset Prevents the reset character (!) from being used to delete input from an SAP field. Without template Prevents special characters from being treated differently. If the user enters special characters as part of the input, they are transferred to the screen as regular text. If you set this attribute, you cannot set the Req.entry attribute.

43. Display Attributes

44. Fixed font Displays input/output fields and text fields in a non proportional) font. To use Fixed font for output templates, you must also have defined the element as an output only field. Bright Highlights an element. Invisible Set this attribute if you want the element to be invisible. 2-dimensional Displays elements without the three-dimensional shading that normally appears around the element border. This field is automatically set when you use an icon.

45. As label left/right This attribute is used for text fields and input/output fields that are only used for display purposes (Input field attribute not set). If this attribute is set, the text field is linked to the screen element on its left/right in the same line. At runtime, the text field appears as a label for that screen element, that is, it appears to the left/right of the screen element. Double-Click sensitive Makes a screen element double-click sensitive (hotspot). You can only set this attribute for text fields and input/output fields. If you set this attribute, double-clicking the element at runtime triggers an action.

46. User Actions on Screens

47. Process Input/Output Fields Press Pushbuttons on the Screen Access checkbox and radio buttons With function codes Using GUI status

48. Processing I/O Fields Can be either conventional fields in which the user can enter values using the keyboard or by selecting from a value list, or checkboxes or radio buttons, for which the mouse is required. All input/output fields have a name linking them to a screen field. The data type of the screen field determines the input format. The ABAP program must contain identically-named data objects that correspond to the screen fields, otherwise data may be lost. After the PBO event has been processed, the screen fields are filled with the values from the ABAP fields. Before or during the PAI event, the values from the screen fields are written to the ABAP fields.

49. Local Program Fields To use local program fields from ABAP program in screen, create them in the ABAP program, activate the program, and then copy the fields from the ABAP program to the screen. Afterwards, however, you must avoid changing the fields in the ABAP program. Screen Fields with Dictionary Reference To use information from the ABAP Dictionary, such as field labels, field help, and input help, copy fields from the ABAP Dictionary(structures or tables). Then declare identically- named fields as an interface work area in the ABAP program using the TABLES statement.

50. Pushbuttons on the Screen Only element of screens that trigger the PAI event when the user chooses them. A function code can be specified in the attribute sheet of the pushbutton. Label of a pushbutton can be specified statically or dynamically( Set the Output field attribute for it,create a field with the same name of the pushbutton and assign text to it at the PBO events You can also assign icons to dynamic texts on pushbuttons by including the icon code in the text. The icon codes are all contained in the include program. For example, the ICON_CANCEL ( ) icon has the code @0W@.). Icons can also be assigned to the pushbutton statically. In each PAI event,the function code for the pushbutton is assigned to SY_UCOMM system field and in the OK_CODE field of the screen.

51. Checkboxes and Radio Buttons with Function Codes Function code can be assigned to checkboxes and radiobuttons, which trigger the PAI event and places the function code in the OK_CODE field.Without code, they behave as normal I/O fields. It is possible to assign an individual function code to each checkbox, and assign only one function code to all of the radio buttons in a group( the system automatically applies the same function code to all of the other radio buttons in the group. )

52. Using GUI Statuses For details on GUI status,click here

53. Finding Out the Cursor Position Sometimes, it becomes necessary to find out the cursor position in the screen after user interaction,specially if the user chooses the Choose function (F2 or mouse double-click). GET CURSOR FIELD [OFFSET ] [LINE ] [VALUE ] [LENGTH ]. is the variable name on which the name of the current cursor field is received, OFFSET writes the cursor position within the screen element to the variable, LINE writes the line number of the table to the variable if the cursor is positioned in a table control( If not in a table control, is set to zero),VALUE writes the contents of the screen field in display format, with all of its formatting characters, as a string to the variable. LENGTH writes the display length of the field to the variable.

54. Input Checks It is normally necessary to check user input for validity and consistency. There are three kinds of input checks on screens: Automatic Input Checks Automatic input checks are called in the PAI event before data is transported back to the ABAP program and before dialog modules are called. Input Checks in the Flow Logic Input checks in the flow logic can be performed before you call dialog modules. Input Checks in Dialog Modules These input checks are programmed in PAI modules. If the user enters an incorrect value, you can make input fields ready for input again without repeating the PBO processing.

55. Automatic Input Check There occurs a mandatory field check, format check and Dictionary check for appropriate fields. These are carried out before any data is transferred to the ABAP program, and before the screen flow logic is processed. Before the automatic input checks, you can call a single dialog module unconditionally (MODULE AT EXIT- COMMAND )using a special function type. You normally use this dialog module to bypass the checks and leave the screen directly. If the automatic input checks find an error, a message appears in the status bar of the screen, and the corresponding fields remain ready for input. The user must correct the entries and trigger the PAI again. The actual PAI processing does not start until there are no more errors.

56. Checking Fields in the Screen Flow Logic Checking a Value List You can check a screen field against a value list as follows: FIELD VALUES (,,...). The input help for can also use the value list in the FIELD statement. This helps the user to enter only correct values. The individual entries in the list can have the following format: [NOT] [NOT] BETWEEN AND If the check fails, an error message is displayed and the corresponding field is again ready for entry.

57. Checking Against Database Tables You can check a screen field against the contents of a database table as follows: FIELD SELECT * FROM WHERE = AND = AND... [INTO ] WHENEVER [NOT] FOUND SEND ERRORMESSAGE|WARNING [ [WITH... ]]. If a matching entry is found, you can write it into a screen field, but you do not have to. You can also send an error or warning message depending on the outcome of the search, which makes the input field for ready for input again. The input help for can also use the value list in the FIELD statement. This helps the user to enter only correct values.

58. Input Checks in Dialog Modules Checking Single Fields FIELD MODULE. The corresponding input field on the current screen (and only this field) is made ready for input again, allowing the user to enter a new value. If the field is only checked once, the PAI processing continues directly after the FIELD statement, and the preceding modules are not called again.

59. Checking a Set of Fields CHAIN. FIELD:,,... MODULE. FIELD:,,... MODULE.... ENDCHAIN. All of the fields on the screen that belong to the processing chain are made ready for input again. Other fields are not ready for input. Whenever the MODULE statement appears within a processing chain, even if there is only one FIELD attached to it, all of the fields in the chain (not only the affected field) are made ready for input again, allowing the user to enter new values. If the fields in the processing chain are only checked once, the PAI processing continues directly after the FIELD statement, and the preceding modules are not called again.

60. F1 Field Help If the user chooses the F1 key or the corresponding help icon ( ), a help text appears for the field in which the cursor is currently positioned. Data element documentation of a Dictionary field automatically comes in the screen.To change that or to add documentation to that, choose the screen field and then:-

61. On choosing them, a sapscript is opened, where the documentations are written.

62. Data element supplement documentation created in this way is program- and screen-specific. Any data element supplement documentation created in the ABAP Dictionary with the same number is overridden by the screen-specific documentation. You can link existing data element supplement documentation created in the ABAP Dictionary with a screen field by using the table THLPF. To do this, crate a new row in THLPF containing the following data: Program name, screen name, field name, and number of the data element supplement documentation.

63. To display data element supplement documentation, you must code the following screen flow logic in the POH event: PROCESS ON HELP-REQUEST.... FIELD [MODULE ] WITH.... If there is screen-specific data element supplement documentation for the field, you can display it by specifying its number. The number can be a literal or a variable. The variable must be declared and filled in the corresponding ABAP program. You can fill the variables, for example, by calling the module before the help is displayed.

64. The module is defined in the ABAP program like a normal PAI module. The processing logic of the module must ensure that adequate help is displayed for the field in question. Instead of calling an extra screen with text fields, you should use one of the following function modules to display a suitable SAPscript document: HELP_OBJECT_SHOW_FOR_FIELD This function module displays the data element documentation for components of any structure or database table from the ABAP Dictionary. You pass the name of the component and structure or table to the import parameters FIELD and TABLE.

65. HELP_OBJECT_SHOW Use this function module to display any SAPscript document. You must pass the document class (for example, TX for general texts, DE for data element documentation) and the name of the document to the import parameters DOKCLASS and DOKNAME. For technical reasons, you must also pass an empty internal table with the line type TLINE to the tables parameter of the function module.

66. Input Help (F4 Help)  Input Help from the ABAP Dictionary  Input Help on the Screen  Input Help in Dialog Modules

67. Input Help from the ABAP Dictionary Various means can be adopted :- 1.By using a Dictionary field to which a search help is attached. 2.Key fields of the check table can provide input help if Dictionary Check is on. 3.The domain of the field can contain fixed values or value ranges. 4.There can be a value table for the domain of the field. ( A check is not implemented by simply entering a value table! The check against the value table only takes effect when a foreign key has been defined.) 5. Fields with the types DATS and TIMS have their own predefined calendar and clock help that can be used as input help.

68. Input Help on the Screen Within the Screen Painter, you can define two types of input help: 1.The FIELD statement with one of the additions VALUES or SELECT. 2.Linking a search help directly to a screen field.

69. Input Help in Dialog Modules Dialog modules can be called in the POV events as :- PROCESS ON VALUE-REQUEST. FIELD MODULE. …… When the user presses F4 on field, the module is called.In the module, U call some relevant function modules that provides the list of values.Those function modules atart with F4IF_.

70. CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST‘ EXPORTING retfield = 'MATNR' DYNPPROG = progname DYNPNR = sy-dynnr DYNPROFIELD = 'MARA-MATNR ' WINDOW_TITLE = ' Select Materials From the List‘ VALUE_ORG = 'S‘ tables value_tab = itab EXCEPTIONS PARAMETER_ERROR = 1 NO_VALUES_FOUND = 2 OTHERS = 3. Example of Using : F4IF_INT_TABLE_VALUE_REQUEST

71. retfield : Name of the column whose value is to be returned. dynpprog : Name of the program. dynpnr : value of sy-dynnr dynprofield : name of the field where value is to be returned value-org = 'S' ( the internal table to be passed has a flat structure.Every line in VALUE_TAB then corresponds to one line in the list of values) value_tab : internal table to be passed with values

72. Example of Using : HELP_VALUES_GET_WITH_TABLE 1.First, declare the following at the top of the program :- DATA: BEGIN OF FIELDS OCCURS 10. INCLUDE STRUCTURE HELP_VALUE. DATA: END OF FIELDS. data : begin of itab occurs 5, CTEXT(50), end of itab. 2. Suppose U want to show the material code and name of materials from makt table. Declare a module in the POV event for a field for which U want the F4 help to be activated.

73. module selfhelp input. CLEAR FIELDS.REFRESH FIELDS. FIELDS-TABNAME = 'MAKT'.FIELDS-FIELDNAME = 'MATNR'. FIELDS-SELECTFLAG = 'X'. APPEND FIELDS.clear fields. FIELDS-TABNAME = 'MAKT'. FIELDS-FIELDNAME = 'MAKTG'. FIELDS-SELECTFLAG = ''. APPEND FIELDS.clear fields. CLEAR ITAB.REFRESH ITAB. select distinct matnr maktg into (mymatnr,mymaktg) from makt where matnr in ( select distinct matnr from mara where matkl like 'N%' ). ITAB-CTEXT = MYMATNR.APPEND ITAB. ITAB-CTEXT = MYMAKTG.APPEND ITAB. endselect.

74. CALL FUNCTION 'HELP_VALUES_GET_WITH_TABLE' EXPORTING CUCOL = 10 CUROW = 10 TITEL = 'SELECT fROM THE lIST ' IMPORTING SELECT_VALUE = MARA-MATNR TABLES fields = FIELDS valuetab = ITAB.

75. Dropdown Box Basically an I/O field in which the user can choose value from a list, but can’t enter anything. Input help button cannot be used for it. Set the value L or LISTBOX in the Dropdown attribute in the Screen Painter. The visLg attribute sets the output width of the list box and the field. When a function code is assigned to a listbox field, the PAI event is triggered immediately when the user chooses a value from the list, and the function code is placed in the SY-UCOMM and OK_CODE fields.

76. Value list attribute of the screen element is used to determine how the value list should be compiled. If nothing is entered there, the text field uses the first column displayed in the input help assigned to the screen field. The input help can be defined in the ABAP Dictionary, the screen, or a POV dialog module. If A is entered in the value list attribute, the value list is filled by the program (for example, in the PBO event) using the function module VRM_SET_VALUES. An internal table with the type VRM_VALUES(of type group VRM) is passed to the import parameter VALUES of the function module. The line type is a structure consisting of the two text fields KEY (length 40) and TEXT (length 80). In the table, you can combine possible user entries from the KEY field with any texts from the TEXT component. You specify the corresponding input/output field in the import parameter ID.

77. Click here to get demo program of listbox

78. Modifying Screens Dynamically

79. Attributes of screen elements are set statically in the screen painter, some of which can be changed dynamically at runtime by ABAP programs. To modify the attributes of screen elements, system table SCREEN is used, which represents the screen the user is using.

80. ComponentLengthTypeDescriptionAttribute NAME30CName of the screen fieldName GROUP13CModification group 1Group 1 GROUP23CModification group 2Group2 GROUP33CModification group 3Group3 GROUP43CModification group 4Group4 REQUIRED1CField input is mandatoryMandatory field INPUT1CField is ready for inputInput OUTPUT1CField is for display onlyOutput INTENSIFIED1CField is highlightedHighlighted INVISIBLE1CField is suppressedInvisible LENGTH1XField lengthVisLg ACTIVE1CField is activeInput/Output/Invisible DISPLAY_3D1CThree-dimensional boxTwo-dimensional VALUE_HELP1CInput help button displayInput help REQUEST 1CInput exists- The SCREEN Table

81. Allowed Combinations of Active,Input,Output, Invisible CombinationSignificance 1,1,1,0 Screen field is displayed, even if Invisible is set statically. Ready for input, even if Input is not set statically. However, not ready for input if the Output only is set statically. 1,1,0,0 Screen field is displayed, even if Invisible is set statically, except when Output only is set statically. Field contents are not displayed. Ready for input, even if Input is not set statically. 1,0,1,0 Screen field is displayed, even if Invisible is set statically. Field contents are displayed.Not ready for input, even if Input is set statically. 1,0,0,0 Screen field is displayed, even if Invisible is set statically, except when Output only is set statically. Field contents are not displayed. Not ready for input, even if Input is set statically. 1,1,1,1 Screen field is displayed, even if Invisible is set statically, except when Output only is set statically. Field contents are not displayed. Ready for input, even if Input is not set statically. User input is masked by asterisks (*).

82. CombinationSignificance 1,1,0,1 Screen field is displayed, even if Invisible is set statically, except when Output only is set statically. Output is masked by asterisks (*).Ready for input, even if Input is not set statically. User input is masked by asterisks (*). 1,0,1,1 Screen field inactive.Screen field is not displayed, regardless of the static attributes. 0,0,0,1 Screen field inactive.Screen field is not displayed, regardless of the static attributes. You can modify SCREEN in your ABAP program during the PBO event of a screen. Its contents override the static attributes of the screen fields for a single screen call. The only statements that you can use with SCREEN are:LOOP AT SCREEN.... MODIFY SCREEN.... ENDLOOP.

83. Setting the Cursor Position Dynamic Cursor Position To set the cursor position dynamically, use the following statement in an ABAP dialog module in the PBO event: SET CURSOR FIELD [OFFSET ]. can be a literal or a variable containing the name of a screen element. You can use the OFFSET addition to place the cursor at a particular point within an input/output field.

84. Switching on Hold Data Dynamically Hold data allows users to retain values that they have entered on a screen so that they appear the next time they start the same transaction. Only values actually entered by the user are retained. They are placed in the corresponding field as default values each time the screen is processed, and they overwrite the values transferred from the ABAP program in the PBO event. In the PBO event of a screen, you can overwrite the Hold data attribute dynamically using the statement SET HOLD DATA ON|OFF. The ON addition activates the attribute, OFF deactivates it.

85. In the PBO event, the Hold data attribute is activated dynamically. If the user enters a value and then chooses System  User profile  Hold data or Set data, the same value is displayed in the field when the screen is next displayed. This value is displayed each time the screen is called until the user chooses Delete data. This overwrites any value assigned to the field FIELD in the ABAP program.

86. Complex Screen Elements  Status Icon  Subscreens  Context Menu  Tabstrip Control  Table Control  Custom Control

87. Status Icon Display Elements, used to represent the state of a program graphically. Created in screen painter. A name and screen field(status field) is assigned to it.Text and quickinfo texts can also be attached to the icon in PBO event of ABAP program.

88. Instructions for Creating a Status Icon 1.Create a status icon in the screen and give it a name. 2.In ABAP program, create a field of type icons-text with the same name as the status field. Then call the function module ICON_CREATE in PBO event to define the icon. In the function module, there are various export parameters :- NAME : Name of the required icon TEXT : Text that will appear after the icon in the screen. INFO : Quickinfo text, which appears whenever the mouse pointer is positioned over the icon. Click here to get an example of using status icon

89. Subscreens Allows to embed one screen within another at runtime. A subscreen screen is embedded in subscreen area of main screen. Using subscreen is similar to using includes in ABAP programs. The flow logic of the embedded screen is also embedded into the flow logic of the main screen. Subscreens are used by screen exits, tabstrip controls etc. 1)Define subscreen area(s) on a screen. 2)Define suitable subscreen screen. 3)Include the subscreen screen in the subscreen area.

90. 1) Defining subscreen area(s) on a screen Created by screen painter. Each subscreen area has an unique name, position, length and height. One can also specify whether the subscreen area can be resized vertically or horizontally when the user resizes the window. If the resizing attributes are set, PAI event is triggered whenever the user resizes the main screen.

91. 2) Define Subscreen Screens One can create subscreens either in the same program or in a different program. To create a subscreen, enter the screen type : Subscreen in the screen attributes. The statically defined next screen must be the no. of the screen itself.Make sure that it fits within the subscreen area into which U want to place it.

92. Subscreens are designed similarly as normal screens with all types of screen elements. But, they do not have their own OK_CODE field. Function codes linked to user actions on subscreens are placed in the OK_CODE field of main screen. Flow logic of a subscreen screen should not contain : MODULE … AT EXIT-COMMAND statement. Type ‘E’ functions are handled in the main screen. Flow logic of a subscreen screen should not contain the following statements :- SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN, LEAVE TO SCREEN U also cannot change the GUI status of a main screen in a subscreen screen.

93. 3) Including Subscreen Screens in Program U write the inclusion of subscreen screens in the main screen in PBO events of the main program :- PROCESS BEFORE OUTPUT. Call subscreen including [ ]. The name of the area should be specified without inverted commas. The PBO logic of the subscreen screen is also included at the same point (Can call the PBO module of the ABAP program in which the subscreen screen is defined). At the end of the subscreen PBO, global fields from the program are passed to any identically named screen fields in subscreen screen.THE PBO flow logic of the subscreen screen can itself include further subscreens.

94. To call the PAI flow logic of the subscreen screen, use the following statement in the PAI flow logic of the main screen: PROCESS AFTER INPUT.... CALL SUBSCREEN.... This statement includes the PAI flow logic of the subscreen screen included in the subscreen area in the PBO event. This can call PAI modules of the ABAP program in which the subscreen screen is defined. Data is transported between identically- named fields in the subscreen screen and the ABAP program either when the PAI event is triggered, or at the corresponding FIELD statements in the PAI flow logic of the subscreen screen.

95. CALL SUBSCREEN statement between CHAIN and ENDCHAIN or LOOP and ENDLOOP can’t be placed. The variable SY-DYNNR changes when CALL SUBSCREEN is encountered or when one returns to the main screen. If subscreen screens are defined in other ABAP programs, ensure that the required global data of your ABAP programs is transported into the program of the calling screen after you have called their PAI flow logic. For example, subscreen screens can be defined in function groups and pass their global data to and from function module parameters. You must then call the function modules in appropriate dialog modules in the main program to transport the data. You can also export the global data from the main program as a data cluster to ABAP memory before the PBO of a subscreen screen and import it into a PBO module of the subscreen. Click here to get an example

96. Context Menu The user interface of a screen is defined by a GUI status, which is defined in the Menu Painter and type Dialog status is assigned to it. For each dialog status, the system automatically creates a standard context menu, which the user can display by clicking the right-hand mouse button on the screen (or choosing Shift+F10 ). The standard context menu contains all of the function keys to which functions are assigned.

97. Besides standard context menu, context-specific menu can be defined for : I/O fields,Text field, Table Control,Subscreens, Group Boxes. When one of these elements is selected using the right-hand mouse button, a dynamic context menu can be created in the ABAP program. This may contain any functions, and is not restricted to function keys. You cannot assign context menus to pushbuttons, checkboxes, or radio buttons. However, you can assign unique function codes to them instead.

98. Global Class CL_CTMENU Context menus are objects of the global ABAP Objects class CL_CTMENU. It contains methods that allow you to define context menus dynamically in a program. As a template, you can create your own context menus statically in the Menu Painter.

99. Context Menu for Elements in Screen To link a context menu with one of the screen elements, enter an ID in the Context menu field in the element attributes in the Screen Painter. If a context menu is not defined for a screen element, it inherits from the hierarchically next-highest element. For example, all screen elements in a group box with no own context menu would inherit the context menu of the group box. The highest hierarchy level is default context menu, containing all of the key settings of the current dialog status.

100. If a screen element is linked with a context menu – either its own or one that it has inherited, a special subroutine ON_CTMENU_ is called in the ABAP program when the user clicks the right- hand mouse button. The PAI event is not triggered. You use this subroutine (callback routine) to define the context menu dynamically. You must program it in the processing logic. If the subroutine does not exist, the context menu is not displayed. You can link the same context menu to any number of screen elements. They then all work with the same subroutine.

101. Defining Context Menus in the Processing Logic For each context menu that that is to be called for an element on a screen, a corresponding callback routine need to be programmed: FORM ON_CTMENU_ USING TYPE REF TO cl_ctmenu.... ENDFORM. Each routine must have a single USING parameter, typed as a reference variable to class CL_CTMENU. For each context menu assigned to an element on a screen, the runtime environment automatically creates an object of the class. When the user requests the context menu by clicking the right-hand mouse button, the system calls the corresponding subroutine and passes a reference to the corresponding object to the formal parameter. When the object is passed it is initial – the context menu contains no entries. In the subroutine, you can work with the methods of the object (as listed above) to construct the context menu dynamically.

102. Using Predefined Context Menus As well as dialog statuses and dialog box statuses, there is a third kind of GUI status that you can define in the Menu Painter, namely a context menu. Predefined context menus allow you to make groups of statically-defined function coded available context-specifically. The method LOAD_GUI_STATUS allows you to load a context menu from any ABAP program into a local context menu in a program. As a rule, you use predefined context menus to reuse the function codes from a dialog status with the same semantics, but context-specifically. Once you have loaded a predefined context menu into a local context menu in a program, you can modify it in any way (append other predefined context menus, add or remove functions, add other context menus).

103. Defining New Context Menus New context-specific menus can be created either by modifying existing ones or by constructing new menus. Any number of new functions can be added to a context menu.The function text, function code, and function type (for example, E for an unconditional module call) should be mentioned for that. However, you can also add any other local context menu from the program. In this case, you only have to pass a reference to another context menu (see example below). You can create a collection of context menu objects in your program and use and combine them as necessary. You can also construct submenus. You can have deep-nested menus by adding submenus to existing submenus.

104. Ergonomic Guidelines Followings should be observed while creating context menus: The functions in a context menu should be a subset of the functions in the program You can ensure this by using predefined context menus Context menus should not contain more than ten entries at a single level. If you use a context menu for a screen element, it should contain all of the functions possible for that element, but at least the standard comments such as Select, Copy, Cut, and Paste. The sequence of the functions should be as follows: Object- specific commands, copy commands, other commands. You should not duplicate functions that can be selected using the left-hand mouse button in a context menu. Click here for demo

105. Tabstrip Control Screen object consisting of two or more pages. Each tab page consists of a tab title and a page area. If the area occupied by the tabstrip control is too narrow to display all of the tab titles, a scrollbar appears, allowing you to reach the titles that are not displayed. There is also a pushbutton that allows you to display a list of all tab titles.

106. Structure of a Tab Page 1.Define the tab area on a screen and the tab titles. 2.Assign a subscreen area to each tab title. 3.Program the screen flow logic. 4.Program the ABAP processing logic.

107. Paging through the tabstrip control can be done:  At the SAPgui  On the application server. In the first case, each tab page has its own subscreen. In the second, there is a single subscreen area that is shared by all tab pages. Paging Through The Tabstrip Control

108. Defining the Tabstrip Control Area and Tab Titles Defined in screen layout. Tabstrip area : Has a unique name and a position, length, and height. Resizing properties with resizing of windows can also be mentioned. Has two tab titles by default. To create additional tab titles, simple create pushbuttons in the row containing the tab titles. Tab titles have the same attributes as pushbuttons, that is, each has a name, a text, and a function code. You can also use icons and dynamic texts with tab titles.

109. Assigning Subscreen Area to a Tab Title Tab pages can be :- o Paged in SAPGUI o Paged in Application Server Paging in SAPGUI :- Separate subscreen areas are assigned to separate tab pages and function codes of the tab titles are defined with type ‘P’(local GUI function). In screen flow logic, the subscreens are called in the PBO event. All the tab pages reside locally at SAPGUI. PAI event is not triggered when the user selects a tab page. All the input checks for all the subscreens are performed at same time. This path is generally adopted where data are displayed on tabstrip controls.

110. Paging on Application Server : One subscreen area is shared by all the tab titles and called in PBO event. Function code of individual tab titles are defined without special function types, When user chooses a tab page, PAI event is triggered and there should be a module in the flow logic that activates the appropriate tab page and assigns correct subscreen to subscreen area.

111. General Rules to Follow 1.Create subscreen areas first. 2.Create tabstrip area. Determine the function types and function codes. 3.For paging at SAPGUI, assign a subscreen area for each tab titles. For paging at application server, select all the tab titles and assign a single subscreen area. 4.Create and program the subscreens as usual.

112. Paging in the SAPgui When you page in the SAPgui, you must include a subscreen for each subscreen area: PROCESS BEFORE OUTPUT.... CALL SUBSCREEN: INCLUDING [ ], INCLUDING [ ], INCLUDING [ ],...... PROCESS AFTER INPUT.... CALL SUBSCREEN:,,,...

113. Paging on the Application Server When you page on the application server, you only have to include a subscreen for the one subscreen area: PROCESS BEFORE OUTPUT.... CALL SUBSCREEN INCLUDING [ ].... PROCESS AFTER INPUT.... CALL SUBSCREEN....

114. Handling in the ABAP Program Create a control for each control in the declaration part of your program using the following statement: CONTROLS TYPE TABSTRIP. where is the name of the tabstrip area on a screen in the ABAP program. The control allows the ABAP program to work with the tabstrip control. Before the screen is displayed, you use the control to set the tab page that is currently active: -ACTIVETAB =. When you page at the SAPgui, you only need to do this once before the screen is displayed. This initializes the tabstrip control. The default active tab page is the first page. After this, the page activated when the user chooses a tab title is set within SAPgui.

115. When you page on the application server, you must assign the active page both before the screen is displayed for the first time, and each time the user pages. At the same time, you must set the required subscreen screen. Use in the PAI event In the PAI event, ACTIVETAB contains the function code of the last active tab title on the screen. When you page in the SAPgui, this allows you to find out the page that the user can currently see. When you page at the application server, the active tab page is controlled by the ABAP program anyway. The OK_CODE field behaves differently according to the paging method:

116. Paging in the SAPgui When you page in the SAPgui, the PAI event is not triggered when the user chooses a tab title, and the OK_CODE field is not filled. The OK_CODE field is only filled by user actions in the GUI status or when the user chooses a pushbutton either outside the tabstrip control or on one of the subscreens.

117. Paging on the application server PAI event is triggered when the user chooses a tab title, and the OK_CODE field is filled with the corresponding function code. To page through the tabstrip control, you must assign the function code to the ACTIVETAB component of the control: -ACTIVETAB =. This statement overwrites the function code of the last active tab page with that of the new tab title. At the same time, you must ensure that the correct subscreen is inserted in the subscreen area. Otherwise, tabstrip controls are handled like normal subscrens in ABAP programs, that is, the ABAP program of a subscreen screen must contain the dialog modules called from the flow logic of the subscreen.

118. Click here to get the examples

119. Table Control Mechanism offered by SAP to display table data in the screen. Designed in the screen and controlled by Screen flow logic and ABAP program. Data can be entered, updated,deleted in table control. Can be placed in normal screens or subscreens.

120. Basic form CONTROLS ctrl TYPE TABLEVIEW USING SCREEN scr. Effect Creates a table control ctrl of the type TABLEVIEW. The reference screen for the initialization is the screen scr. Attributes The CONTROLS statement creates a complex data object of the type CXTAB_CONTROL with the name of the control. You maintain the initial values in the Screen Painter and assign the screen with the initial values for a control using the addition USING SCREEN. You can use the Customizing button (in the top right corner) to save the current setting (column widths and column positions) and use it as the initial value for the next call. All the initial values can be overwritten by the program.

121. Table Control Attributes Click here to get Attributes of Table Controls

122. Accessing Table Control Records : LOOP LOOP---ENDLOOP loops are used to loop through table controls. Used in PBO to copy the values from ABAP program to screen fields and also in PAI to copy data from screen fields to ABAP program. So, LOOP statement is a must even if nothing is to be copied back and forth. Table controls with screen table rows not created from internal table involves only use of LOOP …ENDLOOP statements. Table controls with table fields developed from internal table in the program uses : LOOP AT statement. It scrolls through table and the screen table rows in parallel.

123. Looping Directly Through A Screen Table LOOP[ WITH CONTROL ]....... ENDLOOP. The screen table fields as any type (internal table, database table, structure or individual fields). The simple LOOP copies the screen table fields back and forth to the relevant ABAP fields. If you want to manipulate the screen values in a different structure, you must explicitly move them to where you want them.

124. Each pass through the loop places the next table row in the ABAP fields, and executes the LOOP (usually ABAP module calls) for it. In a PBO event, the LOOP statement causes loop fields in the program to be copied row by row to the screen. In a PAI event, the fields are copied row by row to the relevant program fields.In an ABAP module, the system variable SY-STEPL gives the index of the screen table row that is currently being processed. The system sets this variable each time through the loop. SY-STEPL always has values from 1 to the number of rows currently displayed. This is useful when you are transferring field values back and forth between a screen table and an internal table. You can declare a table-offset variable in your program (often called BASE, and usually initialized with SY-LOOPC) and use it with SY-STEPL to get the internal table row that corresponds to the current screen table row.

125. Looping Through an Internal Table LOOP AT. loops through an internal table and a screen table in parallel. In particular, LOOP AT loops through the portion of the internal table that is currently visible in the screen. You can use this form of the LOOP statement for both table controls and step loops. LOOP AT CURSOR  WITH CONTROL   FROM   TO ....... ENDLOOP. This form of LOOP loops through the internal table, performing for each row. For each internal table row, the system transfers the relevant program fields to or from the corresponding screen table row.

126. Click here to get complete examples of Table Controls