BC ABAP Programming PHẦN 5 potx

Modifying Screens DynamicallyThe attributes of screen elements are set statically in the Screen Painter when you define them.However, it is possible to override some of these attributes

The component CARRIER2 of the ABAP Dictionary structure DEMOF4HELP isassigned to the input field Its Dropdown attribute is set to L, and it has the outputlength 15 The Value list attribute is empty, and it has the function code CARRIER.The pushbutton has the function code CANCEL with function type E.

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT

PROCESS AFTER INPUT

MODULE CANCEL AT EXIT-COMMAND

13:30:00 NEW YORK SAN FRANCISCO 09:00:00 SAN FRANCISCO NEW YORK 12:00:00 FRANKFURT MIAMI

The component CONNID of the ABAP Dictionary structure DEMOF4HELP is

assigned to the input field Its Dropdown attribute is set to L, and it has the output

Dropdown Boxes

length 30 The Value list attribute is set to A, and it has the function code

SELECTED The pushbutton has the function code CANCEL with function type E.The screen flow logic is as follows:

PROCESS BEFORE OUTPUT

MODULE INIT_LISTBOX

PROCESS AFTER INPUT

MODULE CANCEL AT EXIT-COMMAND

MODULE USER_COMMAND_200

The user cannot type any values into the screen fields When he or she chooses theinput field on screen 100, a value list appears in the list box, compiled from the inputhelp for the field DEMOF4HELP-CARRIER2 This is the search help H_SCARR,which is assigned to the check table SCARR The value list contains the names ofthe airlines When the user chooses an entry, the screen field is filled with the airlinecode, and the PAI event is triggered The module USER_COMMAND_100 checksthe OK_CODE field and calls screen 200

In the PBO event of screen 200, an internal table LIST is filled with values from thedatabase table SPFLI The KEY field is filled with the flight numbers, and otherrelevant information is placed in the TEXT field The table LIST is then passed to thefunction module VRM_SET_VALUES When the user chooses the input field onscreen 200, the TEXT column of the internal table is displayed in the list box Whenthe user chooses an entry, the screen field is filled with the corresponding entry fromthe KEY field, and the PAI event is triggered The module USER_COMMAND_200checks and processes the OK_CODE field

Modifying Screens Dynamically

The attributes of screen elements are set statically in the Screen Painter when you define them.However, it is possible to override some of these attributes in ABAP programs with the help of aspecial internal table

The R/3 System contains a function called field selection, which allows you to change the

attributes of screens dynamically

It is also possible to set the cursor on a screen to a particular position dynamically from yourprogram

Setting Attributes Dynamically [Page 618]

The Field Selection Function [Page 626]

Setting the Cursor Position [Page 637]

Setting Attributes Dynamically

Setting Attributes Dynamically

Each field on a screen has a set of attributes that are fixed when you define the screen in theScreen Painter When an ABAP program is running, a subset of the attributes of each screenfield can be addressed using the system table SCREEN

The SCREEN Table

SCREEN is like an internal table with a header line However, you do not have to declare it inyour program You cannot display it in the Debugger, and cannot use any work area other thanits header line to address it It has the following structure:

REQUIRED 1 C Field input is mandatory Mandatory field

VALUE_HELP 1 C Input help button display Input help

-The final column contains the corresponding attributes of the screen fields in the Screen Painter.You can modify SCREEN in your ABAP program during the PBO event of a screen Its contentsoverride the static attributes of the screen fields for a single screen call The only statements thatyou can use with SCREEN are:

You cannot use any further additions in the LOOP AT SCREEN statement

The component NAME contains the name of the screen field The components GROUP1 toGROUP4 can contain any three-character code These codes allow you to include screen fields

in up to four modification groups Modification groups are like an extra key field for the tableSCREEN that allow you to change the attributes of all of the elements in a group simultaneously.You assign elements to modification groups statically in the Screen Painter, although you canoverwrite them dynamically in a program

The remaining components are for reading and activating or deactivating the display attributes ofscreen fields For all components other than LENGTH, 1 means active and 0 means inactive

ACTIVE, INPUT, OUTPUT, and INVISIBLE

There are certain hierarchy rules between the components ACTIVE, INPUT, OUTPUT, andINVISIBLE They also have different effects depending on their respective static settings

The ACTIVE component has no equivalent in the element attributes Instead, it changes thecomponents INPUT, OUTPUT, and INVISIBLE

At the beginning of the PBO, ACTIVE is always set to 1, regardless of the static attribute settings.Setting ACTIVE to 0 automatically sets INPUT = 0, OUTPUT = 0, and INVISIBLE = 1 Any otherchanges to the settings of INPUT; OUTPUT, and INVISIBLE for the same table row are ignored.Conversely, setting INPUT = 0, OUTPUT = 0, and INVISIBLE = 1 sets ACTIVE to 0, and anyfurther assignment to ACTIVE for the same table row will also be ignored The setting ACTIVE =

1 has no other effect on the attributes The only purpose of the ACTIVE component is to allowyou to make a screen field inactive through a single assignment You should particularly note that

a module call linked to a FIELD statement in the screen flow logic is always executed, even whenSCREEN-ACTIVE = 0 for the field in question If you want to prevent a module from beingprocessed for an inactive field, you must specify the FIELD and MODULE statements separately.There are eight possible combinations of ACTIVE, INPUT, OUTPUT, and INVISIBLE, that havethe following effect on screen fields:

