ACCR01 SAPMACCR01 Create Accrual/Deferral Document

Creating customer-specific objects within the customer name range

SSCR (SAP Software Change Registration) is a procedure, for registering all manual changes to SAP source coding and SAP Dictionary objects.

What is the difference between modifications and enhancements ?
Modifications mean making changes to the SAP standard functionality.
Enhancements mean adding some functionality to SAP standard functionality

Modifying standard code can lead to errors
Modifications mean more work during software upgrades

Customer exits are not available for all programs and screens within the R/3 standard applications. You can only use exits if they already exist within the SAP R/3 System . Otherwise you have to opt for modifications

Menu exits
Screen exits
Function module exits
Keyword exits

Adding functionality to R/3 applications. Function module exits play a role in both menu and screen exits.

To take advantage of the exits available within standard R/3 applications, you need to create an add-on project. This project lets you organize the enhancement packages and exits you want to use. The add-on project also allows you to hang add-on functionality onto the exit hooks contained with SAP enhancements.

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

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

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.

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.

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.