Tuesday, June 29, 2010

LESSON 41 SUBSCREEN TABSTRIPS

SUBSCREEN TABSTRIPS:

A subscreen area is a reserved rectangular area on a screen, into which you place another screen at runtime. Subscreen areas may not contain any other screen elements. To use a subscreen, you create a second screen (with the type subscreen), and display it in the subscreen area you defined on the main screen.

A subscreen is an independent screen that you display within another screen. You may want to use a subscreen as a way of displaying a group of objects in certain circumstances, but not in others. You can use this technique to display or hide extra fields on the main screen, depending on the entries the user has made.

A second use for subscreens is that different programs can use the same subscreens. To do this, you must execute other screen programs within your main program.

You can include more than one subscreen on a single main screen. You can also determine the subscreens dynamically at runtime.

You can use subscreens in the following circumstances:
In screen enhancements (screen exits), Within other screen objects (tabstrip control)
In the Modification Assistant In Web transactions.

If the subscreen is larger than the subscreen area in which it is called, the system only displays as much of it as will fit onto the screen. However, you can use the Scrollable attribute to ensure that, if the screen is too big, the system will display scrollbars.

The resizing attributes control whether the size of a subscreen area can be changed vertically and horizontally. You should set these attributes if you want the size of the subscreen area to change with the size of the whole window. You can use the minimum size attribute to set a lower limit beyond which the subscreen area cannot be resized.

The Context menu attribute allows you to assign a context-sensitive menu to the output fields on the subscreen screen.

The following restrictions apply to subscreens:
CALL SUBSCREEN ... is not allowed between LOOP and ENDLOOP or between
CHAIN and ENDCHAIN.

A subscreen may not have a named OK_CODE field.
Object names must be unique within the set of all subscreens called in a single main screen.

Subscreens may not contain a module with the AT EXIT-COMMAND addition.
You cannot use the SET TITLEBAR, SET PF-STATUS, SET SCREEN, or LEAVE
SCREEN statements in the modules of a subscreen.

To create a subscreen area, choose subscreen from the object list in the Screen Painter and place it on the screen. Fix the top-left hand corner of the table control area, and then drag the object to the required size.

In the Object text field, enter a name for the subscreen area. You need this to identify the area when you call the subscreen.

To use a subscreen, you must call it in both the PBO and PAI sections of the flow logic of the main screen. The CALL SUBSCREEN statement tells the system to execute the PBO and PAI processing blocks for the subscreen as components of the PBO and PAI of the main screen. You program the ABAP modules for subscreens in the same way as for a normal screen (apart from the restrictions already mentioned).

If the subscreen is not in the same module pool as the "main program", the global data of the main program is not available to the subscreen, and the data from the screen will not be transferred back to the program. You must program the data transfer yourself (for example, using a function module that exports and imports data, with an appropriate MOVE statement in the subscreen coding).

If you want to use subscreens in the screens of several different programs, you should encapsulate the subscreens in a function group and use function modules to transport data between the program in which you want to use the subscreen and the function group.

You can pass data between the calling program and the function group using the interfaces of the function modules.

This is the technique used for customer subscreens (screen enhancements).

You use function modules to transport data between the calling program and the function group.

To declare the data from the calling program to the subscreen of the function group, use a module before the subscreen call. This should call a function module whose interface you can use to pass the required data to the function group.

The function module call must occur before the subscreen call. This ensures that the data is known in the function group before the PROCESS BEFORE OUTPUT processing block of the subscreen is called.

In the PAI module of the calling screen, the sequence is reversed: You call the PROCESS AFTER INPUT processing block of the subscreen before calling a function module to pass the data from the function group back to the calling program.

For the data from the calling program to be available globally in the function group, you must transfer the interface parameters from the function module into global data fields of the function group.

The function module that you use to transfer the data from the calling program into the function group must copy its interface parameters into the global data in the function group.

The function module that you use to transfer data from the function group to the calling program must copy the corresponding data from the global data of the function group into its interface parameters.

Tabstrip controls provide you with an easy, user-friendly way of displaying different components of an application on a single screen and allowing the user to navigate between them. Their intuitive design makes navigation much easier for end users.

Tabstrip controls are a useful way of simplifying complex applications. You can use tabstrip controls wherever you have different components of an application that form a logical unit. For example, you might have a set of header data which remains constant, while underneath it, you want to display various other sets of data.

You should not use tabstrip controls if

You need to change the screen environment (menus, pushbuttons, header data, and so on) while processing the application components. The screen surrounding the tabstrip must remain constant.

The components must be processed in a certain order. Tabstrips are designed to allow users to navigate freely between components.
The components are processed dynamically, that is, if user input on one tab page leads to other tab pages suddenly appearing.

