FUNCTION MODULE

Former Member · ‎11-13-2007

Hi gurus,

Just want to ask on where can i use the function module 'F4IF_INT_TABLE_VALUE_REQUEST' ?????

Hope there is someone out there who can help me with this.

thanks,

gerald

former_member386202 · ‎11-13-2007

Hi,

It is used for F4 help on selection screen n used in

" At SELECTION-SCREEN on values request"

Regards,

Prashant

hymavathi_oruganti · ‎11-13-2007

if you want your own( not from db) value help for a field in the selection screen ,

and also based on some condition, u can use this.

Former Member · ‎11-13-2007

hi

THIS FUNCTION MODULE CAN BE USED WHEN EVER YOU WANT F4 HELP FOR A SELCTION-SCREN FEILD

F4IF_INT_TABLE_VALUE_REQUEST F4 help also returning the value to be displayed in internal table

Functionality

This module implements the standard help at POV while passing the values to be displayed in a table. The entire dialogue behaves as for a standard F4 help. This module also supports input help control.

Note: Before you use this module at POV (Process on Value-Request), reconsider whether a search help could not carry out the same task. You can implement self-defined value selection in a search help exit. This has the advantage that you can attach the search help to a data element or a field of a structure. The F4 help is then automatically available for all users of the data element or structure.

The values to be displayed are passed in table VALUE_TAB. There are different ways to organize the data in VALUE_TAB. These are mainly defined with the parameter VALUE_ORG.

1. VALUE_ORG = 'S' (Structure)

This option should be used for new developments (despite other default values).

VALUE_TAB is an internal table with a (flat) structure. Every line in VALUE_TAB then corresponds to one line in the list to be displayed.

How the definition of the data struture is passed to the module is described below.

The data in VALUE_TAB is available in internal representation.

2. VALUE_ORG = 'C' (Column)

Each line of VALUE_TAB contains the contents of a single field. The contents of VALUE_TAB are copied to the hit list line by line. The description of the columns is passed in FIELD_TAB. When all fields of FIELD_TAB have been edited, the next line is processed.

In this case the values in VALUE_TAB must be passed in external representation. This means that for types whose external and internal representation differ, the values should be passed to VALUE_TAB with the ABAP command WRITE and not with MOVE (These are for example all the numeric types, date, fields with conversion exit, etc.). Use the extension LEFT-JUSTIFIED for numbers.

Caution: Do not copy any constants directly to VALUE_TAB. For example, if a date is defined as constant "01.01.1998", it can no loner be interpreted for other user-specific settings.

Definition of the data structure of VALUE_TAB.

Depending on how the internal table VALUE_TAB was defined, there are different ways to pass this structure to the module.

In the end, the data structure is always stored internally in table FIELD_TAB. In addition to passing the value directly in the call, there are different ways for the module to fill the table automatically or to enhance the data automatically.

1. The structure of internal table VALUE_TAB is defined in the ABAP Dictionary. For example the table is defined as follows:

DATA: VALUE_TAB LIKE <DDIC structure> OCCURS 0 [WITH HEADER LINE].

In this case it is sufficient to pass the name of the reference structure to parameter DDIC_STRUCTURE. Table FIELD_TAB should not be passed in this case because it is automatically filled with the information from the ABAP Dictionary in the function module.

Table FIELD_TAB only has to be defined instead of parameter DDIC_STRUCTURE if for example some of the fields of the structure should not be displayed or if the order of the columns or header texts should be changed.

If only fields TABNAME and FIELDNAME are filled in FIELD_TAB, the module gets the remaining information from the ABAP Dictionary. As a result you can easily choose individual fields and their order.

If you want to change text, you should fill FIELD_TAB initially using the module DDIF_FIELDINFO_GET. You can then change for example the text in FIELD_TAB.

2. Table VALUE_TAB can for example be defined as follows:

DATA: BEGIN OF VALUE_TAB OCCURS 0,

FIELD1 LIKE <DDIC FIELD>,

FIELD2 TYPE <Data element>,

"etc.

END OF VALUE_TAB.

If all the fields have an explicit reference to a DDIC field (mit LIKE) or to a data element (with TYPE), the module itself can determine the structure of VALUE_TAB. In this case do not pass either DDIC_STRUCTURE or FIELD_TAB.

