The Field Selection Function 

This topic describes how a special function Field selection (transaction SFAW and some function modules) 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 at runtime. However, you should only use this option if you often need to assign different field attributes to the same screen for technical reasons. In this case, the same rules apply for all fields, so any field modification is clear.

The following basic rules apply:

·        All fields involved in the field selection process are grouped together in field selection tables 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 selection.

·        Central field selection uses the modification group SCREEN-GROUP1, which therefore cannot be used for anything else.

·        If you use fixed special rules in the field selection which are the same as changing the program, you should make the changes directly in the program, not in the maintenance transaction.

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

·        Entry

·        The output is as follows:

·        Mandatory field

·        Active

·        Highlighted

·        Invisible

You can also determine the conditions and the type of changes involved. During the event PROCESS BEFORE OUTPUT, you call a function module which checks the conditions and, if necessary, changes the attributes.

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 by creating corresponding interface work areas in the ABAP program using TABLES. At runtime, a function module analyzes the field contents of the influencing fields and then sets the attributes of the 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 of maintenance 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:

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

The NOT condition is a pre-selection. If one of the affecting fields satisfies the NOT condition, it is not relevant for the following screen modification. Using the NOT condition may improve performance.

Affecting field: SPFLI-CARRID 

NOT condition: NELH

SPFLI-CARRID is relevant for the field selection only if its contents are not equal to LH at runtime.

At runtime, the system uses the default value for the field modification if it cannot find the current value of the influencing field in the list of maintained values. To achieve this, you need to define 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 the corresponding field for field selection or not. This field selection option is based on the predefined SAP field selection and allows customers to set screen attributes to suit their own requirements within a framework determined by application development. Many application areas have their own 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:

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 also modify the field.

Each of these influencing and modifiable fields has an internal number which is unique for each program. When it is generated, the number is automatically placed in SCREEN-GROUP1 of the appropriate screens and cannot be changed in Screen Painter. This enables the system to establish 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: specify which 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 the desired link. A list appears in which you can enter the relevant conditions, for example:

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

Combination Rules For Attributes

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

Entry
		Field 1
		‘_’	'X'
Field 2	‘_’	‘_’	‘_’
	'X'	‘_’	'X'

 

The output is as follows:
		Field 1
		‘_’	'X'
Field 2	‘_’	‘_’	‘_’
	'X'	‘_’	'X'

 

Active
		Field 1
		‘_’	'X'
Field 2	‘_’	‘_’	‘_’
	'X'	‘_’	'X'

 

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

 

Meaning of the characters:
_ = switched off (off), X = switched on (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 field selection, but also any entries made in Screen Painter. This means that the result of the above combination 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:

Input = 'X'
Output = 'X'
Mandatory = '_'
Invisible = '_'
Highlighted = '_'.

Conversely, you cannot change the values defined on the screen in the following manner:

Input = '_'
Output = '_'
Mandatory = 'X'
Invisible= 'X'
Highlighted = 'X'

If you enter the following combination of influences, it is not really a valid combination, since the combination rules stipulate that the specified display attributes cannot be changed by another influencing field (or the screen).

Input = 'X'
Output = 'X'
Active = 'X'
Mandatory = '_'
Highlighted = '_'
Invisible = '_'

When you reenter the field selection, influences that have no effect, such as the one above, are not displayed. Only exception: If you have defined a default value for the influencing field, it can make sense to display and maintain influences of this kind.

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 the relevant 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 call one of the function modules FIELD_SELECTION_MODIFY_ALL or FIELD_SELECTION_MODIFY_SINGLE. Both these function modules determine the contents of the influencing fields, refer if necessary to the combination rules and execute the screen modification. FIELD_SELECTION_MODIFY_ALL executes the LOOP AT SCREEN statement itself. However, with FIELD_SELECTION_MODIFY_SINGLE, you must the LOOP AT SCREEN yourself and call the function module within the loop. You can thus perform your own additional screen modifications within the LOOP.

Examples of calling the function modules in the event PBO:

...

       1.       

CALL FUNCTION 'FIELD_SELECTION_MODIFY_ALL'
     EXPORTING modulpool    = modulpool
               dynprogruppe = dyngrp.

       2.       

LOOP AT SCREEN.
  IF screen_group1 NE space AND
    screen-group1 NE '000'.
    CALL FUNCTION 'FIELD_SELECTION_MODIFY_SINGLE'
         EXPORTING modulpool    = modulpool
                   dynprogruppe = dyngrp.
* eigene Sonderregeln
    MODIFY SCREEN.
  ENDIF.
ENDLOOP.

       3.       

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

Since the Module pool and Screen groupparameters determine the field selection, you must maintain influences for these.

The Module pool parameter defines, in main memory, which loaded module pool you use to search for the current values of the influencing fields.

When you call the function modules, you may not use the system fields sy-repid and 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 field modification.

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

Suppose the dynpro of the second screen contains the following module call in the 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'
        EXPORTING
             dynprogruppe =  'BILD'
             modulpool    =  'SAPMTXXX'
        EXCEPTIONS
             OTHERS       = 1.

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:

After choosing Change, the following screen appears:

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

When entering 'LH', the field SPFLI-AIRPFROM is invisible. When entering 'AA', it is visible as Dep. airport.

Linking Fields

Every influencing field influences a field which can be modified regardless of other fields. Linking influencing fields can be desirable in some cases but then only possible by defining help fields, which you must set in the application program before calling the function module.

This restriction helps the transparency of the field selection.

Examples of Links

Suppose we have the following fields:

·        Affecting 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 to (that means 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:

IF f4711 = 'A' AND f4712 = 'B'
   h4711 = 'AB'
ELSE.
   h4711 =....
ENDIF.

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.
also if: F4711 <> 'A' OR F4712 <> 'B', then M4711 is not ready for input.

Solution:

M4711 ready for input
Field selection:
Influencing field	F4711	Value 'A'	Input = 'X'
					Value 'A1'	Input = ' '
					Value 'AX'	Input = ' '
Influencing field	F4712	Value 'B'	Input = 'X'
					Value 'B1'	Input = ' '
					Value 'BX'	Input = ' '

OR Condition and "Mandatory"

IfF4711 = 'A' OR F4712 = 'B',then
M4711 is a required-entry field.

Solution:

Mandatory is switched off
Influencing field	F4711	Value 'A'
				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 field selection definition.

Authorization for Field Selection

The authorization object for Field selection is "central field selection" (S-FIELDSEL). This object consists of an activity and a program authorization group. The latter is taken from the program authorizations (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 to change the screen attributes of a field from within Customizing. This kind of change does not count as a modification.