Tabstrip controls are compatible with batch input processing.

A tabstrip control consists of individual pages. These consist of the page area and the tab title.

The tab may only have one row of tab titles.

If the tabstrip control contains too many pages, it will not be possible for all of the tab titles to be displayed at once. If this happens, the system displays a scrollbar with which you can scroll through the remaining tab pages. In the top right-hand corner of the tab is a pushbutton. If the user clicks this, a list of all of the tab titles is displayed. The active tab title is marked with a tick.

A tabstrip control consists of individual pages. These consist of the page area and the tab title.

The tab may only have one row of tab titles.

If the tabstrip control contains too many pages, it will not be possible for all of the tab titles to be displayed at once. If this happens, the system displays a scrollbar with which you can scroll through the remaining tab pages. In the top right-hand corner of the tab is a pushbutton. If the user clicks this, a list of all of the tab titles is displayed. The active tab title is marked with a tick.

A tab page consists of a tab title, a subscreen area, and a subscreen.

From a technical point of view, the system handles tab titles like pushbuttons.

The contents of tab pages are displayed using the subscreen technique. You assign a subscreen area to each tab page, for which you can then call a subscreen.

As well as the general "Object name", "Starting position" and static size attributes, tabstrip controls also have special tabstrip attributes.

You create a tabstrip control in the following three steps:

Define the tab area
Define the tab titles and, if necessary, add further tab titles
Assign a subscreen area to each tab page.

To create a tabstrip area, choose Tabstrip from the object list in the Screen Painter and place it on the screen. Fix the top-left hand corner of the table control area, and then drag the object to the required size.

Assign a name to the tabstrip control in the "Object name" attribute. You need this name to identify your tabstrip control.

In your ABAP program use the CONTROLS statement to declare an object with the same name. Use TABSTRIP as the type.

The type TABSTRIP is defined in the type pool CXTAB. The field ACTIVETAB contains the function code of the tab title of the currently active tab page. The other fields are reserved for internal use.

The default number of tab pages for a tabstrip control is two.

Technically, tab titles are treated in the same way as pushbuttons. They have an object name, a text, a function code, and a function type. You enter these in the "Object name", "Object Text", "FctCode" and "FctType" fields of the obje ct attributes.

A tab title can have the function type ' ' (space) or 'P'. If the function type is ' ' (space), the PAI processing block is triggered when the user chooses that tab, and the function code of the tab title is placed in the OK_CODE field. If the function type is 'P', the user can scroll between the different tab pages with the same type without the PAI processing block being triggered. For further details, refer to the following pages.

If you want your tabstrip control to have more than two pages, you must create further tab titles. To do this, choose Pushbutton from the object list in the Screen Painter and place it in the tab title area.

You must assign a subscreen area to each tab page.

The subscreen area assigned to a tab page is automatically entered as the "Reference object" (in the Dictionary attributes) for the tab title of that page.

To assign a subscreen area to one or more tab pages, choose the relevant tab title in the fullscreen editor, choose the Subscreen object, and place it on the tab page.

Alternatively, you can assign a single subscreen area to several tab pages by entering the name of the subscreen area directly in the "Reference object" field of the attributes of the relevant tab pages.

If you have assigned a different subscreen area to each tab page in a tabstrip control, you can scroll between the pages locally at the frontend.

To do this, you must send all of the subscreens to the front end when you send the main screen itself.
All of the tab titles in the tabstrip control must also have function type 'P'.

Now, when you scroll between the different tab pages, there is no communication between the presentation server and the application server.

When the user chooses a function on the screen that triggers PAI processing, the system processes the PAI blocks of all of the subscreens as well. This means that all of the field checks are run. In this respect, you could regard the tabstrip control as behaving like a single large screen.

Local scrolling in tabstrip controls is more appropriate for display transactions.

To program a tabstrip control to scroll locally at the front end, you must:
Assign a separate subscreen area to each tab page; a subscreen will be sent to each of these when the screen is processed.

Call all of the subscreens from the flow logic.
Assign function code type 'P' to all of the tab titles.

The system hides any tab page whose subscreen contains no elements that can be displayed.

If there are no tab pages containing elements that can be displayed, the system hides the entire tabstrip control.

If all of the tab pages share a single subscreen area, the program analyzes the function code of the chosen tab title to determine which screen is displayed.

There are two steps in this process:

In the PAI processing block, the program determines which tab page needs to be active, based on the tab title chosen by the user.

When the PBO processing block is processed again, the program displays the corresponding Screen .

During this process, the system only checks the fields of the subscreen that is actually displayed.