ACTIVE INPUT OUTPUT INVISIBLE Effect

1 1 1 0 Screen field is displayed, even if Invisible is set

statically

Field contents are displayed

Ready for input, even if Input is not set statically.However, not ready for input if the Output only isset statically

1 1 0 0 Screen field is displayed, even if Invisible is set

statically, except when Output only is setstatically

Field contents are not displayed

Ready for input, even if Input is not set statically

1 0 1 0 Screen field is displayed, even if Invisible is set

statically

Field contents are displayed

Not ready for input, even if Input is set statically

1 0 0 0 Screen field is displayed, even if Invisible is set

statically, except when Output only is setstatically

Field contents are not displayed

Not ready for input, even if Input is set statically

Setting Attributes Dynamically

1 1 1 1 Screen field is displayed, even if Invisible is set

statically, except when Output only is setstatically

Field contents are not displayed

Ready for input, even if Input is not set statically.User input is masked by asterisks (*)

1 1 0 1 Screen field is displayed, even if Invisible is set

statically, except when Output only is setstatically

Output is masked by asterisks (*)

Ready for input, even if Input is not set statically.User input is masked by asterisks (*)

Screen field is not displayed, regardless of thestatic attributes

Screen field is not displayed, regardless of thestatic attributes

If a field is statically-defined as Output only, setting INPUT = 1 has no effect INPUT is always 0for these fields Masking user input by asterisks can be used for entering user passwords

If a whole line becomes invisible when you make fields invisible, the screen is automaticallymade smaller You can, however, switch off this attribute in the static screen attributes by

selecting Switch off runtime compression

REQUIRED

When you set REQUIRED = 1, a field that is ready for input is made mandatory Users can onlyleave the screen when all mandatory fields contain an entry Exception: Function codes withtype E and modules with the AT EXIT-COMMAND addition

DISPLAY_3D

When you set DISPLAY_3D = 0, the three-dimensional frame for input/output fields is removed.You cannot use DISPLAY_3D = 1 to create a three-dimensional effect for text fields or screenfields with the Output only attribute

You can set the LENGTH component to a value shorter than the statically-defined output length(vislength) for input/output fields and Output only fields This allows you to shorten their outputlength You cannot shorten other screen elements, or lengthen any screen elements

REQUEST

Setting REQUEST = 1 for a field that is ready for input has the same effect in the PAI event as ifthe user had changed the field contents This means that a conditional module call [Page 578]using ON REQUEST or ON CHAIN-REQUEST would be executed regardless of whether theuser really changed the field REQUEST is automatically reset to 0

Dynamic screen modifications

REPORT DEMO_DYNPRO_MODIFY_SCREEN.

INCLUDE DEMO_DYNPRO_MODIFY_SCREEN_SEL.

DATA: FIELD1(10), FIELD2(10), FIELD3(10),

FIELD4(10), FIELD5(10), FIELD6(10).

DATA: OK_CODE LIKE SY-UCOMM,

SAVE_OK LIKE SY-UCOMM.

DATA: ITAB LIKE TABLE OF SCREEN WITH HEADER LINE.

DATA LENGTH(2) TYPE C.

FIELD1 = FIELD2 = FIELD3 = '0123456789'.

CALL SCREEN 100.

MODULE STATUS_0100 OUTPUT.

CLEAR: ITAB, ITAB[].

SET PF-STATUS 'SCREEN_100'.

PERFORM CHANGE_INPUT USING:

ACT, INP, OUT, INV, REQ, INT, D3D, HLP, RQS.

CALL SELECTION-SCREEN 1100 STARTING AT 45 5.

PERFORM CHANGE_INPUT USING:

ACT, INP, OUT, INV, REQ, INT, D3D, HLP, RQS.

MESSAGE S159(AT) WITH ACT INP OUT INV.

Setting Attributes Dynamically

MODULE REQUESTED INPUT.

MESSAGE S888(SABAPDOCU) WITH TEXT-004.

ENDMODULE.

MODULE STATUS_0200 OUTPUT.

SET PF-STATUS 'SCREEN_200'.

SUPPRESS DIALOG.

LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN 0.

FORMAT COLOR COL_HEADING ON.

WRITE: 10 'ACT', 14 'INP', 18 'OUT', 22 'INV', 26 'REQ',

30 'INT', 34 'D3D', 38 'HLP', 42 'RQS', 46 'LEN' FORMAT COLOR COL_HEADING OFF.

ULINE.

LOOP AT ITAB.

IF ITAB-NAME = ' '.

ULINE.

ELSEIF ITAB-NAME = TEXT-001 OR ITAB-NAME = TEXT-003.

FORMAT COLOR COL_NORMAL ON.

Setting Attributes Dynamically

Demonstration of dynamic screen modifications

List

Visible input/output fieldVisible output fieldVisible output only fieldInvisible input/output fieldInvisible output fieldInvisible output only field

Modification Refresh

The input/output fields are assigned to the fields FIELD1 to FIELD6 in the ABAPprogram These fields, along with the text field TEXT in the top line, are assigned tothe modification group MOD The remaining screen elements are not assigned to amodification group The function codes of the pushbuttons are MODIFY, UNDO, andLIST

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT

