This is in continuation with SAP ABAP SYNTAX FOR FORM PART ONE
Addition 2
... USING p1 ... pn
Effect
Defines the formal parameters p1 ,... pn which are replaced by actual parameters when you call the subroutine.
The formal parameters p1 ,... pn can have a particular type (see Type assignment ). You can also specify the transfer type (i.e. how you want to pass them).
Note
Transfer types: USING ... p ...
Transfer is by reference. This means you can change the transferred field continually in the subroutine.
USING ... VALUE(p) ...
When you specify VALUE(...) , transfer is by value, i.e. the field contents are passed to the relevant local field. VALUES parameters thus behave in the same way as local fields.
Addition 3
... CHANGING p1 ... pn
Effect
The parameters after CHANGING can accept the same specifications as those after USING .To link the VALUE specification with the change of a parameter value, you can use the addition CHANGING ... .
Then, all the formal parameters specified by VALUE(...) are transported back to the actual parameters at the end of the subroutine (i.e. after ENDFORM ). If the subroutine is terminated by a dialog message, none of the parameters referenced by CHANGING VALUE ... changes.
Otherwise, the effect of USING and CHANGING is identical.
Example
DATA: NUMBER_1 TYPE I VALUE 1,
NUMBER_2 TYPE I VALUE 2,
TEXT_1(10) VALUE 'one',
TEXT_2(10) VALUE 'two'.
PERFORM CONFUSE USING NUMBER_1
NUMBER_2
TEXT_1
NUMBER_1
TEXT_2.
FORM CONFUSE USING PAR_NUMBER_1 TYPE I
PAR_NUMBER_2 TYPE I
PAR_TEXT_1 TYPE C
VALUE(PAR_V_NUMBER_1) TYPE I
VALUE(PAR_V_TEXT_2) TYPE C.
ADD 3 TO PAR_V_NUMBER_1.
ADD 4 TO PAR_NUMBER_1.
ADD NUMBER_1 TO PAR_NUMBER_2.
TEXT_2 = 'three'.
PAR_TEXT_1 = PAR_V_TEXT_2.
PAR_V_TEXT_2 = 'four'.
ENDFORM.
Field contents after the PERFORM call:
NUMBER_1 = 5
NUMBER_2 = 7
TEXT_1 = 'two'
TEXT_2 = 'three'
In subroutines, you are recommended to use the following procedure:
Pass input parameters as USING parameters and output parameters as CHANGING parameters. If in doubt, pass the parameter by VALUE . You should be particularly careful with passed SY fields. For performance reasons, data objects which contain tables should not be passed by VALUE if at all possible.
You can protect TABLES parameters whose heasder lines must remain unchanged with LOCAL . STATICS allows you to create global fields with a local visibility area. In the case of local fields which are initialized on each call, you can replace DATA by STATICS . With frequently called FORM routines, this can lead to a noticeable improvement in performance. To avoid shadowing problems with parameters, you are recommended to keep to the naming convnetion for fields in subroutines. You should, for instance, always start FORM parameters with the prefix 'P_' and
local fields with the prefix 'L_' .
MySAP CRM System architecture and design
MySAP CRM architecture and E procurement introduction
MySAP CRM E procurement
MySAP CRM business intelligence at work
CRM data administration in mysap and business intelligence
Addition 2
... USING p1 ... pn
Effect
Defines the formal parameters p1 ,... pn which are replaced by actual parameters when you call the subroutine.
The formal parameters p1 ,... pn can have a particular type (see Type assignment ). You can also specify the transfer type (i.e. how you want to pass them).
Note
Transfer types: USING ... p ...
Transfer is by reference. This means you can change the transferred field continually in the subroutine.
USING ... VALUE(p) ...
When you specify VALUE(...) , transfer is by value, i.e. the field contents are passed to the relevant local field. VALUES parameters thus behave in the same way as local fields.
Addition 3
... CHANGING p1 ... pn
Effect
The parameters after CHANGING can accept the same specifications as those after USING .To link the VALUE specification with the change of a parameter value, you can use the addition CHANGING ... .
Then, all the formal parameters specified by VALUE(...) are transported back to the actual parameters at the end of the subroutine (i.e. after ENDFORM ). If the subroutine is terminated by a dialog message, none of the parameters referenced by CHANGING VALUE ... changes.
Otherwise, the effect of USING and CHANGING is identical.
Example
DATA: NUMBER_1 TYPE I VALUE 1,
NUMBER_2 TYPE I VALUE 2,
TEXT_1(10) VALUE 'one',
TEXT_2(10) VALUE 'two'.
PERFORM CONFUSE USING NUMBER_1
NUMBER_2
TEXT_1
NUMBER_1
TEXT_2.
FORM CONFUSE USING PAR_NUMBER_1 TYPE I
PAR_NUMBER_2 TYPE I
PAR_TEXT_1 TYPE C
VALUE(PAR_V_NUMBER_1) TYPE I
VALUE(PAR_V_TEXT_2) TYPE C.
ADD 3 TO PAR_V_NUMBER_1.
ADD 4 TO PAR_NUMBER_1.
ADD NUMBER_1 TO PAR_NUMBER_2.
TEXT_2 = 'three'.
PAR_TEXT_1 = PAR_V_TEXT_2.
PAR_V_TEXT_2 = 'four'.
ENDFORM.
Field contents after the PERFORM call:
NUMBER_1 = 5
NUMBER_2 = 7
TEXT_1 = 'two'
TEXT_2 = 'three'
In subroutines, you are recommended to use the following procedure:
Pass input parameters as USING parameters and output parameters as CHANGING parameters. If in doubt, pass the parameter by VALUE . You should be particularly careful with passed SY fields. For performance reasons, data objects which contain tables should not be passed by VALUE if at all possible.
You can protect TABLES parameters whose heasder lines must remain unchanged with LOCAL . STATICS allows you to create global fields with a local visibility area. In the case of local fields which are initialized on each call, you can replace DATA by STATICS . With frequently called FORM routines, this can lead to a noticeable improvement in performance. To avoid shadowing problems with parameters, you are recommended to keep to the naming convnetion for fields in subroutines. You should, for instance, always start FORM parameters with the prefix 'P_' and
local fields with the prefix 'L_' .
MySAP CRM System architecture and design
MySAP CRM architecture and E procurement introduction
MySAP CRM E procurement
MySAP CRM business intelligence at work
CRM data administration in mysap and business intelligence
No comments :
Post a Comment