If you want the application program to process scrolling in a tabstrip control,
All of the tab pages must share a common subscreen area
All of the tab titles must have the function code type ' ' (space), and
In the flow logic, you must use a variable to call the screen that is to be displayed in the subscreen area.


In the PAI block, you must call a module in which the function code of the active tab title is placed in the field ACTIVETAB of the structure you created in your program with type TABSTRIP. In the example above, this is MY_TAB_STRIP.

The PBO processing block must contain a module, before the subscreen is called, in which you place the number of the subscreen in the corresponding variable. In order for the screen to be processed the first time (before the user has had a chance to choose a tab title), you must assign an initial value to this field.

You can hide a tab page at runtime by setting the corresponding tab title to inactive using the system table SCREEN (SCREEN-ACTIVE = '0'). You should do this before processing the tabstrip control for the first time, to ensure that the screen environment remains constant.

You can now create tabstrip controls on selection screens. They allow you to create logical groups of fields, and make large selection screens more user-friendly.

The following requirements must be met if you are to use selection screens with tabstrip controls in your R/3 System:

GUI version 4.0 or higher
Frontend: Motif, Windows 95, MacOs, NT 3.51 or higher.

For a selection screen with tabstrips, you must define:

•A subscreen area on the selection screen to accommodate the tabstrip control
•The individual tab titles
•Selection screens as subscreens for the individual tab pages

Since it is possible to define selection screens as subscreens, you can include selection fields that you create in this way in any other screens. Selection screens as subscreens are processed similarly to other screens.

You define a selection screen as a subscreen as follows:
SELECTION-SCREEN BEGIN OF SCREEN AS SUBSCREEN
[NESTING LEVEL ] [NO INTERVALS].
...
SELECTION-SCREEN END OF SCREEN .

Optional additions: [NESTING LEVEL ]. Each box around a tabstrip control increases the NESTING LEVEL by one.
[NO INTERVALS]. This option hides the HIGH fields for any selection criteria defined using SELECT-OPTIONS on the screen.

You define a subscreen area for a tabstrip control on a selection screen as follows: SELECTIONSCREEN BEGIN OF TABBED BLOCK FOR LINES.
SELECTION-SCREEN END OF BLOCK .

The size of the subscreen area in lines is defined by .

The system automatically generates a CONTROLS statement (CONTROLS:
TABSTRIP_BLOCKNAME TYPE TABSTRIP.) You must not write your own CONTROLS
statement. If you try to do so, a syntax error results.

You define the individual tab pages as follows:
SELECTION-SCREEN TAB (length) USER-COMMAND [DEFAULT [PROGRAM /SCREEN ]].
Optional additions: [DEFAULT [PROGRAM /SCREEN ]].
Assign the selection screen to a tab page. If you use the DEFAULT addition, you must also use the SCREEN addition. The PROGRAM addition is optional. You only need it if the screen co mes from another program.

You can delay specifying the link between the tab title and the selection screen until runtime. You can also change an existing assignment at runtime. To do this, fill the structure blockname. This is created automatically for every tabstrip block. The structure has the same name as the tabstrip block, and contains the fields PROG, DYNNR, and ACTIVETAB.

If you define a selection screen as a subscreen, you can display it on a normal screne or in a tabstrip control that is embedded in a normal screen.

All you need to do is define the selection screen as a subscreen with the relevant selection options and input parameters. You can then define a subscreen area on the screen and embed the subscreen screen in it, by calling the subscreen screen in the PBO event and, if necessary, in the PAI event as well.


LESSON 42 SCREEN ELEMENTS ANDTABLE CONTROLS

SCREEN ELEMENTS ANDTABLE CONTROLS:



A table control is an area on the screen in which the system displays data in tabular form. It is processed using a loop. The top line of a table control is the header line, which is distinguished by a gray separator.

Within a table control, you can use table elements, key words, templates, checkboxes, radio buttons, radio button groups, and pushbuttons. A line may have up to 255 columns; each column may have a title.

You can display or enter single structured lines of data using a table control.

Features:
Resizeable table for displaying and editing data.
The user or program can change the column width and position, save the changes, and reload them later.

Check column for marking lines. Marked lines are highlighted in a different color.
Line selection: Single lines, multiple lines, all lines, and deselection
Column headings double as pushbuttons for marking columns.
Scrollbars for horizontal and vertical scrolling.
You can fix any number of key (leading) columns.
Cell attributes are variable at runtime.

Users can save display variants for table controls. These variants can be saved by each user, along with the basic setting, as the current display setting or as the default display setting.

The table control contains a series of attributes that are controlled entirely at the presentation server:
These are:

Horizontal scrolling using the scrollbar in the table control
Swapping columns
Changing column widths
Marking columns
Marking lines