If you want to pass the field description with FIELD_TAB (for example because you do not want to display all the fields), you normally should not only fill TABNAME and FIELDNAME. The module then gets all the information from the ABAP Dictionary. This also includes the relative position of a field to the beginning of the Dictionary structure. However, this usually will not agree with the relative position of the field in VALUE_TAB.

In this case it is better to fill table FIELD_TAB using module DDIF_FIELDINFO_GET. The relative position of the fields in VALUE_TAB should then be corrected in FIELD_TAB-OFFSET. You can use for example the ABAP command DESCRIBE DISTANCE here.

3. The table has only one field that holds the values column by column. 'C' is passed as VALUE_ORG. The definition of VALUE_TAB could be for example:

DATA: VALUE_TAB(100) TYPE C OCCURS 0 [WITH HEADER LINE].

The definition of the columns should be passed in FIELD_TAB. Again you can limit yourself to TABNAME and FIELDNAME if the remaining information (type, length, headers) should be obtained from the ABAP Dictionary.

The relative position of the fields to the beginning of the structure (FIELD_TAB-OFFSET) are of no importance for this type of data transfer.

Even if you want to pass the entire information in FIELD_TAB yourself, you nevertheless should first fill FIELD_TAB with DDIF_FIELDINFO_GET from the ABAP Dictionary. You can then change individual fields, such as header text, before calling the module.

If you define parameter DDIC_STRUCTURE, FIELD_TAB is internally given the field description of the DDIC structure passed. This is normally meaningless for column-by-column data transfer.

The field names in FIELD_TAB must be unique. If you need fields with the same name from different structures, you should get the information with the function module DDIF_FIELDINFO_GET yourself and then change the field name.

Return the selection in the screen

If the screen information DYNPPROG, DYNPNR, DYNPROFIELD and possibly STEPL are also defined, the selected value is automatically returned in the screen field.

If possible, you should always give this information because the amodal control version of the F4 help can only be supported with this information. A user who switches on the F4 help control does not see a difference between the standard F4 help and a help implemented with this function module in this case.

If the user activates the ActiveX help, it is started amodally under the following conditions:

1. The screen information DYNPPROG, DYNPNR and DYNPROFIELD must be defined.

2. When the function module is called, the RETURN_TAB may not be defined. (In an amodal call, the function module returns before the user has selected a value).

Normally values are only returned in input fields. This behavior can be changed with parameter DISPLAY (see parameter documentation).

With Release 4.6C the module can automatically recognize an input field.

Notes

DYNPPROG and DYNNR cannot be passed as SY-REPID and SY-DYNNR because they are only analyzed after the function module has been called. Instead, first copy the SY fields to local variables and then pass them to the function module.

The value for STEPL is not within a step loop 0. Within a step loop, the current line can be defined at time POV with the function module DYNP_GET_STEPL.

If you do not want to return the selected value automatically, you should not define parameters DYNPPROG, DYNNR etc. A value is not returned automatically if MULTIPLE_SELECTION is selected either, but this could change in the future!

Calls that do not permit a value to be returned automatically can only be implemented modally. The input help control nevertheless can be used for the display, but no other entries can be made in the screen as long as the popup window is displayed. The value is returned in table RETURN_TAB. If the user terminates the F4 help, RETURN_TAB is returned empty (termination does not result in an exception).

Further information

Also read the documentation for the parameters, especially for VALUE and CALLBACK_FORM.

EXAMPLE

TYPES : BEGIN OF ST_OBJID_SH,

OTYPE TYPE HRP1000-OTYPE,

OBJID TYPE HRP1000-OBJID,

END OF ST_OBJID_SH.

DATA : IT_OBJID_SH TYPE STANDARD TABLE OF ST_OBJID_SH.

DATA : WA_OBJID_SH TYPE ST_OBJID_SH.

***********SELECTION SCREEN DESIGN***********************

SELECTION-SCREEN BEGIN OF BLOCK B1 WITH FRAME TITLE TEXT-001.

*SELECT-OPTIONS : S_OTYPE FOR HRP1001-OTYPE NO INTERVALS .

SELECT-OPTIONS : S_OBJID FOR HRP1001-OBJID NO INTERVALS .

SELECT-OPTIONS : DATE FOR SY-DATUM NO-EXTENSION OBLIGATORY.

SELECTION-SCREEN END OF BLOCK B1.

**********END OF SELECTION SCREEN DESIGN*****************