MODULE STATUS_0100

PROCESS AFTER INPUT

FIELD FIELD1 MODULE REQUESTED ON REQUEST

MODULE USER_COMMAND_0100

MODULE CANCEL AT EXIT-COMMAND.

If you choose Modification, a selection screen appears, on which you can selectwhich of the components of the SCREEN table should be set to active or inactive Inthe subroutine CHANGE_INPUT, the user input from the checkboxes is convertedinto the digits 0 and 1 Selection screen 1100 is defined in the following includeprogram:

-*

-*

* -SELECTION-SCREEN BEGIN OF SCREEN 1100.

SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME NO INTERVALS PARAMETERS: ACT AS CHECKBOX DEFAULT '1',

INP AS CHECKBOX DEFAULT '1', OUT AS CHECKBOX DEFAULT '1',

INV AS CHECKBOX DEFAULT '0'.

SELECTION-SCREEN END OF BLOCK B1.

SELECTION-SCREEN BEGIN OF BLOCK B2 WITH FRAME NO INTERVALS PARAMETERS: REQ AS CHECKBOX DEFAULT '0',

D3D AS CHECKBOX DEFAULT '1', HLP AS CHECKBOX DEFAULT '0', INT AS CHECKBOX DEFAULT '0'.

SELECTION-SCREEN END OF BLOCK B2.

SELECTION-SCREEN BEGIN OF BLOCK B3 WITH FRAME NO INTERVALS PARAMETERS RQS AS CHECKBOX DEFAULT '0'.

SELECTION-SCREEN END OF BLOCK B3.

SELECTION-SCREEN BEGIN OF BLOCK B4 WITH FRAME NO INTERVALS PARAMETERS LEN TYPE I DEFAULT 10.

SELECTION-SCREEN END OF BLOCK B4.

SELECTION-SCREEN END OF SCREEN 1100.

When you modify the screen, the current contents of the table SCREEN for themodification group MOD are placed in the auxiliary table ITAB in the PBO event Thisrepresents the static settings of the corresponding screen fields SCREEN is thenmodified according to the settings chosen by the user The user input is also stored

in ITAB

The screen is displayed, and the fields that belong to the modification group MODare displayed according to the new attributes stored in SCREEN The contents of theentries for ACTIVE, INPUT, OUTPUT, and INVISIBLE are visible in the status bar

In the PAI event, the module REQUESTED is called if the user changes the contents

of FIELD1 or sets the REQUEST component of the table SCREEN

If the user chooses List, the current contents of the table SCREEN are appended toITAB in the PAI module USER_COMMAND_0100 Screen 200 is then called as amodal dialog box Screen 200 is used to display the list of table ITAB The contents

of the table SCREEN are displayed before and after modification This makes itpossible to compare directly the effects of the input on the individual componentsand the dependencies between the entries

The Field Selection Function

The Field Selection Function

This topic describes how a special function Field selection (transaction SFAW and some functionmodules) support you in changing screen field attributes dynamically

Field Selection - Overview

The function Field selection allows you to change the attributes of screen fields dynamically atruntime However, you should only use this option if you often need to assign different fieldattributes to the same screen for technical reasons In this case, the same rules apply for allfields, so any field modification is clear

The following basic rules apply:

• All fields involved in the field selection process are grouped together in field selectiontables and maintained using the Field selection function

• You can maintain fields for an ABAP program or screen group (see below)

• On screens belonging to the screen group "blank" ('_'), there is no dynamic field

With field selection, you can activate or deactivate the following attributes at runtime:

Field selection distinguishes between influencing fields and modified fields Modified fields must,

of course, be screen fields All fields should relate to the ABAP Dictionary You can do this bycreating corresponding interface work areas in the ABAP program using TABLES At runtime, afunction module analyzes the field contents of the influencing fields and then sets the attributes ofthe modified fields accordingly

Combining Screens into Screen Groups

Rather than maintaining field selection separately for each screen of a program, you can

combine logically associated screens together in a screen group This reduces the amount ofmaintenance required To assign a screen to a screen group, enter the group in the field Screen group on the attributes screen in the Screen Painter

Calling Field Selection

To call field selection, choose Tools → ABAP Workbench → Development → Other tools →

Field selection Maintenance is by program and screen group.

First, you must declare the ABAP Dictionary names of the fields involved Choose Assign tables

to screen group and enter the tables, for example:

Module pool

Screen group

SAPMTXXXBILD

Delete entry

Tables allowed for field selection

Flight connectionsSPFLI

Save your entries and choose Influencing fields to enter the desired influencing fields into the listand optionally specify a NOT condition, a default value, and a field Cust, for example:

The Field Selection Function

Module pool

Screen group

SAPMTXXXBILD

Choose

AirlineSPFLI-CARRID

Delete field Copy template

Influencing fields

Op

NE

Not conditionLH

Def val Cust

The NOT condition is to be understood as a preselection If one of the fields satisfies the NOTcondition, it is not relevant for the following screen modification Using the NOT condition mayimprove performance

Influencing field: SPFLI-CARRID

an influence for the default value This option allows you to maintain all the forms of an

influencing field, which have the same influence, with a single entry

