Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Dialog programming ABAP

2.507 Aufrufe

Veröffentlicht am

Dialog programming for beginners

Veröffentlicht in: Daten & Analysen
  • I can advise you this service - ⇒ www.HelpWriting.net ⇐ Bought essay here. No problem.
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • You might get some help from ⇒ www.WritePaper.info ⇐ Success and best regards!
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • If you have any problems with writing, feel free to ask our writers for help! The team of Paper Help HelpWriting.net is ready to help with any kind of academic writing!
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
  • Go here now to unlock your dog's natural intelligence today. ♥♥♥ http://t.cn/Aie4mTQb
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

Dialog programming ABAP

  1. 1. ABAP Training Dialog Programming
  2. 2. ABAP Training Dialog Programming 2 Overview of Components  Unlike report, interface, and conversion development which generally entails the creation of one autonomous program which can be executed independently of other objects, dialog program development entails development of multiple objects, none of which can be executed on its own. Instead, all objects are linked hierarchically to the main program and are executed in a sequence dictated by the program.  Dialog programs are composed of the following main components:  Screens  Module pool  Subroutines  Menus/GUI statuses  Transaction codes
  3. 3. ABAP Training Dialog Programming 3 Screen Overview  Screens are made up of the following components:  Screen attributes  Screen layout/screen elements  Fields  Flow logic  Flow logic is comprised of two events:  The process before output (PBO) event invokes any processing which is to occur before the screen is displayed to the user.  The process after input (PAI) event invokes any processing which is to occur after the user has completed interaction with the screen by invoking any one of the possible functions (I.E. Save, back, enter, etc.).
  4. 4. ABAP Training Dialog Programming 4 Module Pool Overview  The module pool consists of modularized ABAP/4 syntax which is placed inside include programs belonging to the dialog program.  These modules are invoked when called upon by flow logic.  Processing of flow logic and ABAP/4 modules is handled by different processors in the SAP system.  Flow logic is processed by the dialog processor while all ABAP/4 is processed by the ABAP/4 processor.
  5. 5. ABAP Training Dialog Programming 5 Module Pool Overview Contd.. The ABAP/4 module pool consists of the following components:  The main program which will contain a series of include programs. Customer dialog programs should begin with SAPMZ or SAPMY.  Global data declarations in the form of a top include program. The program is named with the last five characters of the main program followed by ‘TOP’ (for TOP include). All data declarations will be placed within this program during development.
  6. 6. ABAP Training Dialog Programming 6 Module Pool Overview Contd.. For modularization purposes, remaining ABAP/4 is developed using the following structure of include programs:  A PBO module include program is created to hold modules invoked by the PBO event of any of the screens in the dialog program. A PAI module include program is created to hold modules invoked by the PAI event of any of the screens in the dialog program. The proper naming convention uses the last five characters of the main program followed by either ‘O’ for PBO modules or ‘I’ for PAI modules, ending with a sequential number beginning with ‘01’. All PBO and PAI modules are placed inside their respective include program until the need for further modularization arises at which point a new include can be created using the next number in the sequence.  If further modularization is required a forms include program is created for subroutines name with the last 5 characters of the main program followed by ‘F’ for forms followed by a sequential number beginning with ‘01’.
  7. 7. ABAP Training Dialog Programming 7 Dialog Processor Vs. ABAP/4 Processor  When processing is transferred from the dialog processor (screen) to the ABAP/4 processor (module pool), the values of all screen fields must be passed to their respective ABAP/4 fields. This data transfer process must also occur when processing returns to the dialog processor form the ABAP/4 processor.  In order for values to pass successfully between the dialog processor and the ABAP/4 processor, screen fields must be named identically to their respective ABAP/4 fields.  In the most basic case, data transfer between the dialog processor and the ABAP/4 processor occurs at the beginning of the PBO event and immediately after the function code is invoked for the PAI event. Exceptions to this include the existence of the field statement in the flow logic or the use of a control table.
  8. 8. ABAP Training Dialog Programming 8 Dialog Processor Vs. ABAP/4 Processor
  9. 9. ABAP Training Dialog Programming 9 Review: Components of Dialog Program  Dialog programs are composed of the following components:  Module pool  Screens  Subroutines  Menus/GUI statuses  Transaction codes  The individual components of a dialog program interact to form an executable transaction.  Screens are processed by the dialog processor. Process before output (PBO) and process after input (PAI) flow logic instructions are read by the dialog processor which in turn invokes the ABAP/4 processor and passes the values of the screen fields to the identically named ABAP/4 fields. The ABAP/4 processor processes the PBO or PAI modules called by the flow logic. When completed, control is returned to the dialog processor and the values of the ABAP/4 fields are returned to the identically named screen fields. This process is repeated as necessary until all instructions have been executed.
  10. 10. ABAP Training Dialog Programming 10 Creating Components Using the Standard Dialog Programming Toolset
  11. 11. ABAP Training Dialog Programming 11 Dialog Programming Toolset Central Component Tool Transaction/ Path All Components* Object Browser SE80 Tools > ABAP Workbench > Object Browser Screen Screen Painter SE51 Tools > ABAP Workbench > Screen Painter ABAP/4 Module Pool ABAP/4 Editor SE38 Tools > ABAP Workbench > ABAP/4 Editor Dictionary Objects (tables, fields, etc.) ABAP/4 Dictionary SE11 Tools > ABAP Workbench > ABAP/4 Dictionary Menu Menu Painter SE41 Tools > ABAP Workbench > Menu Painter Transaction Maintain Transaction SE93 Tools > ABAP Workbench > Development > Other Tools > Transactions
  12. 12. ABAP Training Dialog Programming 12 Dialog Programming Toolset Contd..  Dialog program development utilizes tools available in the ABAP workbench which are the same tools used in developing the standard SAP applications. * Dialog programs should always be developed via the object browser (SE80). When developed by the object browser, all objects become linked to the main program without having to explicitly point each object. Additionally, advanced navigation techniques speed up the process of moving from one object to another.
  13. 13. ABAP Training Dialog Programming 13 Object Browser  Individual tools such as screen painter are invoked from within the object browser in one of two ways:  Example 1: position the cursor on the main program, choose create, then select an object from the object list. After naming the object to be created and choosing ‘create’ again, the associated tool will be launched in create mode.  Example 2: position the cursor on an object in the object list (i.E. Screen) and choose ‘create’. Object browser will then launch the tool associated with the object that was selected.
  14. 14. ABAP Training Dialog Programming 14 Creating Objects Using Forward Navigation  Dialog program objects can also be created using the forward navigation functionality of the SAP system.  For example, during the creation of the flow logic for a screen, clicking on the name of an ABAP/4 module that has not yet been created will result in a system prompt stating that the object you have selected does not exist, ‘do you wish to create the object?’ Choosing ‘yes’ will launch the appropriate tool. In the case described here, the developer will select a program to include the module in and the ABAP editor (SE38) will be invoked.  Creation of objects via standard navigation works for other objects such as global data declarations, include program development, screens, and many other objects. This functionality is available in all phases of development including non-dialog program development.  In dialog program development, creating objects via standard navigation ensures that objects reference each other appropriately. Therefore, this is the preferred method for creating objects in a dialog program.
  15. 15. ABAP Training Dialog Programming 15 Developing a Simple Dialog Program
  16. 16. ABAP Training Dialog Programming 16 Creating a Dialog Program 1) create the main program 2) create top include 3) create first screen Define attributes Define graphical user interface Assign field attributes via field list Define flow logic using dialog flow logic syntax 4) create follow up screens (Same steps as first screen)
  17. 17. ABAP Training Dialog Programming 17 Creating a Dialog Program 5) create ABAP/4 processing logic (modules, sub-routines, etc.) Choose (create if necessary) the PBO include which will contain the ABAP/4 modules Write PBO modules (ABAP/4) Choose (create if necessary) the PAI include which will contain the ABAP/4 modules Write PAI modules (ABAP/4) Create any required subroutines (create include programs if necessary) 6) define ABAP/4 global data TOP include Names must be identical to names used in screens! 7) create menus (if necessary, not yet discussed) 8) create transaction * Steps 5 and 6 can be transposed and often occur together.
  18. 18. ABAP Training Dialog Programming 18 Creating the Main Program  From the object browser (SE80) choose the ‘program’ radio button, enter your program name (SAPMZxxx) and choose display.  Message dialog is displayed ‘the program SAPMZxxx does not exist. Do you want to create the object? Choose ‘yes’.
  19. 19. ABAP Training Dialog Programming 19 Creating Main Program (With Top Include)  A ‘create program’ window is displayed with the name of the main program and a checkbox ‘with top include’ defaulted to ‘X’. To work with an explicit TOP include, leave this box checked. This will cause the system to automatically create a TOP include along with the main program. Choose ‘enter’.  Another ‘create program’ window is displayed for the TOP include which the system will now attempt to create. The default name will be MZxxxTOP. Choose enter.  The ABAP/4 editor (SE38) is invoked and the ‘ABAP/4 program attributes’ screen is displayed. As with all program development, provide a short description and assign relevant attributes.
  20. 20. ABAP Training Dialog Programming 20 Creating Main Program (With Top Include)  Assign the type ‘M’ (default) for module pool. Unlike type ‘1’ programs (reports, some utility programs, etc.), Type ‘M’ programs cannot be executed directly. They must first have a transaction code assigned to them (discussed later).  After saving the main program and leaving the program attributes screen (i.E. Choosing ‘back’ from the menu) you will again be prompted with the ‘create object catalog entry’ screen where a development class is assigned. This time the name of the TOP include program MZxxxTOP will be displayed. You must save from this screen or the TOP include program will not be created.
  21. 21. ABAP Training Dialog Programming 21 Viewing Program From Object List  After saving the TOP include, the object list is displayed from within the object browser.  The main program and the TOP include are displayed in a tree format.  All objects added to the dialog program will be displayed in this hierarchy.  Objects displayed here include: dictionary structures, global data, macros, PBO modules, PAI modules, subroutines, screens, GUI status, GUI title, transactions, and includes.  Although dictionary structures, global data, macros, PBO modules, PAI modules, and subroutines are displayed as independent objects belonging to the main program, they are actually objects defined within the include programs which are also listed. For example, if a PBO module is added to an include program for PBO modules, that module will be displayed underneath the main program under PBO modules and the include program containing that module will be displayed with the include programs.
  22. 22. ABAP Training Dialog Programming 22 Creating Screens  Create the first screen, usually numbered ‘0100’, by positioning the cursor on the main program and choosing ‘create’, or by double clicking on the ‘program object types’ entry of the object browser.  The ‘program objects’ list is displayed with the various types of objects which can be created.  Choose the screen radio button, supply the screen number, and choose ‘create’ at the bottom left of the screen.  Assign the screen attributes. Provide a short description. Choose a screen type (default ‘normal’). Enter the follow-up screen to be processed after completion of current screen.  Save the screen attributes.  Choose the ‘full screen’ button from the top to define the screen layout (‘paint the screen’).
  23. 23. ABAP Training Dialog Programming 23 Defining the Screen Layout  Elements are added to screens using screen painter. Two editors are available in screen painter, the alphanumeric screen painter and the graphical screen painter (as of v3.0 and requires windows 95, windows NT, or UNIX).  In the alphanumeric mode fields are input/OUPUT fields are represented by underlines ‘_’ and text fields are types on the screen. Additionally, graphical elements can be added to the screen (i.E. Group boxes, radio buttons, check boxes, icons, buttons, control tables, step loops) by placing a field on the screen, placing the cursor on the field and choosing ‘graphical element’.  With the graphical screen painter, screen elements are chosen from a graphical list of elements and are placed on the screen using the mouse. Screen fields and objects can then be manipulated in a ‘drag and drop’ fashion.  To add fields from the data dictionary, choose ‘dictionary/program fields’ from the GOTO menu.  As a general rule, screen fields should reference dictionary fields whenever possible.
  24. 24. ABAP Training Dialog Programming 24 Assigning Field Attributes  Attributes must be defined for all screen fields.  Objects taken from the dictionary retain the attributes assigned in the data dictionary unless otherwise specified. These attributes include field name, length, type, etc. And are taken from the data element and data domain.  There are six field list views for defining field attributes. They are located in the menu path Goto > field list views and include: field types, text/templates, general attributes, display attributes, modification groups, and list/mc currencies.
  25. 25. ABAP Training Dialog Programming 25 Assigning Field Attributes  Additionally, field attributes can be assigned and displayed by selecting the field and choosing ‘attributes’ from the screen painter or by choosing ‘field list’ from the flow logic portion of screen painter.  Field types  Tests/templates  General attributes  Display attribute  Modification groups  List/mc currencies
  26. 26. ABAP Training Dialog Programming 26 Flow Logic and ABAP/4 Modules  Flow logic is defined from the screen painter by choosing ‘flow’ from the screen painter, or by navigating to the desired screen from the object list.  Flow logic consists of a limited syntax which is different than ABAP/4. Its general purpose is to define the flow of execution of dialog programs.  Module statements are inserted in the flow logic to designate which ABAP/4 modules will be executed.  By double clicking on the module name, ‘forward navigation’ will create the empty ABAP/4 module for you in the appropriate include program.
  27. 27. ABAP Training Dialog Programming 27 PBO and PAI Modules  PBO and PAI modules are developed in ABAP/4.  PBO module statements are followed by OUTPUT and PAI module statements are followed by INPUT.  PBO and PAI modules should be placed in separate include programs.  All ABAP/4 statements are placed between the MODULE and ENDMODULE statements.
  28. 28. ABAP Training Dialog Programming 28 Global Data and Top Include  Global data is defined in the TOP include.  Field names must be identical to screen field names for values to pass between the dialog processor and ABAP/4 processor at runtime.  Fields can be created via forward navigation or by going directly to TOP include in the ABAP editor.  If a TOP include is not defined explicitly, data is placed in the global data area and the TOP include is used implicitly.
  29. 29. ABAP Training Dialog Programming 29 Creating Transaction Codes Dialog programs (type M) cannot be executed directly from the ABAP editor or transaction SA38, the 'ABAP/4 execute program' transaction. To execute a dialog program, create a transaction code using one of the following methods:  From the object list of the object browser:  Choose the create button.  Choose transaction.  Enter a transaction name (customer transactions begin with Z or Y).  Choose the create button again.  From the 'maintain transaction' utility (transaction SE93, menu path tools > ABAP workbench > development > other tools > transactions):  Enter a transaction name (customer transactions begin with Z or Y).  Choose the create button.
  30. 30. ABAP Training Dialog Programming 30 Creating Transaction Codes Contd….. The following steps are the same in either case:  Specify the type of program. For dialog programs, choose dialog.  Choose enter.  Provide a short description/transaction text.  Specify the program name that the transaction will execute.  Specify the first screen number that should be called by the transaction.  Authorization object should be specified but is not required.  For this case, leave the 'maintenance of standard transaction variant allowed' check box on (allows specification of a customer defined variant to be used each time the transaction is called - see transaction SHD0).
  31. 31. ABAP Training Dialog Programming 31 Creating Transaction Codes Contd…..  Choose save to create the transaction.  To execute the program, enter the transaction code you have created in the system command line with the appropriate system command prefix (/n to overwrite current session with new session, /o to open a new session).
  32. 32. ABAP Training Dialog Programming 32 Transaction Types  Dialog transaction: Used to start a dialog program  Report transaction: Used to start a type 1, on-line/report program (can refer to reports, conversion programs, interface programs, utility type programs etc.)  Variant transaction: Used to start a program using a predefined variant  Area menu transaction: Used to start an area menu. Area menus will be discussed with menu painter. Area menus are developed via transaction SE43 and can be used in place of or along with the standard SAP menu (S000). The menu that a user sees when they first logon is defined at the user level in the user profile.  Parameter transaction: Used to start a program to which parameters can be passed.
  33. 33. ABAP Training Dialog Programming 33 Dialog Naming Standards  Module pool/program name: SAPMZxxx or SAPMYxxx (where xxx can be freely defined characters)  TOP include: first 5 characters correspond to last five characters of first main program name. Last three characters are TOP. Example: MZxxxTOP  PBO include: first 5 characters correspond to last five characters of main program name. Last three characters are Onn, where 'O' stands for output and 'nn' is a number identifying first, second, etc. Include for PBO modules. Example: mzxxxo01, mzxxxo02, etc.
  34. 34. ABAP Training Dialog Programming 34 Dialog Naming Standards  PAI include: first 5 characters correspond to last five characters of main program name. Last three characters are inn, where 'I' stands for output and 'nn' is a number identifying first, second, etc. Include for PAI modules. Example: mzxxxi01, mzxxxi02, etc.  All other includes begin with last 5 characters of main program followed by a three character description.
  35. 35. ABAP Training Dialog Programming 35 Defining Elements on the Screen
  36. 36. ABAP Training Dialog Programming 36 Dictionary Fields in Dialog Program To add a dictionary program field to a screen following steps required:  Navigate to Goto > Dict/program fields or simply choose the Dict/ProgFields button from the graphical screen painter within the full screen editor  Enter the table or program that contains the field you want to use, then enter the field name.  Select the field by positioning your cursor on the line retrieved from the dictionary.  Choose the appropriate attributes that you wish to use.
  37. 37. ABAP Training Dialog Programming 37 Dictionary Fields in Dialog Program  Choose the copy button and position the field on the screen with the mouse.  When using a dictionary field in a dialog program, the field receives the same attributes as defined in the data dictionary.  Field type and length will be the same as defined by the domain of the field chosen.  All entries to the field will then be verified against the type and permitted values as determined by the domain. If a check table exists, all entries to this field during program execution will be verified in reference to the check table. Invalid entries will produce an error message.
  38. 38. ABAP Training Dialog Programming 38 Radio Buttons and Check Boxes in Dialog Programs  Radio buttons are mutually exclusive fields.  Radio buttons must be assigned to a graphical group within which exclusivity is decided. For radio buttons defined by a graphical group, the system only allows one radio button to be activated within that group.  Within the programming logic, radio buttons and check boxes can be interrogated using their field name to determine whether they are active or not. If the radio button or check box has been activated by the user, the value is 'X' (can be read as anything other than space), otherwise, the value will be space.
  39. 39. ABAP Training Dialog Programming 39 Icons In Dialog Programs  Icons can be added to text fields in the screen painter by double clicking on the field and assigning one of the icons from the icon list.  Additionally, status icons can be added to the screen (new with graphical screen painter). A status field is an output field with an icon. Status fields are used when the actual icon that will be used is not decided until runtime.  Status icons are assigned via the function module ICON_CREATE (see transaction SE37 for further details). Status icons must have an internal length of at least 6 (6 does not include any text). Visualized length must be at least 2.
  40. 40. ABAP Training Dialog Programming 40 The OK Field, Setting The OK-CODE  Every screen by default is given one field of type ‘OK’.  The OK field is a PAI field which holds the function code invoked by the user at runtime. Remember, the start of the PAI is triggered by the user invoking one of the possible function codes (I.E. Enter, save, back, exit, etc.).  The OK field, like SY-UCOMM, can be read at runtime to determine how the program should react.  The OK code field receives the value of the function code defined in the menu (to be discussed with menu painter) or by the function code assigned to a pushbutton in screen painter.
  41. 41. ABAP Training Dialog Programming 41 The OK Field, Setting The OK-CODE  You must assign a field name for the OK type field. The OK field can be displayed in screen painter by choosing the ‘field list’ button from the flow logic of screen painter, or by going to field list views -> field types. The OK field is the last field displayed. It has the type OK and no name.  You must define a name for the screen field AND declare a field in the ABAP global data. Within the global data declaration (TOP include) this field can by defined ‘LIKE SY- UCOMM’ or as a four character field. This field is commonly named OK_CODE or OKCODE.  At runtime, this field will receive the value for the function code that was assigned to the option the user chose.
  42. 42. ABAP Training Dialog Programming 42 Field Input Validation
  43. 43. ABAP Training Dialog Programming 43 Automatic Field Input Validation Automatic field input checks are carried out at the following levels:  Field definition attributes from the field list  Required entry (?), field type (C, N, F, P, I, etc.).  Definition of attributes from data dictionary  Field type from dictionary must match input (CHAR, DEC, etc.).  If check tables are specified in the domain of the dictionary field, the entry is validated against the check table.
  44. 44. ABAP Training Dialog Programming 44 Automatic Field Input Validation  If the dictionary field's domain has enumerated values, input is validated against these fixed values.  F4 functionality (possible entries) is also available for dictionary fields as defined in the data dictionary.  Automatic field input checks occur immediately after a function has been invoked (I.E. User presses enter) but before the PAI is processed. Additional field input checks can be programmed.  If all entries pass the checks, processing continues with the PAI modules, otherwise message dialog occurs prompting the user for further action.
  45. 45. ABAP Training Dialog Programming 45 User Defined Field Input Validation User defined field input checks can be added to a program in the following ways:  Field input checking in the module pool Within the PAI modules, fields input by the user can be interrogated by the program to determine whether processing should continue. This can be used in conjunction with the flow logic which will determine how the error will be presented to the user and what options they will have for continuing.  Field input checking in the flow logic The limited flow logic syntax also allows for a certain degree of automatic field input checking.
  46. 46. ABAP Training Dialog Programming 46 Field Statement for Input Validation
  47. 47. ABAP Training Dialog Programming 47 User Defined Field Input Validation Contd.  To perform a field level input check in the module pool, the field statement is used in the flow logic syntax in conjunction with a call to the module where the check is performed.  Use of the field statement opens the associated field for input if execution of the called module results in an error or warning message. The screen is redisplayed without processing the PBO modules for that screen. When the screen is redisplayed, only the field identified in the flow logic prior to the module call is ready for input. All other fields have been changed to display only.  When the user has corrected any errors, processing resumes at the precise point where the failure occurred.
  48. 48. ABAP Training Dialog Programming 48 Field Statement for Input Validation
  49. 49. ABAP Training Dialog Programming 49 Data Transfer and the Field Statement  Field statements can exist anywhere in the flow logic that preserves the integrity of the process.  By default, data transport of field values from the dialog processor (screen work area) to the ABAP processor (ABAP work area) occurs at the beginning of the PAI event for all values not contained in a field statement.
  50. 50. ABAP Training Dialog Programming 50 Data Transfer and the Field Statement  For fields placed within a FIELD statement, values are not passed from the screen to the ABAP work area until the field statement is encountered by the dialog processor.  Any given field can exist in multiple field statements.  Values of fields contained in multiple field statements will remain in the screen work area until all field statements referencing that field have been processed. Values are temporarily transferred to the ABAP processor for the duration of the check performed by the field statement until the last field statement is successfully completed.
  51. 51. ABAP Training Dialog Programming 51 Chain Statement  The chain statement is available to allow further control of field input checking.  By using the chain statement, you can control which fields will become ready for input following a negative result from an input checking module.  All fields within the CHAIN, ENDCHAIN statement become ready for input.  Fields can be used in more than one chain and/or field statement.  Additionally, any manipulation of screen fields that may have occurred in the PAI event prior to the field input check will not show up when the screen is redisplayed unless the manipulated fields were part of the chain statement that resulted in an error (or warning).
  52. 52. ABAP Training Dialog Programming 52 Chain Statement
  53. 53. ABAP Training Dialog Programming 53 Conditional Execution of Modules
  54. 54. ABAP Training Dialog Programming 54 ON INPUT / ON REQUEST Overview  Field input checking does not always needed. For instance, if no input value was entered or the value has not changed since last time the screen was executed, there may not be a need to perform field input validation.  Conditional execution of modules techniques allow the developer to control whether field input checking routines should be executed. Two methods are available:  ON INPUT (flow logic) will result in execution of validation processing only if those fields are not at their initial value.
  55. 55. ABAP Training Dialog Programming 55 ON INPUT / ON REQUEST Overview  ON REQUEST/ON CHAIN-REQUEST (flow logic) will result in execution of validation processing only if the value of a screen field has changed since the last time the screen was called using.  When utilizing the FIELD statement to perform input checks, using the additional ON INPUT specification will avoid execution of the specified modules unless the fields have a value other than their initial value. Remember, the initial value is dictated by the type definition either in the data dictionary or the screen field attributes.  ON CHAIN-INPUT can be used to check if at least one screen field within a CHAIN ENDCHAIN statement is not at its initial value before processing continues.
  56. 56. ABAP Training Dialog Programming 56 On Request / On Chain-request
  57. 57. ABAP Training Dialog Programming 57 On Request / On Chain-request  When utilizing the FIELD statement to perform input checks, using the additional ON REQUEST specification will stop the system from processing the specified modules unless the value of the field was changed by the user.  ON CHAIN-INPUT can be used to check if at least one screen field within a CHAIN ENDCHAIN statement has been changed by the user before processing continues
  58. 58. ABAP Training Dialog Programming 58 Field Input Checks in the Flow Logic
  59. 59. ABAP Training Dialog Programming 59 Module Pool Overview  Limited field input checks can also be performed within the flow logic. The basic commands available are select and values.  Select within the flow logic performs much like the select single used in ABAP/4.  Using the values parameter within the flow logic allows you to enumerate permitted values.
  60. 60. ABAP Training Dialog Programming 60 Message Handling in a Dialog Program  (E)rror and (w)arning messages: Have the result of redisplaying the screen where the error occurred, re- opening those fields for input that were part of the CHAIN or FIELD statement that produced the error.  (A)bend messages: The text of an abend message is displayed on the current screen. After the user presses enter, processing ends and the user is returned to the initial screen. This becomes important in the case of database updates and logical units of work (LUW).  (I)nformation messages: Interrupt processing and display on the screen which produced the message. When user hits enter, processing continues from the point of interruption.  (S)uccess messages: Displayed on the next screen.
  61. 61. ABAP Training Dialog Programming 61 Parameter Ids and SAP Memory
  62. 62. ABAP Training Dialog Programming 62 Parameter Ids and SAP Memory  SAP memory allows for storage of values using parameter ids. If a field is given a parameter ID, its values can be sent to memory or received from memory during runtime.  Values sent to memory reside for the term of the current logon session. Therefore, values can be stored beyond the execution time of one program and can be used by many programs.  SET and GET parameter are used to send field contents to memory and get field contents from memory.
  63. 63. ABAP Training Dialog Programming 63 Parameter Ids and SAP Memory  SET parameter id copies field contents to the SAP memory at the PAI event.  GET parameter id retrieves contents of the parameter ID from memory and places them in the designated fields at the end of the PBO event if the field is at its initial value. If the field already contains data from a module performed in the PBO of the current screen, GET parameter will not overwrite the contents.  SET and GET parameter should not be used for intermediate storage in passing values from one program to another because parameter ids are session independent within a user logon. Therefore, it is possible for a parameter ID to inadvertently be set in one session while being used in another.
  64. 64. ABAP Training Dialog Programming 64 Parameter Ids and SAP Memory - Example  Many standard SAP programs use parameter ids and SAP memory. Notice that when working with a program in the ABAP/4 editor (SE38), SET and GET parameter are used. Once working with a program in the editor, should the editor be left and restarted, the program parameter will contain the name of the program last worked on. Similarly, the report execution program (SA38), utilizes the same parameter ID. Thus, not only will the name of the last program that was been worked on in the editor default in the program name of the editor after leaving and returning, but it will also display when entering transaction the report execution transaction.
  65. 65. ABAP Training Dialog Programming 65 Using SAP Memory in Dialog Programs  In order for SAP memory to receive the contents of fields, SET parameter must be specified for the appropriate fields and parameter ids. Likewise, for fields to receive the contents of SAP memory, GET parameter ID must be specified for the appropriate fields and parameter ids.  Not all fields have an associated parameter ID. Parameter ids are defined at the data element level of dictionary fields. If the field you wish to use SET and/or GET parameter with does not have a parameter ID assigned, you can define one in table TPARA.  In dialog programs, you can specify SET and GET parameter as field attributes. SPA and GPA checkboxes correspond to set parameter and get parameter respectively.
  66. 66. ABAP Training Dialog Programming 66 Using SAP Memory in Dialog Programs (Cont.)  In addition to specifying SET and GET parameter via the field attributes of the screen painter tool, SET and GET parameter can be specified in ABAP/4 programs (i.E. In PBO modules).  The above examples indicate the proper syntax for use of SET and GET parameter. Notice the use of MEMORY ID in the above parameters declaration.*  * PARAMETER ID and MEMORY ID are very similar. However, when using SAP memory in the parameters statement, notice the requirement of the key word MEMORY ID rather than PARAMETER ID. Likewise, notice the use of PARAMETER ID in the SET and GET statements. Also, notice the use of single quotes for SET and GET parameter, but no quote when using MEMORY ID.
  67. 67. ABAP Training Dialog Programming 67 Additional Field and Screen Attributes
  68. 68. ABAP Training Dialog Programming 68 Setting Default Values for Screen Fields SAP provides three ways to define default values for screen fields in a dialog program:  Utilizing SAP memory and parameter ids: SET/GET parameter  Fields can be defined so as to retrieve data from SAP memory which has been set by the current program or some other program where the same parameter ID was used.  SET and GET parameter can be activated via the field attributes of screen painter or within the ABAP/4 module pool.
  69. 69. ABAP Training Dialog Programming 69 Setting Default Values for Screen Fields Setting default values in the PBO modules (ABAP/4)  Additionally, default values can be assigned within the ABAP/4 modules that are called by the PBO event. This method simply assigns values to the ABAP/4 fields and passes them to the screen fields before the screen is displayed to the user.  Utilizing the HOLD DATA screen attribute to set default values  Much like the field attributes which can be assigned in screen painter, screens also have attributes which can be maintained. When the HOLD DATA screen attribute has been activated, the system stores all screen field values in memory upon leaving that screen. The stored values then appear as default values the next time that screen is called.
  70. 70. ABAP Training Dialog Programming 70 Setting Default Values in the PBO Modules (ABAP/4)  In the above example, the PBO event of the current screen calls MODULE INITIALIZTION, which checks to see if a value has been entered in the screen field 'year'. If not (the field is initial), the year is defaulted to the current year. At the end of the PBO event the ABAP/4 field value is sent to the screen field and displayed to the user.
  71. 71. ABAP Training Dialog Programming 71 The HOLD DATA Screen Attribute to Set Default Values  From the full screen editor, choose GOTO > SCREEN ATTRIBUTES. By activating the hold data check box, screen field values will be saved. The next time this screen is called, the saved values will again appear.  Copying of saved values to the screen fields will occur after the GET parameter instruction and will therefore overwrite contents set by GET parameter. This is only true if the user has not left the current session, as HOLD DATA is only valid during the life of the current session.
  72. 72. ABAP Training Dialog Programming 72 Positioning the Cursor on a Screen  By default, the cursor will appear on the first input field of a screen. However, a default cursor position other than the first field of a screen can be set by the programmer via screen attributes or within the ABAP/4 modules.  Using screen attributes to set the cursor position  The screen attributes function of screen painter (GOTO > SCREEN ATTRIBUTES from screen painter) allows you to specify the desired default cursor position. By placing the field name where the cursor should first appear in the 'cursor position' of the screen attributes function, the new default location is set.
  73. 73. ABAP Training Dialog Programming 73 Positioning the Cursor on a Screen (Cont.)  Using the module pool to set the cursor position  Cursor position can be set dynamically in the module pool using the statement SET CURSOR FIELD '<field name>'.  Notice that the field name is in single quotes. Field name can be set up as a variable within the PBO module whose value is the appropriate name. If this method is used, the quotes are not necessary.  When using a variable to hold the field name, the variable must be defined globally.  For more information on SET CURSOR, use the help function of the ABAP editor for the keyword SET.
  74. 74. ABAP Training Dialog Programming 74 Additional Screen FIELD Attributes  Field attributes can be maintained via screen painter.  If you wish for a field to use a matchcode object from the data dictionary, you specify the matchcode name in the matchcode field of dictionary attributes within screen painter.
  75. 75. ABAP Training Dialog Programming 75 Additional Screen FIELD Attributes Contd… The following is a partial list of field attributes which may be used:  Dictionary attributes  SET parameter  GET parameter  Foreign key check  Upper/lower case  Program attributes  Input/output field  Output field only  Required field
  76. 76. ABAP Training Dialog Programming 76 Additional Screen FIELD Attributes Contd…  Possible entries button  Right justified  With leading zeros  Display attributes  Fixed font  Bright  Invisible  2D display For a full list of field attributes, choose the FIELD LIST button from the full screen editor.
  77. 77. ABAP Training Dialog Programming 77 Menu Painter
  78. 78. ABAP Training Dialog Programming 78 Creating a GUI Status Via the Object Browser  Menus (GUI status) allow you to define the processing alternatives a user will have when they come to a screen. When creating a menu, you have the ability to assign functions codes to drop down menus from the menu bar, to buttons in the application tool bars (tool bar always appears at top of screen; I.E. Print, save, etc.), To buttons which will appear across the top of a screen underneath the application tool bar, and to function keys (i.E. F11 for save, shift + F12 for print, etc.)  Menus are crated using the menu painter tool of the ABAP development workbench.  For dialog programs, the menu painter tool is invoked via the object browser by choosing the create button, selecting the GUI status radio button, naming the status, and choosing the create button again.
  79. 79. ABAP Training Dialog Programming 79 Creating a GUI Status Via the Object Browser Contd…….. You must specify the status type:  SCREEN used for creating a GUI status for a full screen which has a menu bar, pushbuttons, and input/ouput fields.  DIALOG BOX used for screens that do not have a menu bar and that request only pushbuttons  LIST used for a full screen with a menu bar, pushbuttons AND LIST FUNCTIONS (i.E. Scrolling)  List in dialog box is used for a dialog box that contains a list. Menu buttons available but no menu bar.
  80. 80. ABAP Training Dialog Programming 80 Assigning Function Codes Assigning function codes to GUI status. This can be done in the following areas of the GUI status:  Drop down menus that appear at the top of the screen  Standard and application tool bars at top of screen (icon for print etc.)  Function keys  Push buttons (displayed along top of screen)  When creating a GUI status, you have the option of displaying standard menu options which you can then change and/or add to. To do this, double-click on the button immediately to the left of the test 'display standards' text.  In order for menus to become active, they must be generated after creating them and after each time they are changed.
  81. 81. ABAP Training Dialog Programming 81 Assigning Function Codes - Drop Down Menus
  82. 82. ABAP Training Dialog Programming 82 Assigning Function Codes - Drop Down Menus II  To define drop down menus, you double-click on the menu you wish to creator modify (from within the menu painter tool after choosing the status type)  You can define up to 6 different drop down menus per GUI status. Each drop down menu can have up to fifteen menu options. Each menu option may have a function code assigned to it by placing a freely defined function code to the left of the test under the FUNC header. Alternately, each menu option may reference a sub-menu which again has 15 menu options.  To create a sub-menu, type the name of the sub-menu in the menu line, do not put a function code, and double-click on the line. The a new menu with 15 possible options will appear. Again, function codes or other sub-menus can be assigned.
  83. 83. ABAP Training Dialog Programming 83 Assigning Function Codes - Drop Down Menus II  To add a separator line to a menu line, position the cursor on the line you wish to add the separator to, navigate to EDIT > INSERT > SEPARATOR LINE.  Menu items can be activated or deactivated using the active <-> inactive button of menu painter. If the menu option has been deactivated, the user sees the option but it is greyed out and cannot be chosen.
  84. 84. ABAP Training Dialog Programming 84 Assigning Function Codes - Tool Bars
  85. 85. ABAP Training Dialog Programming 85 Assigning Function Codes - Tool Bars II  The next section of menu painter allows you to assign function codes to the tool bars at the top of the screen.  The first tool bar is considered the standard tool bar (navigate back, exit, cancel, or print, save, etc.). These buttons should not be changed from their standard use. They can be activated by placing the appropriate function codes in them or removing them.  The application toolbar lies immediately below the standard tool bar. These are the options that appear and are specific to the application the GUI status is used for. These are also activated by placing the function codes in the appropriate places. You can assign an icon to the function codes of the application toolbar. They can appear with text or without.
  86. 86. ABAP Training Dialog Programming 86 Assigning Function Codes - Function Keys  The next part of the menu painter allows you to define function codes for the function keys. By placing function codes in the appropriate fields, those function key/code combinations will be activated within the program that references the GUI status.  You define function keys in the 'freely assigned function keys' section of the menu painter.
  87. 87. ABAP Training Dialog Programming 87 Assigning Function Codes - Function Keys
  88. 88. ABAP Training Dialog Programming 88 Invoking the Menu/GUI Status  Each screen may have a different menu created for it. One screen may even have multiple menus defined for it. The menu that is displayed to the user is specified in the ABAP/4 program.  The GUI status must be invoked in the PBO modules.  The proper syntax is SET PF-STATUS '<status name>'. The status must belong to the dialog program that is calling it.
  89. 89. ABAP Training Dialog Programming 89 Setting the Title Bar Dynamically  It is also possible to create title bars which can be set dynamically by the PBO modules. By setting the titlebar in the program the default titlebar taken from screen attributes is overwritten.  Titlebars are created from the object browser like all other objects.  Place the cursor on the highest node of the dialog program hierarchical structure (main program) and choose create. Choose titlebar and give the titlebar a name. Choose create again and create your titlebar.  To set the titlebar in the module, use the statement: SET TITLEBAR '<titlebar name>
  90. 90. ABAP Training Dialog Programming 90 Assigning Function Code Attributes & Using AT EXIT-COMMAND  To assign function code attributes, place cursor on function code from menu painter and double click.  ‘Exit’ type function codes can be assigned type ‘E’ for exit. This allows use of the AT EXIT-COMMAND statement in the PAI flow logic. AT EXIT- COMMAND is a conditional execution statement. Only when a function code with type ‘E’ is invoked will that module be executed.  All function codes which will be used to allow the user to exit out of the current program should be assigned type ‘E’.  The default function type is blank which allows the developer to freely define how the program will react that function. Additional types are transaction and system. For a full list of available function types choose help from the attribute assignment screen of menu painter.
  91. 91. ABAP Training Dialog Programming 91 Updating the Database - ABAP4 Open SQL
  92. 92. ABAP Training Dialog Programming 92 Updating the Database - ABAP/4 Open SQL - Overview  There are four commands available for updating the database:  INSERT - adds new records to the database table  UPDATE - changes one or more fields of specified records  MODIFY - changes existing records or adds new ones  DELETE - deletes specified table records  With all four options, SY-SUBRC is set to 0 for success and something other than 0 for failure.  When database changes occur, the SAP database triggers a command in the underlying database system.  Updates occur in a sequence of related steps which are grouped together to make up a logical unit of work (LUW).
  93. 93. ABAP Training Dialog Programming 93 Updating the Database - ABAP/4 Open SQL - INSERT  INSERT <dbtab> adds the contents of the table work area (defined in the tables statement) to the database table. Note that authorization checks are not supported by the INSERT statement. These must be included by the programmer if required.
  94. 94. ABAP Training Dialog Programming 94 Updating the Database - ABAP/4 Open SQL – INSERT II  INSERT INTO <dbtab> VALUES <identically structured work area> adds the contents of the identically structured work area to the table. Tables: SFLIGHT. Data: FS_SFLIGHT like SFLIGHT. Move 570 to FS_SFLIGHT-MANDT. Move 'LH' to FS_SFLIGHT-CARRID. Move ... Insert into SFLIGHT values FS_flight.
  95. 95. ABAP Training Dialog Programming 95 Updating the Database - ABAP/4 Open SQL – INSERT III  INSERT <dbtab> FROM TABLE <itab> adds the contents of the internal table to the database table. Tables: SFLIGHT. Data: begin of INT_SFLIGHT. Include structure SFLIGHT. Data: end of INT_SFLIGHT. . . Move 570 to INT_SFLIGHT-MANDT. Move 'LH' to INT_SFLIGHT-CARRID. Move ... Append INT_SFLIGHT. . . Insert SFLIGHT from table INT_SFLIGHT.
  96. 96. ABAP Training Dialog Programming 96 Updating the Database - UPDATE  UPDATE <dbtab> changes a record in the database table. If not suitable record is found, the update will fail with a return code (SY-SUBRC) not equal to 0.  Note that authorization checks are not supported by the UPDATE statement. These must be included by the programmer if required. Tables: SFLIGHT. Select * from SFLIGHT Where CARRID like 'l%'. Move '*' to SFLIGHT-CARRID. Update SFLIGHT. If SY-SUBRC NE 0. Message e001 with text-001. "Update failed ENDIF. ENDSELECT. If SY-SUBRC NE 0. Message e001 with text-002. "No records updated ENDIF.
  97. 97. ABAP Training Dialog Programming 97 Updating the Database – UPDATE II  UPDATE <dbtab> FROM TABLE <itab> changes the corresponding records of the database table to the values of the internal table. Tables: SFLIGHT. Data: begin of INT_SFLIGHT. Include structure SFLIGHT. Data: end of INT_SFLIGHT. Select * from SFLIGHT into INT_SFLIGHT. Loop at INT_SFLIGHT where ... If INT_SFLIGHT-CARRID = ... Move 'LH' to INT_SFLIGHT-CARRID. Move ... Modify INT_SFLIGHT. ENDIF. Endloop. . Update SFLIGHT from table INT_SFLIGHT.
  98. 98. ABAP Training Dialog Programming 98 Updating the Database – UPDATE III  UPDATE <dbtab> SET <field x> = <value> WHERE <field y> = <value> changes only those table fields specified with SET for all records in which the WHERE condition is met. Tables: SFLIGHT. Update SFLIGHT Set CONNID = '0064' Currency = 'USD' Where CARRID = 'LH' And PLANETYPE = 'a319'. If SY-SUBRC NE 0. Message e003 with text-003. "No records updated ENDIF.
  99. 99. ABAP Training Dialog Programming 99 Updating the Database – DELETE  DELETE <dbtab> deletes only the table record with the key which corresponds to the key values of the dbtab work area.  Note that authorization checks are not supported by the DELETE statement. These must be included by the programmer if required. Tables: SFLIGHT. Move 'LH' to SFLIGHT-CARRID. Move '0064' to SFLIGHT-CONNID. Move '19990324' to SFLIGHT-FLDATE. Delete SFLIGHT.
  100. 100. ABAP Training Dialog Programming 100 Updating the Database – DELETE II  DELETE <dbtab> WHERE deletes all table entries for which the WHERE condition is met. Tables: SFLIGHT. Delete from SFLIGHT Where CARRID = 'LH' And CONNID = '0064'.
  101. 101. ABAP Training Dialog Programming 101 Updating the Database – DELETE III  DELETE <dbtab> FROM TABLE <itab> deletes all database table entries for which the key matches one of the keys from the internal table itab. Tables: SFLIGHT. Data: begin of INT_SFLIGHT. Include structure SFLIGHT. Data: end of INT_SFLIGHT. Select * from SFLIGHT Where ... into INT_SFLIGHT. . . . Delete SFLIGHT from table INT_SFLIGHT.
  102. 102. ABAP Training Dialog Programming 102 Logical Units of Work (LUW) and Database COMMIT
  103. 103. ABAP Training Dialog Programming 103 Dialog Steps and COMMIT WORK  SAP dialog programs (transactions) are broken down into several dialog steps.  A dialog step consists of the part of the program that begins immediately following the users choice of a function (i.E. Enter, continue, etc.) With the PAI event and ends immediately following the completion of the last instruction of the PBO event for the next screen.  Although several update commands may be included in one dialog step, changes to the database for those commands do not occur until the SAP system issues a COMMIT WORK or a ROLL BACK WORK command. At that point, the database connection is closed.
  104. 104. ABAP Training Dialog Programming 104 Dialog Steps and COMMIT WORK  After COMMIT WORK has occurred the database has been transformed to its new state.  In the case of ROLL BACK WORK the database remains in the same state it would be in if no update commands were executed.  In the R/3 system, COMMIT WORK or ROLL BACK WORK commands are processed at the end of each dialog step (after each screen, just before the next screen is displayed) by default.  ROLL BACK WORK, which backs out any database change instructions that have occurred since the last database commit, is executed in place of COMMIT WORK if an append message has been output any time prior to the closing of the database connection for the current COMMIT WORK event.  When a rollback occurs, the system keeps the log entries for the current commit. These entries can be maintained via transaction SM13.  COMMIT WORK and ROLL BACK WORK can both be stated explicitly in an ABAP/4 program and thus will trigger the COMMIT WORK event. This method is used in ASYNCHRONOUS UPDATES.
  105. 105. ABAP Training Dialog Programming 105 Logical Unit of Work (LUW)  SAP dialog programs (transactions) are also broken down into logical units of work (LUWs).  A logical unit of work consists of the time time immediately following one database COMMIT through the end of the next database COMMIT. If no specific program instructions specify otherwise (i.E. As in the case of asynchronous update commands), an LUW directly corresponds to a dialog step.  From the functional perspective it is possible that the committing of database changes is not suitable after each dialog step (after each screen). For this purpose, asynchronous updates are possible which allow several consecutive dialog steps to be grouped together into one LUW.
  106. 106. ABAP Training Dialog Programming 106 Asynchronous Updates  Asynchronous updates are used when the developer wishes to combine several consecutive dialog steps into one logical unit of work (one database level commit).  Two methods are available for performing asynchronous updates:  CALL FUNCTION '<function name>' IN UPDATE TASK - in this case, the function called is designated as an update type function. All database update commands (INSERT, MODIFY, CHANGE, DELETE) are placed inside the function to be called. Within the program, rather than specifying UPDATE <dbtab> etc., The update function with the relevant open SQL statements will be called. This places the update requests into a log table rather than passing them to the database. All entries remain in the log table until COMMIT WORK is explicitly specified in the ABAP/4 program (syntax: COMMIT WORK). At this point, all update requests placed in the log table since the last COMMIT WORK will be sent to the database. Likewise, if any updates failed in any of the function calls and the program handled the failing return code (IF SY-SUBRC NE 0...) With an append (type a) message, the log entries are flagged with an error and no database changes occur for the current LUW.
  107. 107. ABAP Training Dialog Programming 107 Asynchronous Updates Contd……..  PERFORM <subroutine name> ON COMMIT - in this case, the subroutines contain the database update commands. By specifying ON COMMIT, the update requests are not sent to the database until the COMMIT event is triggered by an explicitly stated COMMIT WORK in the ABAP/4. Like calling a function IN UPDATE TASK, any append messages prior to closing the database connection will result in a rollback.
  108. 108. ABAP Training Dialog Programming 108 Asynchronous Updates Contd…….. Update functions and subroutines are the same as standard functions and subroutines with the following exceptions:  CALL FUNCTION '<function name>' IN UPDATE TASK: No export parameters can be used when defining the function interface and no exceptions can be raised. When maintaining the update function module via FUNCTION MODULE ADMINISTRATION, update with immediate start (V1) or update with delayed start must be chosen. V1 updates are time critical updates and will occur prior to V2 updates. If an error occurs during the V2 update, the V2 entries as well as any V1 entries associated with the current commit remain in the log table, although the V1 entries will correspond to updates which were committed while the V2 error entries will correspond to uncommitted updates.  PERFORM <subroutine name> ON COMMIT: When using ON COMMIT, no parameter passing is permitted.
  109. 109. ABAP Training Dialog Programming 109 SAP Locking Logic
  110. 110. ABAP Training Dialog Programming 110 Creating Lock Objects  Lock objects are created in the ABAP/4 dictionary (TOOLS > ABAP/4 WORKBENCH > ABAP/4 DICTIONARY pushbutton or transaction SE11).  You can also defined lock objects in the object browser (TOOLS > ABAP/4 WORKBENCH > OBJECT BROWSER pushbutton. From the object browser click on the dictionary objects radio button from the single objects section of the screen, and click on the EDIT pushbutton.  Customer defined lock objects begin with 'EZ'.  By creating a lock object, you create a view for one or more records or several tables and selected fields.  When a lock object is created, the system automatically creates two function modules. ENQUEUE_<lock object> and DEQUEUE_<lock object>.  Information on existing lock objects can be found in the ABAP/4 dictionary information system.  SAP locking logic
  111. 111. ABAP Training Dialog Programming 111 Creating Lock Objects (Cont.) Two modes are available for lock objects:  Exclusive - only one user can have a lock at a time.  Shared - only one user can have change access, others may share access in view mode
  112. 112. ABAP Training Dialog Programming 112 Using Lock Objects  Within your program, locks entries must be set and deleted.  Locks should be set prior to perform the read access. Locks must be deleted after the update has been performed.  You must also set lock objects to be deleted for the BACK and CANCEL functions, the system does not do this automatically.
  113. 113. ABAP Training Dialog Programming 113 Setting and Deleting Lock Entries  ENQUEUE_,lock object> checks whether a lock was set for the same object. If so, the exception FOREIGN_LOCK is raised. If the object is not locked, the lock is set by the function module.
  114. 114. ABAP Training Dialog Programming 114 Setting and Deleting Lock Entries  By specifying _WAIT = 'X', the system automatically continues trying to set a lick at regular intervals until it succeeds or exceeds the time limit set in the profile parameters.
  115. 115. ABAP Training Dialog Programming 115 Setting and Deleting Lock Entries  _SCOPE is important in asynchronous updates: _SCOPE = 1 - lock remains in the dialog program _SCOPE = 2(default) - lock is retained for the update program _SCOPE = 3 - both dialog program and update program are owners; There are two entries per object
  116. 116. ABAP Training Dialog Programming 116 Setting and Deleting Lock Entries Module ENQUEUE input. Call function 'ENQUEUE_EZ_SFLIGHT' Exporting CARRID = SFLIGHT-CARRID CONNID = SFLIGHT-CONNID FLDATE = SFLIGHT-FLDATE ... _Scope = '2' _Wait = 'x' Exceptions FOREIFN_lock = 01 System_failure = 02. ....
  117. 117. ABAP Training Dialog Programming 117 Setting and Deleting Lock Entries Module DEQUEUE. Call function 'DEQUEUE_EZ_SFLIGHT' Exporting CARRID = SFLIGHT-CARRID CONNID = SFLIGHT-CONNID FLDATE = SFLIGHT-FLDATE ... _Scope = '2'
  118. 118. ABAP Training Dialog Programming 118 Dynamic Screen Modification
  119. 119. ABAP Training Dialog Programming 119 Modifiable SCREEN Field Attributes  Screen fields and their modifiable attributes are automatically stored in a system internal table named SCREEN.  The initial values of the table fields are set by the attributes defined in screen painter.  To determine the current attributes of the screen from within the ABAP/4 modules, you can LOOP at the SCREEN table where the field is the one you wish to obtain information for to get the value.  You can also change the value by modifying the values in the SCREEN internal table.
  120. 120. ABAP Training Dialog Programming 120 Changing Field Attributes in the Module Pool  Screen modifications must be programmed in the PROCESS BEFORE OUTPUT modules.  When reading the SCREEN table, the WHERE condition is NOT supported (you also cannot READ from the screen table).  When modifying screen fields, the value 1 indicates true, or on, and the value 0 indicates false, or off.  SCREEN ACTIVE* = 0 makes the field invisible and not ready for input. It has the same effect as the 3 combined statements SCREEN-INVISIBLE = 1, SCREEN-INPUT = 0, and SCREEN-OUTPUT = 0.  *SCREEN-ACTIVE can only maintained from the module pool as long as it has not been set to invisible in the field attributes of screen painter.
  121. 121. ABAP Training Dialog Programming 121 Dynamic Screen Sequence
  122. 122. ABAP Training Dialog Programming 122 Determination of Follow-up Screen  Default follow-up screens are set in the screen attributes when a screen is first created.  Screen sequence can be set dynamically at runtime in the module pool.  Methods for dynamically setting screen sequence include: Set screen Call screen Leave screen
  123. 123. ABAP Training Dialog Programming 123 Using SET SCREEN to Set Follow-up Screen  SET SCREEN nnnn temporarily overwrites the default next screen with SCREEN nnnn.  After processing of called screen, follow-up screen of calling screen is invoked unless current screen is terminated with the LEAVE SCREEN statement.  Screen nnnn must be in same module pool as calling screen.  To leave the current screen for good you can also use LEAVE TO SCREEN nnnn.
  124. 124. ABAP Training Dialog Programming 124 Using SET SCREEN to Set Follow-up Screen  SET SCREEN 0 LEAVE SCREEN and LEAVE TO SCREEN 0 take program back to location that screen was called from. Set screen 0100. . Set screen 0100. Leave screen. . Leave to screen 0100. . Set screen 0. Leave screen. . Leave to screen 0.
  125. 125. ABAP Training Dialog Programming 125 Using CALL SCREEN to Set Follow-up Screen  CALL SCREEN nnnn interrupts the current screen, inserting screen nnnn and any of its subsequent screens.  Called screen nnnn must be a screen in the same module pool as calling screen.  LEAVE PROGRAM can be used to terminate current program and return to the place where terminated program was called. . . Call screen 100. . . . Leave program. . .
  126. 126. ABAP Training Dialog Programming 126 Calling a Dialog Box (Screen) and Returning  By calling a screen defined as a modal dialog box and specifying STARTING AT and ENDING AT you can specify position and size of the called screen.  If ENDING AT is left out, the size of the dialog box is taken from the ‘USED’ size in its screen attributes.
  127. 127. ABAP Training Dialog Programming 127 Calling a Dialog Box (Screen) and Returning  Processing is taken to PBO of called dialog screen. SET SCREEN 0, LEAVE SCREEN could be placed in the program logic of the PAI for the dialog screen to return to the called screen. . . Call screen 100 Starting at 20 10 Ending at 60 30. . .  Called screen must be defined as a modal dialog box in the screen attributes
  128. 128. ABAP Training Dialog Programming 128 Linking Dialog and List Processing
  129. 129. ABAP Training Dialog Programming 129 Linking Dialog and List Processing  By linking program components, dialog (screen) processing and list (report) processing and be combined.  List programs (reports) can call a sequence of screens, and dialog programs can interrupt screen processing to perform list processing.  When called from a dialog program, list processing can occur in a full screen or in a modal dialog box. All interactive reporting techniques (drill-down, list modification, etc.) Are available.
  130. 130. ABAP Training Dialog Programming 130 Dialog to List Processing  LEAVE TO LIST-PROCESSING will cause the system to branch from dialog processing to list processing.  All PAI modules of the calling screen are processed BEFORE the list is output to the screen.  In order to invoke the standard list menu, use the command SET PF- STATUS SPACE.  By specifying AND RETURN TO SCREEN nnnn, processing will resume at screen nnnn after list processing. List processing ends when the user has chosen the BACK (F3) command or when the system encounters the LEAVE LIST-PROCESSING statement.
  131. 131. ABAP Training Dialog Programming 131 List to Dialog Processing  Within a list processing program, CALL SCREEN nnnn can be used to call a dialog box or a full screen.  The called screen must be a component of the calling program.  Specifying LEAVE TO SCREEN 0 from within a module invoked by the called screen will return control to the calling program.
  132. 132. ABAP Training Dialog Programming 132 Table Controls
  133. 133. ABAP Training Dialog Programming 133 Table Control Concept  Table controls were introduced as a special screen field type with v3.0.  The purpose of a table control is to allow multiple lines (rows) of the same type to exist on one screen.  When declaring screen fields, dictionary fields may only be used one time on each screen. Table controls are a structure much like an internal table which contains one or more rows of one or more columns.  Prior to v3.0 the STEPLOOP structure was used to allow multiple occurrences of one field type to exist on a screen.
  134. 134. ABAP Training Dialog Programming 134 Table Control Concept  Table controls are a significant enhancement to the STEPLOOP concept and have the following characteristics:  Resizable table grid for displaying and editing data  Columns can be resized and repositioned by the user  Lines and columns can be selected by the user  Single, multiple, and ‘all’ line selection possible  Columns can be selected by header  Horizontal and vertical scrolling  Key columns can be fixed  Individual field (cell) attributes can be modified at runtime.
  135. 135. ABAP Training Dialog Programming 135 Mechanics of the Table Control  To process table controls, data is read from the database into an intermediary internal table in the module pool.  During the PBO event, data is read line by line from the internal table into the control table in screen painter.  During the PAI event, the contents and attributes of the control table are once again fed line by line into the internal table in the module pool, and then if necessary, into the database.  Table controls are created in screen painter like other fields. With the graphical screen painter table controls can be selected and placed on the screen. In the alphanumeric screen painter choose EDIT -> create element -> table control.  From within the ABAP program, the table control is defined of type ‘TABLEVIEW’, which is a complex type structure storing all of the attributes of the control table.
  136. 136. ABAP Training Dialog Programming 136 Structure of Table Control  To process table controls, data is read from the database into an intermediary internal table table in the module pool. During the PBO event, data is read line by line from the internal table into the control table in screen painter. During the PAI event, the contents and attributes of the control table are once again fed line by line into the internal table in the module pool, and then if necessary, into the database.  Table controls are created in screen painter like other fields. With the graphical screen painter table controls can be selected and placed on the screen. In the alphanumeric screen painter choose EDIT -> create element -> table control.  From within the ABAP program, the table control is defined of type ‘TABLEVIEW’, which is a complex type structure.
  137. 137. ABAP Training Dialog Programming 137 Processing a Table Control  LOOP AT and ENDLOOP statements are used for processing control table in the flow logic.  ON REQUEST determines whether the user has manipulated the control table. If not, no modifying of the control table is necessary.  If the user has made changes, you must reflect these changes to the fields of the table control in the relevant internal table so they appear after the next PBO is executed (user hits enter or scrolls).  By processing the complex structure, field attributes (field selected, visible, etc….) Can be checked and/or changed.