*********VALIDATION FOR SCREEN FIELDS********************

AT SELECTION-SCREEN ON VALUE-REQUEST FOR S_OBJID-LOW.

IF S_OBJID IS NOT INITIAL.

SELECT OTYPE OBJID FROM HRP1000

INTO TABLE IT_OBJID_SH

WHERE OTYPE = 'D'.

IF SY-SUBRC EQ 0.

SEARCH HELP FOR QUALIFICATION.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

DDIC_STRUCTURE = ' '

RETFIELD = 'OBJID'

PVALKEY = ' '

DYNPPROG = SY-REPID

DYNPNR = SY-DYNNR

DYNPROFIELD = 'S_OBJID'

STEPL = 0
WINDOW_TITLE =
VALUE = ' '

VALUE_ORG = 'S'

MULTIPLE_CHOICE = ' '
DISPLAY = ' '
CALLBACK_PROGRAM = ' '
CALLBACK_FORM = ' '
MARK_TAB =
IMPORTING
USER_RESET =

TABLES

VALUE_TAB = IT_OBJID_SH

FIELD_TAB =
RETURN_TAB = RETURN_TAB
DYNPFLD_MAPPING =
EXCEPTIONS
PARAMETER_ERROR = 1
NO_VALUES_FOUND = 2
OTHERS = 3

.

IF SY-SUBRC <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

.

Reward if usefull

former_member188827 · ‎11-13-2007

Short Text

F4 help also returning the value to be displayed in internal table

Functionality

This module implements the standard help at POV while passing the values to be displayed in a table. The entire dialogue behaves as for a standard F4 help. This module also supports input help control.

Note: Before you use this module at POV (Process on Value-Request), reconsider whether a search help could not carry out the same task. You can implement self-defined value selection in a search help exit. This has the advantage that you can attach the search help to a data element or a field of a structure. The F4 help is then automatically available for all users of the data element or structure.

The values to be displayed are passed in table VALUE_TAB. There are different ways to organize the data in VALUE_TAB. These are mainly defined with the parameter VALUE_ORG.

1. VALUE_ORG = 'S' (Structure)

This option should be used for new developments (despite other default values).

VALUE_TAB is an internal table with a (flat) structure. Every line in VALUE_TAB then corresponds to one line in the list to be displayed.

How the definition of the data struture is passed to the module is described below.

The data in VALUE_TAB is available in internal representation.

2. VALUE_ORG = 'C' (Column)

Each line of VALUE_TAB contains the contents of a single field. The contents of VALUE_TAB are copied to the hit list line by line. The description of the columns is passed in FIELD_TAB. When all fields of FIELD_TAB have been edited, the next line is processed.

In this case the values in VALUE_TAB must be passed in external representation. This means that for types whose external and internal representation differ, the values should be passed to VALUE_TAB with the ABAP command WRITE and not with MOVE (These are for example all the numeric types, date, fields with conversion exit, etc.). Use the extension LEFT-JUSTIFIED for numbers.

Caution: Do not copy any constants directly to VALUE_TAB. For example, if a date is defined as constant "01.01.1998", it can no loner be interpreted for other user-specific settings.

Definition of the data structure of VALUE_TAB.

Depending on how the internal table VALUE_TAB was defined, there are different ways to pass this structure to the module.

In the end, the data structure is always stored internally in table FIELD_TAB. In addition to passing the value directly in the call, there are different ways for the module to fill the table automatically or to enhance the data automatically.

1. The structure of internal table VALUE_TAB is defined in the ABAP

Dictionary. For example the table is defined as follows:

DATA: VALUE_TAB LIKE <DDIC structure> OCCURS 0 [WITH HEADER LINE].

In this case it is sufficient to pass the name of the reference structure to parameter DDIC_STRUCTURE. Table FIELD_TAB should not be passed in this case because it is automatically filled with the information from the ABAP Dictionary in the function module.

Table FIELD_TAB only has to be defined instead of parameter DDIC_STRUCTURE if for example some of the fields of the structure should not be displayed or if the order of the columns or header texts should be changed.

If only fields TABNAME and FIELDNAME are filled in FIELD_TAB, the module gets the remaining information from the ABAP Dictionary. As a result you can easily choose individual fields and their order.

If you want to change text, you should fill FIELD_TAB initially using the module DDIF_FIELDINFO_GET. You can then change for example the text in FIELD_TAB.