By setting the field Cust accordingly, you can decide whether to allow customers to use thecorresponding field for field selection or not This field selection option is based on the predefinedSAP field selection and allows customers to set screen attributes to suit their own requirementswithin a framework determined by application development Many application areas have theirown special Customizing transactions for this purpose (these are parameter transactions related

to the Transaction SFAC; refer here to the documentation on the function module

FIELD_SELECTION_CUSTOMIZE)

Then, choose Modified fields to enter all modifiable fields into a list, for example:

Delete field Copy template

Modifiable fields

Field no Cust2

You can again set the field Cust accordingly if you want to allow customers to use these

modifiable fields in special Customizing transactions If Cust is selected, customers can alsomodify the field

Each of these influencing and modifiable fields has an internal number which is unique for eachprogram When it is generated, the number is automatically placed in SCREEN-GROUP1 of theappropriate screens and cannot be changed in Screen Painter This enables the system toestablish a one-to-one relationship between the field name and SCREEN-GROUP1

Finally, you create links between influencing and modifiable fields from the two lists: specifywhich contents of an influencing field influences the modifiable field in which way

To link fields, select the fields from both lists with Choose or double-click If you select an

influencing field, the list of modifiable fields appears and vice versa From this list, select thedesired link A list appears in which you can enter the relevant conditions, for example:

Module pool

Screen group

SAPMTXXX

*

Mod field+ I nfl field+ Delete entry

Influencing val Input Output Active Oblig Intens Invisible

Influencing field

Modifiable field

SPFLI-CARRIDSPFLI-AIRPFROM

AirlineDeparture airport

The entry above results in suppressing the display of field SPFLI-AIRPFROM on those screens,

in whose PBO the corresponding field selection function modules are called and if

SPFLI-CARRID then contains 'LH'

The Field Selection Function

Combination Rules For Attributes

If several influencing fields influence the same modified field, there must be a combination rule todetermine how these influences are linked You use the tables to below establish how a singlefield attribute is set, if it is activated and/or deactivated by different influences The screen

processor controls the combination of several attributes

Input

Field 1

‘_’ 'X'Field 2 ‘_’ ‘_’ ‘_’

'X' ‘_’ 'X'

Output

Field 1

‘_’ 'X'Field 2 ‘_’ ‘_’ ‘_’

'X' ‘_’ 'X'

Active

Field 1

‘_’ 'X'Field 2 ‘_’ ‘_’ ‘_’

'X' ‘_’ 'X'

Mandatory

Field 1

‘_’ 'X'Field 2 ‘_’ ‘_’ 'X'

'X' 'X' 'X'

Highlighted

Field 1

‘_’ 'X'Field 2 ‘_’ ‘_’ 'X'

'X' 'X' 'X'

Invisible

Field 1

‘_’ 'X'Field 2 ‘_’ ‘_’ 'X'

'X' 'X' 'X'

Description of characters:

_ = switched off , X = switched on

If Field 1 makes a screen field invisible (X), Field 2 cannot change this.

Static Attributes in the Screen Painter

In screen modifications, the system takes into account not only the entries you make during fieldselection, but also any entries made in Screen Painter This means that the result of the abovecombination is linked to the screen field attributes according to the same linking rules as

individual attributes

To take advantage of the full dynamic modification range, you should use the following attributes

in the Screen Painter:

Generating the Field Selection

If the list of modified fields has changed at all, you must generate the field selection This

produces consecutive numbers for the modified SCREEN-GROUP1 fields in the screens of therelevant ABAP program

To generate the field selection, choose Generate from Transaction SFAW

Function Modules for Field Selection

To activate field selection for a screen in the PROCESS BEFORE OUTPUT event, you can callone of the function modules FIELD_SELECTION_MODIFY_ALL or

FIELD_SELECTION_MODIFY_SINGLE Both these function modules determine the contents ofthe influencing fields, refer if necessary to the combination rules and execute the screen

modification FIELD_SELECTION_MODIFY_ALL executes the LOOP AT SCREEN statementitself However, with FIELD_SELECTION_MODIFY_SINGLE, you must the LOOP AT SCREEN

The Field Selection Function

yourself and call the function module within the loop You can thus perform your own additionalscreen modifications within the LOOP

Examples of calling the function modules in the event PBO:

1

CALL FUNCTION 'FIELD_SELECTION_MODIFY_ALL'

EXPORTING MODULPOOL = MODULPOOL

CALL FUNCTION 'FIELD_SELECTION_MODIFY_SINGLE'

EXPORTING MODULPOOL = MODULPOOL

as 1, but includes your own LOOP AT SCREEN for special rules

You must decide in each individual case which of the options 2 or 3 produces the best

When you call the function modules, you may not use the system fields REPID or

SY-DYNGR directly as actual parameters Instead, you must assign them to other fields at an

appropriate point For example:

MODULPOOL = SY-REPID

DYNGRP = SY-DYNGR

Sometimes, the Module pool values may differ from the current SY_REPID value

If the Screen group parameter is blank, the system uses the current contents of SY-DYNGR This

is not possible for the Module pool parameter because the value '_' (blank) prevents any fieldmodification

Let us consider an ABAP program in which the second screen contains the followingmodule call in its PBO event:

