In the CRM webclient you implement or redefine the valuehelp logic. Sometimes a valuehelp is not implemented in the standard, or you might want to implement a more company-specific valuehelp. This can be done by redefining the GET_V of an attribute of a context node.
A GET_V for a DDLB (DropDown List Box) would particularly contain the following code:
DATA: lt_ddlb TYPE bsp_wd_dropdown_table,
lr_ddlb TYPE REF TO cl_crm_uiu_ddlb.
lt_ddlb = cl_crm_uiu_bt_tools=>get_strcmp_ddlb(
iv_structure = [name of the structure the field is part of]
iv_component = [Fieldname])
IF NOT lr_ddlb IS BOUND.
CREATE OBJECT lr_ddlb EXPORTING iv_source_type = ‘T’.
lr_ddlb->set_selection_table( it_selection_table = lt_ddlb ).
rv_valuehelp_descriptor = lr_ddlb.
If you want the dropdown listbox to be occupied with values from a domain, you can use the following code:
DATA:lt_ddlb TYPE bsp_wd_dropdown_table.
SELECT domvalue_l ddtext INTO TABLE lt_ddlb FROM dd07t WHERE
domname = [domain] AND ddlanguage = sy-langu.
INSERT INITIAL LINE INTO lt_ddlb INDEX 1.
SORT lt_ddlb BY value.
IF sy-subrc = 0.
CREATE OBJECT rv_valuehelp_descriptor TYPE cl_bsp_wd_valuehelp_pldescr
iv_source_type = ‘T’
iv_selection_table = lt_ddlb.
The values from the valuehelp are determined when building the screen (do_prepare_output). This means, that if you want the available values to vary based on the contents of another field, you only have to trigger a roundtrip to the server (like raising a server event, which can be implemented in the get_p) when the contents of the field which it depends on are changed.
Furthermore, you will have to implement in the get_v of the field how the available values are filtered.