Saturday, March 15, 2008

SUBSCREEN TABSTRIPS IN SAP

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.

No comments:

Blog Archive