The PAI processing block is triggered when you scroll vertically in the table control or save the user configuration.

As well as the normal "Object name", "Start position on screen" and "Static size" attributes, table controls also have special table control attributes.

The "Special table control attributes" determine the table type and display options for a table control, as well as whether it can be configured by the user. The fields stepl and loopc of structure syst contain information about the loop processing used with table controls (see following pages).

For further information about the static attributes, refer to the online documentation.

When you create a table control, you must create:

A table control area.
Table control fields.

To create a table control area, choose the table control object from the object list in the Screen Painter and place it in the screen work area. Fix the top-left hand corner of the table control area, and then drag the object to the required size.

In the "Object name" attribute, assign a name to your table control. In the ABAP program, declare a structure with the same name, containing the dynamically changeable attributes of the table control.

The CONTROLS statement declares a complex data object with the type TABLEVIEW
(corresponding to the type CXTAB_CONTROL, declared in type group CXTAB in the ABAP
Dictionary). At runtime, the data object (my_control) contains the static attributes of the table control.

You maintain the initial values (static attributes) in the Screen Painter. The USING SCREEN addition in the CONTROLS statement determines the screen whose initial values are to be used for the table control.

You can reset a table control to its initial attributes at any time using the statement REFRESH CONTROL FROM SCREEN . does not have to be the same as the initial screen of the table control.

You create fields in a table control using the Dict./Program fields function. This involves the following steps:
Enter the name of the structure whose fields you want to use in the table control and press ENTER.

In the field list, choose the fields that you want to use and choose OK.
Position the cursor in the table control area and click the left mouse button.
The system places all of the selected fields in the table control. If the fields have data element texts, the system uses these as column headings.

Alternatively, you can position individual input/output fields in the table control area, each of which generates a single column.

When you create a table control, the system automatically proposes one with a selection column.

The selection column behaves like a checkbox. It must therefore be a field with length 1 and data type CHAR. You must enter the field name in the attributes of the table control.

The selection column is a field of the structure used for transport between the screen and the ABAP program.

The runtime attributes of a table control, which are stored in the structure declared using the CONTROLS statement, can be divided into general attributes and column attributes.

The general attributes contain information about the attributes of the table control as a whole, such as, for example, the number of fixed columns.

The column attributes are stored in an internal table (one entry per column of the internal table).

For each column, it maintains the attributes stored in the structure SCREEN, plus the special table control column attributes column position, a selection and a visibility flag, and a field for the displayed width.

For information about the names of the attributes and their precise meanings, refer to the keyword documentation in the ABAP Editor for the CONTROLS statement (then choose Tableview -> CXTAB_CONTROL).

You can change a table control dynamically by modifying the contents of the fields in the table control structure declared in your program.

The fields of the table control structure also provide information about user interaction with the table control. For example, you can use the selected field to determine whether the user has selected a particular column.

For performance reasons, you read the data for the table control once from the database and store it in an internal table using an array fetch.

The system fills the table control lines from this internal table.

Before you can display data from an internal table in a table control, you must first fill the table. Make sure that you do not fill the internal table in every PBO event, but only when the key fields change (in the above example, airline and flight number).

For the table control processing, you need to know how far the user can scroll vertically (the size of the internal table). You should therefore use the DESCRIBE TABLE statement to find out the number of entries in the internal table, and save this in the LINES field of the table control.

There is only one work area for processing lines in the table control. For this reason, you need a LOOP … ENDLOOP. structure in both the PBO and PAI events for each table control.

In the PBO processing block, you must fill one line of the table control with the corresponding line from the internal table in each loop pass.

Similarly, in the PAI processing block, you must pass the changes made in the table control back to the correct line of the internal table.

When you process functions, you must distinguish between those that should only apply to individual lines of a table control, and those that should apply to the entire screen.

There are three steps involved in displaying buffered data from the internal table in the table control:

The system loops through the lines of the table control. The lines of the screen table are processed one by one. For each line, the system carries out the following steps:

The current line of the internal table is placed in the work area of the internal table. (Note that it is possible to scroll in the table on the screen.)
The data from the work area of the internal table is copied into the relevant line of the table control.

When you use table controls on a screen, the field transport sequence changes.

In the PBO processing block, data is transferred from the ABAP program to the screen after each loop pass in the flow logic. The rest of the screen fields are filled, as normal, at the end of the PBO.

The loop statement in the flow logic LOOP AT INTO WITH CONTROL starts a loop through the screen table, and reads the line of the internal table corresponding to the current line of the screen table, placing it in .
is the name of the internal table containing the data, is the name of the work area for the internal table, and is the name of the table control on the screen.