PROCESS BEFORE OUTPUT

MODULE MODIFY_SCREEN

Suppose the module MODIFY_SCREEN contains the following function call:

MODULE MODIFY_SCREEN OUTPUT.

CALL FUNCTION 'FIELD_SELECTION_MODIFY_ALL'

Let us also suppose that the influences for the screen group BILD and the

corresponding ABAP program are maintained as described above

After calling the transaction, suppose these entries are made:

AirlineFlight number

LH

DisplayChange

400

After choosing Change, the following screen appears:

FromFlight data

LUFTHANSA

FRANKFURT

AirlineFlight number

LH400

Departure airport JFK

Departure time 10:10:00Arrival time 11:34:00

The Field Selection Function

However, if instead of 'LH' as airline carrier 'AA' is entered, the following screenappears:

FromFlight data

AMERICAN AIRLINES

NEW YORK

AirlineFlight number

AA17

Arrival airport SFOFlight time 06:01:00Departure time 13:30:00Arrival time 16:31:00

This restriction helps the transparency of the field selection

Examples of Links

Suppose we have the following fields:

• Influencing fields: F4711, F4712

Field that can be modified: M4711

The following cases can only be implemented using a workaround:

OR Condition and "Ready for Input"

• IfF4711 = 'A' OR F4712 = 'B’, then

M4711 is ready for input

Solution:

• Define H4711 as an influencing field in SFAW;

define the following condition in SFAW:

if H4711 = 'AB'

then M4711 input on (that is, input = 'X')

In the application program, you must program the following before calling the function module:

IF F4711 = 'A' OR F4712 = 'B'

H4711 = 'AB'

ENDIF

AND Condition and "Mandatory"

• IfF4711 = 'A' AND F4712 = 'B',

then M4711 obligatory and only then

Solution:

• Maintenance in the field selection:

If H4711 = 'AB',

then M4711 is a required-entry field

(H4711 = 'AB' only precisely with the above AND condition)

In the application program, you would write the following:

The following cases, on the other hand, can be represented directly:

AND Condition and "Ready for Input"

• If F4711 = 'A' AND F4712 = 'B',

then M4711 is ready for input F4711 <> ‘A’ OR F4712 <> ‘B’,

then M4711 is not ready for input

'B' Input = 'X'

Value 'B1' Input = ' ' Value 'BX' Input = ' '

OR Condition and "Mandatory"

IfF4711 = 'A' OR F4712 = 'B’, then

The Field Selection Function

mandatory = 'X' Influencing field F4712 Value 'B'

mandatory = 'X'

The possibility to define a NOT condition for an influencing field gives further variants of the fieldselection definition

Authorization for Field Selection

The authorization object for Field selection is "central field selection" (S-FIELDSEL) This objectconsists of an activity and a program authorization group The latter is taken from the programauthorizations (ABAP Editor)

Possible activities:

'02' = Change

'03' = Display

'14' = Generate field selection information on screens

'15' = Assign relevant tables to field selection

Changing a field selection modifies the program flow It is also possible in some applications tochange the screen attributes of a field from within Customizing This kind of change does notcount as a modification

Setting the Cursor Position

When a screen is displayed, the system automatically places the cursor in the first field that isready for input However, you can also define on which screen element the cursor should appear

in your program The screen element does not have to be an input field Positioning the cursorcan make applications more user-friendly

You can set the cursor position either statically in the Screen Painter or dynamically in yourABAP program

Static Cursor Position

To define the cursor position statically, enter the name of the required screen element in theCursor position screen attribute [Page 531] in the Screen Painter

Dynamic Cursor Position

To set the cursor position dynamically, use the following statement in an ABAP dialog module inthe PBO event:

SET CURSOR FIELD <f> [OFFSET <off>]

<f> can be a literal or a variable containing the name of a screen element You can use theOFFSET addition to place the cursor at a particular point within an input/output field

Setting the cursor position

REPORT DEMO_DYNPRO_SET_CURSOR

DATA: FIELD1(14), FIELD2(14), FIELD3(14),

NAME(10)

SELECTION-SCREEN BEGIN OF BLOCK BLOC WITH FRAME

PARAMETERS: DEF RADIOBUTTON GROUP RAD,

TXT RADIOBUTTON GROUP RAD,

F1 RADIOBUTTON GROUP RAD,

F2 RADIOBUTTON GROUP RAD,

F3 RADIOBUTTON GROUP RAD

SELECTION-SCREEN END OF BLOCK BLOC

PARAMETERS POS TYPE I

Setting the Cursor Position

MODULE CURSOR OUTPUT

The input/output fields are assigned to the fields FIELD1 to FIELD3 in the ABAPprogram The heading is the text field TEXT, and the pushbutton is the screenelement PUSH

The static cursor position in the screen attributes is set to PUSH

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT

MODULE CURSOR

PROCESS AFTER INPUT

MODULE BACK AT EXIT-COMMAND

During the PBO event, before screen 100 is displayed, the cursor is set according tothe user’s choice on the selection screen If the user chooses the static default, thecursor is placed on the pushbutton, otherwise on the header or one of the inputfields The position POS is only taken into account for the input fields

Switching on Hold Data Dynamically

In the attributes of a screen [Page 531], you can enable the following standard menu entries bysetting the Hold data attribute:

