Setting Attributes Dynamically

Transcription

1 Setting Attributes Dynamically PDF download from SAP Help Portal: Created on February 22, 2015 The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal. This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included. Note 2015 SAP SE or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Please see for additional trademark information and notices. Page 1 of 5

2 Table of content 1 Setting Attributes Dynamically Page 2 of 5

3 1 Setting Attributes Dynamically Each field on a screen has a set of attributes that are fixed when you define the screen in the Screen Painter. When an ABAP program is running, a subset of the attributes of each screen field 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 in your program. You cannot display it in the Debugger, and cannot use any work area other than its header line to address it. It has the following structure: Component Length Type Meaning Attribute NAME 132 C Name of the screen field Name GROUP1 3 C Modification group 1 Group 1 GROUP2 3 C Modification group 2 Group2 GROUP3 3 C Modification group 3 Group3 GROUP4 3 C Modification group 4 Group4 REQUIRED 1 C Field input is mandatory Mandatory field INPUT 1 C Field is ready for input Input OUTPUT 1 C Field is for display only Output INTENSIFIED 1 C Field is highlighted Highlighted INVISIBLE 1 C Field is suppressed Invisible LENGTH 1 X Field length VisLg ACTIVE 1 C Field is active Input/Output/Invisible DISPLAY_3D 1 C Three-dimensional box Two-dimensional VALUE_HELP 1 C Input help button display Input help REQUEST 1 C Input exists - 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 contents override the static attributes of the screen fields for a single screen call. The only statements that you can use with SCREEN are: LOOP AT SCREEN.... MODIFY SCREEN.... ENDLOOP. 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 to GROUP4 can contain any three-character code. These codes allow you to include screen fields in up to four modification groups. The screen field can belong to different modification groups. Modification groups are like an extra key field for the table SCREEN 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 can overwrite them dynamically in a program. The remaining components are for reading and activating or deactivating the display attributes of screen 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, and INVISIBLE. They also have different effects depending on their respective static settings. The ACTIVE component has no equivalent in the element attributes. Instead, it changes the components 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 other changes to the settings of INPUT; OUTPUT, and INVISIBLE for the same table line are ignored. Conversely, setting INPUT = 0, OUTPUT = 0, and INVISIBLE = 1 sets ACTIVE to 0, and any further assignment to ACTIVE for the same table line will also be ignored. The setting ACTIVE = 1 has no other effect on the attributes. The only purpose of the ACTIVE component is to allow you 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 when SCREEN-ACTIVE = 0 for the field in question. If you want to prevent a module from being processed 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 have the following effect on screen fields: ACTIVE INPUT OUTPUT INVISIBLE Effect Screen field is displayed, statically. Field contents are is not set statically. However, not ready for input if the Screen field is displayed, Page 3 of 5

4 Field contents are not is not set statically Screen field is displayed, statically. Field contents are Not ready for input, even if Input is set statically Screen field is displayed, Field contents are not Not ready for input, even if Input is set statically Screen field is displayed, Field contents are not is not set statically. User input is masked by asterisks (*) Screen field is displayed, Output is masked by asterisks (*). is not set statically. User input is masked by asterisks (*) Screen field inactive. Screen field is not displayed, regardless of the static attributes Screen field inactive. Screen field is not displayed, regardless of the static attributes. If a field is statically-defined as Output only, setting INPUT = 1 has no effect. INPUT is always 0 for 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 automatically made 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 only leave the screen when all mandatory fields contain an entry. Exception: Function codes with type 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 screen fields with the Output only attribute. VALUE_HELP Setting VALUE_HELP to 0 or 1 switches the input help button off and on respectively. INTENSIFIED If you set INTENSIFIED = 1, the field contents of input fields are changed from black to red. The contents of output fields are changed from black to blue. LENGTH 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 output length. 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 if the user had changed the field contents. This means that a conditional module call using ON REQUEST or ON CHAIN-REQUEST would be executed regardless of whether the user really changed the field. REQUEST is automatically reset to 0. Example This example shows a simple screen modification. Program DEMO_DYNPRO_MODIFY_SCREEN demonstrates all possible modifications. Page 4 of 5

5 Dynamic screen modifications. REPORT demo_dynpro_modify_simple. DATA: ok_code TYPE sy-ucomm, save_ok TYPE sy-ucomm. DATA flag(1) TYPE c. CALL SCREEN 100. MODULE status_0100 OUTPUT. SET PF-STATUS 'SCREEN_100'. LOOP AT SCREEN. IF screen-group1 = 'MOD'. IF flag = ' '. screen-input = '0'. ELSEIF flag = 'X'. screen-input = '1'. MODIFY SCREEN. ENDLOOP. MODULE cancel. LEAVE PROGRAM. MODULE user_command_0100 INPUT. save_ok = ok_code. CLEAR ok_code. CASE save_ok. WHEN 'TOGGLE'. IF flag = ' '. flag = 'X'. ELSEIF flag = 'X'. flag = ' '. ENDCASE. The next screen (statically defined) for screen 100 is itself, and it has the following layout: The input and output fields are copied from structure DEMO_CONN in the ABAP Dictionary. The lowermost four input and output fields are assigned to modification group MOD. The screen flow logic is as follows: PROCESS BEFORE OUTPUT. MODULE status_0100. PROCESS AFTER INPUT. MODULE cancel AT EXIT-COMMAND. MODULE user_command_0100. In GUI status SCREEN_100, function code TOGGLE is linked with a pushbutton. When the program is called, the lowermost four input/output fields are not displayed as ready for input since the FLAG variable initially contains a space. The user can toggle the ready for input status. Page 5 of 5