If the fields in your table control have the same structure and name as those in the work area , the system can transport data between the ABAP program and the screen automatically (step 3).

If you are not using the same structure for the table control fields and the work area of the internal table, you must call a module between LOOP and ENDLOOP that moves the data from the work area into the screen fields (MOVE-CORRESPONDING TO …) .

The system calculates the value of -TOP_LINE when you scroll, but not when you scroll a page at a time outside the table control.

Transferring changed values from the table control back to the internal table involves the following three steps:

The system loops through the lines of the table control. The lines of the screen table are processed one by one. For each line, the system carries out the following steps:

The data from the current line of the table control is copied into the header line of the internal table.

The data in the work area must then be placed in the line of the internal table corresponding to the line of the table control that is being processed. (Note that it is possible to scroll in the table on the screen.)

In the PAI processing block, all screen fields that do not belong to a table control and that are not listed in a FIELD statement are transported back to the work fields in the ABAP program first.

The contents of the table control are transported line-by-line to the corresponding work area in the ABAP program in the appropriate loop.

Lastly, the fields that occur in FIELD statements are transported directly before the corresponding statement.

The LOOP AT . ... ENDLOOP block processes a loop through the lines of the table on the screen.

If the fields on your screen have the same names as the fields in the internal table, you must return the data from the header line of the internal table to the body of the table itself. You do this using the field -current_line.

If the fields on your screen do not have the same names as the fields in the internal table, you must first copy the data into the header line of the internal table. You can then copy the data back into the internal table itself. You can also use the field -current_line to do this.

You can modify the attributes of a table control by overwriting the field contents of the structure created in the CONTROLS statement.

To change the attributes of individual cells temporarily (!), change the table SCREEN in a PBO module that you processes between LOOP and ENDLOOP in the flow logic (LOOP AT SCREEN, MODIFY SCREEN).

In the LOOP, the runtime system initializes the attributes set statically for the table control in the Screen Painter. You can only change these in a module called from a loop through the table control.

You can change a table control dynamically by modifying the contents of the fields of its structure.

The fields of the table control structure also provide information about user interaction with the table control. For example, you can use the selected field to determine whether the user has selected a particular column.

It is possible to change the attributes of table control fields temporarily. These changes are only effective while the current screen is being processed.

To do this, you call a module from within the table control loop in the flow logic, in which you change the attributes of the current line.

To change the attributes of the fields of a line in the table control, use a LOOP AT SCREEN. ... ENDLOOP. block to loop through the fields of the current line. Within this loop, you can change the attributes of the fields of the current line of the table control.

You can easily sort the table control display by a particular column using the table control attribute -selected and -screen-name

You can scroll a page at a time in a table control using the table control attribute
-top_line.

In the PAI processing block, you need to know the current number of lines in the corresponding table control.

The system field sy-loopc contains the number of table control lines in the PBO processing block. However, in the PAI, it contains the number of filled lines.

Sy-loopc is only filled between LOOP and ENDLOOP, since it always refers to the current loop.

The LINE parameter in the GET or SET statement refers to the system field sy-stepl, the special loop index in the flow logic.

You calculate the internal table line that corresponds to the selected table control line as follows:

Line = -TOP_LINE + cursor position - 1.

The GET CURSOR statement sets the return code as follows: sy-subrc = 0. The cursor was on a field. sy-subrc = 4: The cursor was not positioned on a field.

If you use a step loop on your screen, you can place the cursor on a particular element within the step loop block. To do this, use the LINE parameter and enter the line on which the cursor should be positioned: SET CURSOR FIELD LINE .

You can also use the OFFSET and LINE parameters together.

LESSON 43 CONTEXT MENUS ON SCREENS

CONTEXT MENUS ON SCREENS:


Context menus (right mouse key, SHIFT F10) are shortcuts for functions that are frequently used.

They can be used to display context-sensitive menus. The context is defined by the position (cursor for SHIFT F10, mouse location for right mouse key) where the user called the context menu. If needed, you can specify the context more precisely with the displayed contents. This permits the user to select functions that are relevant for the current context using the context menu.

You define whether a context menu should be offered when you create a screen object (screens, input fields, table controls, boxes, ...). When the user selects a context menu on an object, an event mechanism (as understood by ABAP objects) calls a certain subroutine in the application program.

The program is assigned a menu reference. The program uses this menu reference to build the display menu. Menus defined with the Menu Painter and dynamic menus can be used here.

After the user executes a menu function, the application program regains control and can react to the user input.

Context menus are assigned to output fields. When you assign a context menu to a box, table control or screen (normal or subscreen), all the subordinate output fields that do not have a context menu inherit that one.