• System → User profile → Hold data

Hold data allows users to retain values that they have entered on a screen so that they

appear the next time they start the same transaction Only values actually entered bythe user are retained They are placed in the corresponding field as default values eachtime the screen is processed, and they overwrite the values transferred from the ABAPprogram in the PBO event

• System → User profile → Set data

This has the same effect as Hold data Additionally, when the held data is placed in thescreen fields, these fields are no longer ready for input

• System → User profile → Delete data

This deletes the held data, and makes the relevant fields on the screen ready for inputagain

If Hold data is not activated in the screen attributes, the above menu entries have no effect

In the PBO event of a screen, you can overwrite the Hold data attribute dynamically using thestatement

SET HOLD DATA ON|OFF

The ON addition activates the attribute, OFF deactivates it

MODULE HOLD_DATA OUTPUT.

SET HOLD DATA ON.

ENDMODULE.

The statically-defined next screen for screen 100 is 0, and it contains a single

input/output field called FIELD

The flow logic is as follows:

PROCESS BEFORE OUTPUT.

MODULE HOLD_DATA.

PROCESS AFTER INPUT.

Switching on Hold Data Dynamically

In the PBO event, the Hold data attribute is activated dynamically If the user enters

a value and then chooses System → User profile → Hold data or Set data, the samevalue is displayed in the field when the screen is next displayed This value is

displayed each time the screen is called until the user chooses Delete data Thisoverwrites any value assigned to the field FIELD in the ABAP program

Complex Screen Elements

Kontextmenüs [Page 645]

Custom Controls [Page 668]

Status Icons [Page 642]

Subscreens [Page 653]

Tabstrip Contols [Page 660]

Table Controls [Page 676]

Status Icons

Status Icons

Status icons are display elements that you can use to represent the state of a program

graphically It is possible to use any SAPgui icon However, in practice, you should only use theicons for status display [Extern] listed in the SAP Style Guide

You can only create status icons in the graphical Screen Painter When you create one, youassign a name and a screen field, called a status field, to it The visible length of the screen fielddetermines the amount of space that the icon can take up on the screen As well as the iconitself, you can also place text in the field The actual length (defLg) of the status field must belong enough for the internal representation of the icon, plus any text and quickinfo text that youspecify When you create the status icon in the Screen Painter, a placeholder appears on thescreen You must specify the icon itself and its text and quickinfo text in the PBO event of yourABAP program

In order to define the icon in your ABAP program, you must create a field with the same name asthe status field on the screen and the ABAP Dictionary type ICONS-TEXT You can then fill thisfield with the required technical information in the PBO event When the screen is displayed, theinformation is transferred to the status field and the icon appears

To fill the field in your ABAP program, use the function module ICON_CREATE It has the

following import parameters:

The name of the required icon These are listed in the SAP Style Guide [Extern], in theinclude program <ICON>, or the corresponding input help in the Screen Painter or MenuPainter

This flag switches the quickinfo display on or off

The function module converts these parameters into a single string, which is returned in theexport parameter RESULT When you assign the RESULT parameter to the status field, it

contains all the information required to display the status icon

Status icons

REPORT DEMO_DYNPRO_STATUS_ICONS.

DATA VALUE TYPE I VALUE 1.

DATA: STATUS_ICON TYPE ICONS-TEXT,

ICON_NAME(20), ICON_TEXT(10).

CALL SCREEN 100.

MODULE SET_ICON OUTPUT.

SET PF-STATUS 'SCREEN_100'.

Status Icons

Continue

The screen contains a status field called STATUS_ICON with a visible length of 12and defined length 26 The status icon and the space for the text are represented byplaceholders in the Screen Painter

The screen flow logic is as follows:

PROCESS BEFORE OUTPUT.

MODULE SET_ICON.

PROCESS AFTER INPUT.

MODULE CANCEL AT EXIT-COMMAND.

MODULE CHANGE.

The dialog module SET_ICON passes various values to the function module

ICON_CREATE, depending on the values of the fields in the program The statusfield STATUS_ICON is filled with the contents of the export parameter RESULT ofthe function module The corresponding icon with its text and quickinfo is thendisplayed on the screen When the user chooses Continue, the contents of the fieldVALUE are changed in the PAI, and consequently a new icon is defined in the PBOevent The following icons and texts are displayed:

right-function code that is available using the keyboard, since normally only the most important areassigned to the application toolbar.

However, as well as the standard context menu, you can define context-specific menus for any ofthe following screen elements:

Global Class CL_CTMENU

Context menus are objects of the global ABAP Objects [Page 1344] class CL_CTMENU In theclass library, the class belongs to the Frontend Services component, in which the classes of theControl Framework are also stored (see Custom Controls [Page 668]) It contains methods thatallow you to define context menus dynamically in a program As a template, you can create yourown context menus statically in the Menu Painter

The most important methods of the class CL_CTMENU are:

LOAD_GUI_STATUS Assigns a context menu that has already been defined statically

in the Menu Painter to a local context menu in a programADD_FUNCTION Assigns a single function to a context menu in a program

ADD_MENU Assigns another local context menu to the current local context

menu in the programADD_SUBMENU Assigns another local context menu to the current local context

menu in the program as a cascading menu

