dokumen.tips_sap-dialog-programming.pdf

ABAP Training
Dialog Programming

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

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.).

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.

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.

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’.

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.

Dialog Processor Vs. ABAP/4 Processor

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.

Creating Components Using the Standard
Dialog Programming Toolset

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

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.

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.

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.

Developing a Simple Dialog Program

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)

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.

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’.

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.

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.

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.

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’).

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.

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.

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

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.

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.

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.

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.

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).

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).

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.

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.

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.

Defining Elements on the Screen

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.

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.

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.

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.

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.

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.

Field Input Validation

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.

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.

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.

Field Statement for Input Validation

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.

Field Statement for Input Validation

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.

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.

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).

Chain Statement

Conditional Execution of Modules

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.

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.

On Request / On Chain-request

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

Field Input Checks in the Flow Logic

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.

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.

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.

 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.

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.

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.

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.

Additional Field and Screen Attributes

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.

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.

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.

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.

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.

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.

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.

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

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.

Menu Painter

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.

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.

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.

Assigning Function Codes - Drop Down
Menus

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.

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.

Assigning Function Codes - Tool Bars

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.

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.

Assigning Function Codes - Function Keys

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.

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>

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.

Updating the Database - ABAP4 Open SQL

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).

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.

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.

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.

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.

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.
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.

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.

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.

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'.

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.
Select * from SFLIGHT
Where ... into INT_SFLIGHT.
.
.
.
Delete SFLIGHT from table INT_SFLIGHT.

Logical Units of Work (LUW) and
Database COMMIT

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.

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.

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.

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.

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.

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.

SAP Locking Logic

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

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

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.

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.

 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.

 _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

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.
....

Module DEQUEUE.
Call function 'DEQUEUE_EZ_SFLIGHT'
Exporting
CARRID = SFLIGHT-CARRID
CONNID = SFLIGHT-CONNID
FLDATE = SFLIGHT-FLDATE
...
_Scope = '2'

Dynamic Screen Modification

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.

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.

Dynamic Screen Sequence

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

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.

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.

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.
.
.

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.

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

Linking Dialog and List Processing

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.

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.

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.

Table Controls

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.

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.

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.

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.

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.

dokumen.tips_sap-dialog-programming.pdf

More Related Content

Similar to dokumen.tips_sap-dialog-programming.pdf

Recently uploaded

dokumen.tips_sap-dialog-programming.pdf