2. Table VALUE_TAB can for example be defined as follows:

DATA: BEGIN OF VALUE_TAB OCCURS 0,

FIELD1 LIKE <DDIC FIELD>,

FIELD2 TYPE <Data element>,

"etc.

END OF VALUE_TAB.

If all the fields have an explicit reference to a DDIC field (mit LIKE) or to a data element (with TYPE), the module itself can determine the structure of VALUE_TAB. In this case do not pass either DDIC_STRUCTURE or FIELD_TAB.

If you want to pass the field description with FIELD_TAB (for example because you do not want to display all the fields), you normally should not only fill TABNAME and FIELDNAME. The module then gets all the information from the ABAP Dictionary. This also includes the relative position of a field to the beginning of the Dictionary structure. However, this usually will not agree with the relative position of the field in VALUE_TAB.

In this case it is better to fill table FIELD_TAB using module DDIF_FIELDINFO_GET. The relative position of the fields in VALUE_TAB should then be corrected in FIELD_TAB-OFFSET. You can use for example the ABAP command DESCRIBE DISTANCE here.

3. The table has only one field that holds the values column by column. 'C' is passed as VALUE_ORG. The definition of VALUE_TAB could be for example:

DATA: VALUE_TAB(100) TYPE C OCCURS 0 [WITH HEADERLINE].

In this case it is sufficient to pass the name of the reference structure to parameter DDIC_STRUCTURE. Table FIELD_TAB should not be passed in this case because it is automatically filled with the information from the ABAP Dictionary in the function module.

Table FIELD_TAB only has to be defined instead of parameter DDIC_STRUCTURE if for example some of the fields of the structure should not be displayed or if the order of the columns or header texts should be changed.

If only fields TABNAME and FIELDNAME are filled in FIELD_TAB, the module gets the remaining information from the ABAP Dictionary. As a result you can easily choose individual fields and their order.

If you want to change text, you should fill FIELD_TAB initially using the module DDIF_FIELDINFO_GET. You can then change for example the text in FIELD_TAB.

Former Member · ‎11-13-2007

hi,

F4IF_INT_TABLE_VALUE_REQUEST

its a F4 help that returns the values selected in an internal table. it helps to program your own F4 help for a field

Former Member · ‎11-13-2007

Hi,

This FM is used for F4 Help(Search Help) ie.,it displays the possible entries for that field from the internal Table.

chk the demo program

REPORT demo_dynpro_f4_help_module .

TYPES: BEGIN OF values,

carrid TYPE spfli-carrid,

connid TYPE spfli-connid,

END OF values.

DATA: carrier(3) TYPE c,

connection(4) TYPE c.

DATA: progname TYPE sy-repid,

dynnum TYPE sy-dynnr,

dynpro_values TYPE TABLE OF dynpread,

field_value LIKE LINE OF dynpro_values,

values_tab TYPE TABLE OF values.

CALL SCREEN 100.

MODULE init OUTPUT.

progname = sy-repid.

dynnum = sy-dynnr.

CLEAR: field_value, dynpro_values.

field_value-fieldname = 'CARRIER'.

APPEND field_value TO dynpro_values.

ENDMODULE.

MODULE cancel INPUT.

LEAVE PROGRAM.

ENDMODULE.

MODULE value_carrier INPUT.

CALL FUNCTION 'F4IF_FIELD_VALUE_REQUEST'

EXPORTING

tabname = 'DEMOF4HELP'

fieldname = 'CARRIER1'

dynpprog = progname

dynpnr = dynnum

dynprofield = 'CARRIER'.

ENDMODULE.

MODULE value_connection INPUT.

CALL FUNCTION 'DYNP_VALUES_READ'

EXPORTING

dyname = progname

dynumb = dynnum

translate_to_upper = 'X'

TABLES

dynpfields = dynpro_values.

READ TABLE dynpro_values INDEX 1 INTO field_value.

SELECT carrid connid

FROM spfli

INTO CORRESPONDING FIELDS OF TABLE values_tab

WHERE carrid = field_value-fieldvalue.

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

EXPORTING

retfield = 'CONNID'

dynpprog = progname

dynpnr = dynnum

dynprofield = 'CONNECTION'

value_org = 'S'

TABLES

value_tab = values_tab.

ENDMODULE.

Regards,

Omkar.