HIDE_FUNCTIONS Hides functions

Context Menus

DISABLE_FUNCTIONS Deactivates functions

ENABLE_FUNCTIONS Activates functions

SET_DEFAULT_FUNCTION Sets a default function, which is highlighted when the menu is

When you define a context menu on a screen (or list [Page 903]), the relevant objects of classCL_CTMENU are created automatically by the runtime environment, not explicitly in the program.References to the object are passed as the parameters of special callback routines in the ABAPprogram

Context Menus for Elements on Screens

In order to link a context menu with one of the screen elements above, you only need to enter an

ID <context> in the Context menu field in the element attributes in the Screen Painter If you donot define a context menu for a particular screen element, it inherits the context menu from thehierarchically next-highest element For example, all screen elements in a group box that do nothave their own context menu would inherit the context menu of the group box The highesthierarchy level is the default context menu, containing all of the key settings of the current dialogstatus

If a screen element is linked with a context menu – either its own or one that it has inherited, aspecial subroutine

ON_CTMENU_<context>

is called in the ABAP program when the user clicks the right-hand mouse button The PAI event

is not triggered You use this subroutine (callback routine) to define the context menu

dynamically You must program it in the processing logic If the subroutine does not exist, thecontext menu is not displayed

You can link the same context menu <context> to any number of screen elements They then allwork with the same subroutine

Defining Context Menus in the Processing Logic

For each context menu that you want to call for an element on a screen, you need to program acorresponding callback routine:

FORM ON_CTMENU_<context> USING <l_menu> TYPE REF TO cl_ctmenu

ENDFORM

Each routine must have a single USING parameter, typed as a reference variable to class

CL_CTMENU For each context menu assigned to an element on a screen, the runtime

environment automatically creates an object of the class When the user requests the contextmenu by clicking the right-hand mouse button, the system calls the corresponding subroutine andpasses a reference to the corresponding object to the formal parameter

When the object is passed it is initial – the context menu contains no entries In the subroutine,you can work with the methods of the object (as listed above) to construct the context menudynamically.

Using Predefined Context Menus

As well as dialog statuses and dialog box statuses, there is a third kind of GUI status [Page 553]that you can define in the Menu Painter, namely a context menu To find out how to createcontext menus in the Menu Painter, refer to Creating Context Menus [Extern]

Predefined context menus allow you to make groups of statically-defined function coded

available context-specifically The method LOAD_GUI_STATUS allows you to load a contextmenu from any ABAP program into a local context menu in a program As a rule, you usepredefined context menus to reuse the function codes from a dialog status with the same

semantics, but context-specifically Once you have loaded a predefined context menu into alocal context menu in a program, you can modify it in any way (append other predefined contextmenus, add or remove functions, add other context menus)

Defining New Context Menus

You can create new context-specific menus either by modifying existing ones or by constructingnew menus

You can add any number of new functions to a context menu When you add a new function,you must specify the function text, function code, and function type (for example, E for an

unconditional module call [Page 574])

However, you can also add any other local context menu from the program In this case, youonly have to pass a reference to another context menu (see example below) You can create acollection of context menu objects in your program and use and combine them as necessary.You can also construct submenus You can have deep-nested menus by adding submenus toexisting submenus

Ergonomic Guidelines

When you create context menus, you should observe the following rules:

• The functions in a context menu should be a subset of the functions in the program You canensure this by using predefined context menus

• Context menus should not contain more than ten entries at a single level

• If you use a context menu for a screen element, it should contain all of the functions possiblefor that element, but at least the standard comments such as Select, Copy, Cut, and Paste

• The sequence of the functions should be as follows: Object-specific commands, copy

commands, other commands

• You should not duplicate functions that can be selected using the left-hand mouse button in acontext menu

Displaying the Context Menu

Once you have defined the context menu dynamically in the callback routine, the system displays

it on the screen immediately When the user chooses a function from the menu, the systemtriggers the PAI event and places the corresponding function code in SY-UCOMM and the OKCODE field

DATA: field1 TYPE i VALUE 10,

field2 TYPE p DECIMALS 4.

DATA: prog TYPE sy-repid,

flag(1) TYPE c VALUE 'X'.

DATA: ok_code TYPE sy-ucomm,

save_ok TYPE sy-ucomm.

prog = sy-repid.

CALL SCREEN 100.

MODULE status_0100 OUTPUT.

SET TITLEBAR 'TIT100'.

FORM on_ctmenu_input USING l_menu TYPE REF TO cl_ctmenu.

DATA calculate_menu TYPE REF TO cl_ctmenu.

CREATE OBJECT calculate_menu.

CALL METHOD: calculate_menu->add_function

EXPORTING fcode = 'SQUARE'

text = text-001,

Context Menus

calculate_menu->add_function

EXPORTING fcode = 'CUBE'

text = text-002, calculate_menu->add_function

EXPORTING fcode = 'SQUAREROOT'

text = text-003, calculate_menu->add_function

EXPORTING fcode = 'CUBICROOT'

text = text-004, l_menu->add_submenu

EXPORTING menu = calculate_menu

text = text-005.

ENDFORM.

The next screen (statically defined) for screen 100 is itself It has the following layout:

Try the right-hand mouse button (Shift+F10) in various positions

Show eventEvent Input