You can create a context menu from within the object list of the Object Navigator. Position the cursor on GUI status and right-click. The Object Navigator automatically opens the Menu Painter.

Of course you can also create a context menu directly in the Menu Painter.

A context menu is a special GUI status. Assign it a name, a descriptive text and status type Context menu.

In a context menu you can link any function codes and function texts. In particular, you can take advantage of your screen pushbuttons. The functions already provided in the interface can be used as an F4 input help.

The link technique ensures consistent context menus in large applications.

You should observe the following rules when designing context menus.

Do not use any functions that cannot be found elsewhere in the system (pushbuttons or interface).

Avoid using more than two hierarchy levels in context menus.

Do not use more than 10 entries, but map all the available pushbuttons.

Use separators to structure the context menu optically.

Place object-specific statements at the beginning of the menu.

Pressing the right mouse key triggers a callback routine in your program. You can create this callback routine in your application program with forward navigation. It is named ON_CTMENU_. You define which callback routine is called in the Screen Painter.

You can directly assign a callback routine to input/output fields, text fields and status icons. Checkboxes, radio buttons and pushbuttons do not have their own callback routines. However, these fields can inherit context menus from boxes or screens.

If you assign a callback routine to a table control, it is triggered for all the fields of the table control that do not have their own callback routine.

The callback routine has the following form:
FORM ON_CTMENU_ USING p_menu TYPE REF TO cl_ctmenu.
.
ENDFORM.

The context menu is built with a method call for the instance of class cl_ctmenu that was passed.

Clicking with the right mouse key on an output field triggers the corresponding callback routine.

You can now use the static method load_gui_status of class cl_ctmenu to load a context menu that was predefined in the Menu Painter. Using other methods of class cl_ctmenu (see next slide) you can also completely rebuild the context menu or modify a loaded menu.

If the user triggers a function in the context menu, the corresponding function code is placed in the command field and triggered depending on function type PAI of the screen.

The class cl_ctmenu provides a number of other methods in addition to the static method load_gui_status. You can use them to adjust the context menu at runtime (e.g. using the values in data fields).

The corresponding methods are called within the callback routine.

You can find further information in the documentation for class cl_ctmenu in the Class Builder.



LESSON 44 LISTS IN SCREEN PROGRAMMING

LISTS IN SCREEN PROGRAMMING:

A list is generally used to output mass data. It can be output on either the screen or a printer.

List may contain colors, symbols and icons as well as text.

There is a standard GUI status for lists. Lists may also have a header and up to four lines of column headers. These are independent program objects, and are translatable.

You can also program interactive lists, which allow users to select lines or particular values. A selection triggers further processing. This might, for example, generate a further list containing a detail list.

You fill the corresponding basic list buffer with WRITE statements at PBO or PAI. You can create your own list and column headers by programming a TOP-OF-PAGE event. This event will be triggered whenever a new page is created in the list buffer (NEW-PAGE).

You can direct the output directly to the spool with the NEW-PAGE PRINT ON statement.

To create interactive lists on screens, you can use the list events AT LINE-SELECTION, AT USER-COMMAND, TOP-OF-PAGE, END-OF-PAGE and TOP_OF_PAGE DURING LINESELECTION.

There is no common list buffer outside of a CALL level.

The list display is processed at the end of the screen in which LEAVE TO LIST-PROCESSING was programmed at PBO or PAI.

To direct the output to the spool, use the NEW-PAGE PRINT ON statement, but not LEAVE TO LIST-PROCESSING.

To create a list that is displayed on a screen, use the ABAP statement LEAVE TO LISTPROCESSING.

This sets a switch that ensures that the contents of the list buffer are output once
the current screen has been processed. The SET PF-STATUS SPACE statement ensures that the list is displayed with the standard GUI status for lists.

Once the screen has been fully processed and LEAVE TO LIST- PROCESSING was executed, the list is displayed on list screen 120 (screen for a basis program).

You can also use the following form: LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN 0. SET PF-STATUS SPACE. WRITE ... LEAVE SCREEN.

When the system exits list processing (user presses F3, or ABAP statement LEAVE LISTPROCESSING), the system carries on processing the program with the screen following the one from which the list processing was started. You can override this by using the AND RETURN TO SCREEN addition in the LEAVE TO LIST-PROCESSING statement.

If you include the ABAP statement SUPPRESS DIALOG in a PBO module, the current screen is not displayed.

If you want to display a list in a dialog box within a transaction, you must call a screen, but include the SUPPRESS DIALOG statement in its PBO processing block.

To return to the calling screen after leaving the list, declare: LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN 0.


LESSON45 OVERVIEW OF DATABAE UPDATES

