Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

what is the function module used for search help

Former Member
0 Kudos

hi

experts can u help me for this

6 REPLIES 6

Former Member
0 Kudos

hi,

this may help u

F4_SEARCH_HELP

reward if its useful

-vijay

Former Member
0 Kudos

F4IF_INT_TABLE_VALUE_REQUEST:Display internal table as search help

F4UT_PARAMETER_VALUE_GET

F4UT_PARAMETER_RESULTS_PUT

F4IF_SHLP_EXIT_EXAMPLE.

regards,

srinivas

uwe_schieferstein
Active Contributor
0 Kudos

Hello Ramesh

If you want to have full control over an existing F4 search help and adjust it dynamically to your specific requirements then you can use the following two function modules:

- F4IF_GET_SHLP_DESCR

=> retrieves the meta data of the search help, can be modified

Take the (modified) search help description and feed

- F4IF_START_VALUE_REQUEST

Regards

Uwe

Former Member
0 Kudos

use the FM

F4IF_START_VALUE_REQUEST

Former Member
0 Kudos

Hi

CALL FUNCTION 'F4IF_INT_TABLE_VALUE_REQUEST'

this is the FM

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

Parameters

DDIC_STRUCTURE

RETFIELD

PVALKEY

DYNPPROG

DYNPNR

DYNPROFIELD

STEPL

WINDOW_TITLE

VALUE

VALUE_ORG

MULTIPLE_CHOICE

DISPLAY

CALLBACK_PROGRAM

CALLBACK_FORM

MARK_TAB

USER_RESET

VALUE_TAB

FIELD_TAB

RETURN_TAB

DYNPFLD_MAPPING

Exceptions

PARAMETER_ERROR

NO_VALUES_FOUND

Function Group

SDHI

<b>

reward if usefull</b>

former_member386202
Active Contributor
0 Kudos

Hi,

F4IF_INT_TABLE_VALUE_REQUEST

F4IF_FIELD_VALUE_REQUEST

F4UT_PARAMETER_VALUE_GET

F4UT_PARAMETER_RESULTS_PUT

F4IF_SHLP_EXIT_EXAMPLE.

Regards,

prashant