The relevant extract of the element list is as follows:

Elements TEXT2 and FIELD2 have no context menus of their own They inherit thecontext menu FRAME from the group box They are assigned to modification groupMOD.

The flow logic is as follows:

PROCESS BEFORE OUTPUT.

MODULE status_0100.

PROCESS AFTER INPUT.

MODULE cancel AT EXIT-COMMAND.

MODULE user_command_0100.

The following function codes and GUI status are assigned to this ABAP program:

The table shows the function codes that each GUI status contains

The dialog status SCREEN_!00 is set statically in the PBO Function codes HIDEand REVEAL are displayed or hidden, depending on the contents of the FLAG field.The context menus for the screen elements are constructed in the callback routines

Constructed from the static context menus CONTEXT_MENU_2 and

CONTEXT_MENU_1 This has two lines – Hide result and Cancel The entry forfunction code HIDE is highlighted

REVEAL:

Constructed from the static context menus CONTEXT_MENU_3 and

CONTEXT_MENU_1 This has two lines – Show result and Cancel The entry forfunction code REVEAL is highlighted

INPUT:

Constructed by including the four-line local context menu CALCULATE_MENU as asubmenu To do this, the program declares a local reference variable with reference

to class CL_CTMENU, then creates the object and adds the function codes

SQUARE, CUBE, SQUAREROOT, and CUBICROOT When we include it in thecontext menu for INPUT, we must specify a text for the menu entry behind which itstands

When a user runs the program and right-clicks the first line, the context menu TEXT

is displayed When he or she right-clicks the second line, context menu INPUT is

Context Menus

displayed, and for the third line, FRAME is displayed The fourth line is hidden bythe program For all other areas of the screen, the system displays the standardcontext menu, with all of the static function codes plus F1 and F4

When the user chooses one of the new dynamic functions, the system calculatesusing the number in input field FIELD1 and places the result in FIELD2

When the user chooses Hide result (HIDE), the program modifies the screen

dynamically The fourth line becomes visible, and the user can now display thecontext menu REVEAL

Selektionsbilder als Subscreens [Page 778]

Subscreens allow you to embed one screen within another at runtime The term subscreenapplies both to the screen that you embed, and the area on the main screen in which you place

it This section is about subscreen areas The actual screens that you embed are called

subscreen screens When you use a subscreen, the flow logic of the embedded screen is alsoembedded in the flow logic of the main screen Using subscreens on screens is like using

includes in ABAP programs

Subscreens allow you to expand the content of a screen dynamically at runtime For example,screen exits, which are part of the enhancement concept, use the subscreen technique Somecomplex screen elements, like tabstrip controls [Page 660], also use them

To use a subscreen, you must:

1 Define the subscreen area(s) on a screen

2 Define suitable subscreen screens

3 Include the subscreen screen in the subscreen area

Main screen

Subscreen area

bild

Subscreen screens

bild

bildPBOBildschirm- PAI

Bildschirm-bild

Dynamic inclusion

Defining Subscreen Areas

You define subscreen areas using the Screen Painter in the layout of the screen on which youwant to embed a subscreen Each subscreen area on a screen has a unique name, and aposition, length, and height Subscreen areas may not overlap either with each other or withother screen elements You can also specify whether a subscreen area can be resized vertically

or horizontally when the user resizes the window If the area supports resizing, you can specify a

minimum size for it If the resizing attributes are selected, the PAI event is triggered whenever theuser resizes the main screen

Defining Subscreen Screens

You can create subscreen screens either in the same program or a different program To create

a subscreen screen, enter the screen type Subscreen in the screen attributes The defined next screen must be the number of the subscreen itself Choose a size for the screen,making sure that it fits within the subscreen area into which you want to place it If the subscreenscreen is too big for the subscreen area, only the top left-hand corner of it will be displayed.You create the layout, element list, and flow logic of a subscreen screen in the same way as anormal screen Subscreens may also include other subscreens However, the following

• Subscreens cannot have their own OK_CODE field Function codes linked to useractions on subscreens are placed in the OK_CODE field of the main screen This alsoapplies to subscreen screens defined in a different program to the main screen

• The flow logic of a subscreen screen may not contain a MODULE AT

EXIT-COMMAND statement Type E functions may only be handled in the main screen

• The flow logic of a subscreen screen may not contain any dialog modules containing thestatements SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN, orLEAVE TO SCREEN Any of these statements causes a runtime error You cannotchange the GUI status of a main screen in a subscreen screen

Including Subscreen Screens

You include a subscreen screen using the CALL SUBSCREEN statement in the flow logic of themain screen

To include a subscreen screen in the subscreen area of the main screen and call its PBO flowlogic, use the following statement in the PBO event of the main screen:

PROCESS BEFORE OUTPUT

CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>

This statement assigns the subscreen screen with number <dynp> to the subscreen area called

<area> You can also specify the program in which the subscreen screen is defined (optional) Ifyou do not specify the program explicitly, the system looks for the subscreen screen in the sameABAP program as the main program If it does not find a corresponding subscreen screen, aruntime error occurs The PBO flow logic of the subscreen screen is also included at the samepoint This can call PBO modules of the ABAP program in which the subscreen screen is defined

At the end of the subscreen PBO, the global fields from the program are passed to any