OVERVIEW OF DATABAE UPDATES:


You can update databases either using ABAP's Open SQL commands, or with the database-specific commands of your database's Native SQL command set.

You can access ABAP cluster databases using special ABAP commands.

You can access the data in database tables using the Open SQL commands. The command set includes operations of the Data Manipulation Language (DML). The Data Definition Language (DDL) operations are not available in Open SQL, as these functions are performed by the ABAP Dictionary.

Native SQL commands allow you to carry out both DML and DDL operations.

The commands for ABAP cluster databases enable operations to be carried out on the data in the cluster databases. The tables themselves are created in the ABAP Dictionary as transparent tables.
For general information on cluster tables, refer to the course appendix.

For further information on Native and Open SQL, see the ABAP Editor Keyword documentation for the term SQL.

Each time you access the database using Open SQL, the database interface of each work process (application server) converts this to a database-specific command. For this reason, the ABAP programs themselves are independent of the database used and can be transferred to other system platforms (with a different database system) without additional programming requirements.

SAP database tables can be buffered at the application server level. The aims of buffering are to

Reduce the time needed to access data with read accesses. Data on the application server can be accessed more quickly than data on the database.

Reduce the load on the database. Reading the data from application server buffers reduces the number of database accesses.

The buffered tables are accessed exclusively via database interface mechanisms.

Database accesses with Native SQL enable database-specific commands to be used. This requires a detailed knowledge of the syntax in question. Programs that use Native SQL commands need additional programming after they are transported to different system environments (different database systems), since the syntax of the SQL commands generally varies from one database to the next.

The target quantity can be limited on the database using all the Open SQL commands discussed here.

One or more rows can be processed with a SQL command. Each command also provides the option of specifying the table name dynamically.

In addition to this, each type of operation has a syntax variant, which can be used to change individual fields in a row.

With masked field selections (WHERE LIKE ''), note that '_' masks an individual character and '%' masks a character string of any length (in line with the SQL standard).

For all Open SQL commands, you can edit data in the current client (standard). To do so, you do not specify any command additions and leave the client field non valuated.

If you want to edit data from other clients explicitly, use the SQL command with the addition CLIENT SPECIFIED and enter the number of the client in which the SQL operation is to be carried out in the WHERE clause of the command.

All Open SQL commands return confirmation of the success or failure of the database operation in the form of a return code. This is always returned by the database interface in the sy-subrc system field. The return code '0' (zero) always means that the operation has been completed successfully. All other values mean that errors have occurred. For further details, please refer to the keyword documentation for the command in question.

In addition, the sy-dbcnt system field displays the number of records for which the desired database operation was actually carried out.

Note that Open SQL commands do not perform any automatic authorization checks. You need to carry these out separately (see unit Authorization Checks).

To insert a new row in a database table, enter the command INSERT INTO VALUES . To do so, you must specify the data to be written to the database in the structure (key and non-key fields) before the command.

The structure must be typed according to the row structure of the database table to be updated (DATA TYPE ).

Rows can also be inserted for views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The INSERT command has the two return codes '0' (row could be inserted) and '4' (row could not be inserted, as a row with the same key already exists).

The following ABAP short forms exist:

Short form 1: INSERT [CLIENT SPECIFIED] FROM .
Short form 2: INSERT [CLIENT SPECIFIED].

The second short form requires that the data, which is to be added to the database, be available in a table work area called . This table work area must be declared in the program with TABLES: .

The second short form is forbidden using ABAP Objects.
a database table. The internal table contains the data in the rows that are to be inserted.
The internal table must be typed to row type .

If the operation can be carried on all rows, the return code sy-subrc returns the value zero. If even one data record cannot be created, a runtime error is triggered. This means that no data record is inserted by the command.

You can prevent the runtime error occurring with the addition ACCEPTING DUPLICATE KEYS.
In the event of an error, the addition sets return code 4 instead of the runtime error. The data records that were successfully inserted are not rejected (no DB ROLLBACK).

The sy-dbcnt system field contains the number of rows that were successfully inserted in the database.

The command UPDATE SET = ... = WHERE allows you to change data in one row in a database table. After the SET command, you specify the fields in the rows whose values you want to change and the key of the database row in the WHERE clause. The key must be specified completely; each individual field must be specified with the relational operator '='.

For numeric fields, the data following the SET command may be specified in the form of a "calculation rule" carried out on the database: f = g, f = f + g, f = f - g.

The command has the two return codes 0 (row could be changed) and 4 (row could not be changed).

Rows can also be changed in views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The following g short forms exist:

Short form 1: UPDATE FROM .
Short form 2: UPDATE dbtab.

With short form 1, the entire data record must have been written to the structure (key and non-key fields) before it is called up. The structure must be typed to the row type of the database table (DATA: TYPE . The short form is not field-specific, but sends the entire structure to the database interface.

The second short form requires that the data, which is to be updated in the database, be available in a table work area called . This table work area must be declared in the program with TABLES: .

The second short form is forbidden using ABAP Objects.

If identical changes are to be made to several rows in a table, use the syntax specified on the slide.
Using the WHERE clause, specify the rows for which the change is to be carried out.

The following "calculations" are also possible here for the numerical fields to be changed:
f = g, f = f + g, f = f - g.

The command has the two return codes 0 (at least one row has been changed) and 4 (no rows could be updated).

The sy-dbcnt field contains the number of updated rows in the database table.

There is a short form UPDATE SET = ... = . This requires that a table work area has been created with TABLES and changes the fields specified after SET for all rows in the current client.

The short form is forbidden using ABAP Objects.

If changes are to be made to several rows in a database table, whereby the changes for each row is determined via an internal table, use the syntax UPDATE FROM TABLE .

Here, the internal table contains the data of the rows to be changed (key and non-key fields). The internal table must have the row type .

The command has the two return codes 0 (all rows have been updated) and 4 (at least one row of the internal table was not used to update the database; the remaining rows have been updated).

The system field sy-dbcnt contains the number of rows that have been updated in the database.

The MODIFY command is SAP-specific. It includes the operations of the two commands
INSERT ... and UPDATE...:

In other words, MODIFY FROM inserts a new data record if the structure specifies a data record that does not yet exist in the database.

If the structure specifies an existing data record; the command updates the row in question.

Using the different syntax variants, you can make changes to individual rows, make similar changes to several rows, and carry out operations on sets of records.

All variants of the MODIFY... syntax have the two return codes 0 (all rows were inserted or updated) and 4 (at least one line was not inserted or updated).

The operation can also be carried out on views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The field sy-dbcnt contains the number of rows that have been changed or inserted in the database.

The command DELETE FROM WHERE enables one row to be deleted from a database table. In the WHERE clause, specify all the key fields with the relational operator '='.

The command has the two return codes 0 (row has been deleted) and 4 (row has not been deleted).

A row can also be deleted from views. However, there are two restrictions here: The view may only contain fields from one table and must be created in the ABAP Dictionary with maintenance status 'read and change'.

The following short forms exist:

Short form 1: DELETE [CLIENT SPECIFIED] FROM ,
Short form 2: DELETE [CLIENT SPECIFIED].

Short form 1 requires that the structure has been filled with the key fields of the row to be deleted before it is called up. The structure must have the row type .

Short form 2 requires that the key fields of the row to be deleted be available in a table work area called . This table work area must be declared in the program with TABLES: .

The second short form is forbidden using ABAP Objects.

The command DELETE FROM WHERE enables several rows to be deleted from a database table. Here, you can specify the rows that are to be deleted with the WHERE clause.

The command has the two return codes 0 (at least one row was deleted) and 4 (no rows were deleted).

The system field sy-dbcnt contains the number of rows that have been updated on the database.

To delete several specific rows from a database using a database operation, use the statement DELETE FROM TABLE . The internal table here contains the key fields for the rows that are to be deleted. The internal table must have the row type .

The command has the two return codes 0 (all rows have been deleted) and 4 (at least one row could not be deleted, the rest have been deleted).

There are two ways of deleting all the rows from a table in the current client:

Either DELETE FROM WHERE IN with a blank internal table

or DELETE FROM WHERE LIKE '%'.

The number of rows deleted from the database is shown in the system field sy-dbcnt.

If you receive a return code other than zero from the database interface in response to an Open SQL statement for changing data in the database, you should make sure that the database is reset to the status it had before the change attempt was made. You can do this by means of a database rollback.
The database rollback undoes any changes made to the current database LUW (see the next unit).

For return codes from DB change statements (Open SQL), the most suitable means of triggering a database rollback is to send a termination dialog message (A message or X message). This triggers a database rollback and terminates the associated program.

All other message types (E,W, I) also involve a dialog but do not trigger a database rollback.

You can also trigger a database rollback using the ABAP statement ROLLBACK WORK (without terminating the program at the same time). You should not use the ROLLBACK WORK statement directly, unless you do not want to reset the program context (unlike a termination dialog message).


Tutorials on SAP-ABAP

Adobe Interactive Forms Tutorials

Business Server Pages (BSP)

Userexits/BADIs

Web Dynpro for ABAP (Step by step procedure for web dynpro,Tutorials on Web Dynpro,)

ALV Tutorials

Blog Archive

goodsites