Search field gets deleted after roundtrip

[former_member185943]

Hello,

I added 2 new custom search fields to a search view. I did not use AET. Instead, I manually created .APPEND to the "search" and "search result" structures and then added them to views by configuration. Thanks to an application-specific customising table, this was enough for the search to work well for both fields.

However, the value from one search field gets deleted after each roundtrip (after search is performed, or some other search field selected...).

The fields have different value-helps.

• The first one works fine. It does not have GET_V method. Reason: there is a good standard search-help which I could reuse. I set the new SERVER_EVENT in redefined GET_DQUERY_DEFINITIONS. This field works fine in all senses.
• However, the one with custom value help gets deleted after each roundtrip (after search is performed or after selecting a value for another search field). The custom value-help is a local class instantiated in GET_V method, returning an itab with name-value pairs in method IF_BSP_WD_VALUEHELP_PLDESCR~GET_SELECTION_TABLE. The SOURCE_TYPE = 'T'.

What am I missing? Please share your ideas.

Update1:

I tried to use GET_P to trigger the same server event as with the first good field, but GET_P does not fire for "ServerEvent" property (only "isInputHelpMandatory", not useful for me).

Update2:

I found that the standard sets value to search context node instance GR_QUERY_CTXT_NODE. I did it too, worked fine, no program errors, but no effect neither.

Update 3:

GET_ and SET_ for the new context attributes do not trigger at all.

Thanks!

KR,

Igor

[former_member202474 · Accepted solution]

Hi Igor,

               I recommend you to add the server event and drop down values in the same method GET_DQUERY_DEFINITIONS even for second field. This method gets called every time for each roundtrip .

Probably this should solve your issue.

Regards,

Ruby.

[former_member185943 · Accepted solution]

Hi, Ruby,

Thanks for the tip! I did it - it gets even worse, because this roundtrip itself deletes the value so it cannot be used in search. I tried to use the event to set value to the context attribute - no effect.

If I comment out my value helper in GET_V, the field value remains as normal (but then I have no value help).

I tried also by filling the DDLB_OPTIONS values in GET_DQUERY_DEFINITIONS manually (w and w/o server event) - effect is the same as with GET_V object (with dropdown values, the field gets deleted, regardless of server event).

Igor

[Former Member · Accepted solution]

Hi Igor,

Please check whether values are passed to query service and they are present after round trip as well(in do prepare output after search completion) in debugging.

I guess you are clearing values some where in code by mistake, Custom fields will hold values as long as the query service instance is not changed.

Bharath R S

[former_member202474 · Accepted solution]

Hi Igor ,

                 Sorry for the delay . Can you pass the drop down list values in DDLB_OPTIONS and in parameter server event value as 'DDLB_CLCK'. I tried , it works for me. Please add the code and test again.

In search related view we generally add the code in the method GET_QUERY_DEFINITIONS instead of GET_V methods.You can cross check in any of the standard search views to have a better clarity.

Hope it helps.

Regards,

Ruby.

[former_member185943 · Accepted solution]

Hi, Ruby,

Yes, I tried this already, but no success - it works exactly the same as with GET_V_.

However, I worked this around by creating a dictionary search help and instantiating CL_BSP_WD_VALUEHELP_F4DESCR in GET_V_.

Now I have a "normal" field with F4 instead of dropdown list and it works OK. Dropdown list would still be better due to low number of hits, but I could not make it work properly.

Thanks for your effort!

Igor

[former_member185943 · Accepted solution]

Hi, Bharath,

The query service gets good values. I am not clearing values anywhere, with "normal" field and dictionary search help it works OK.

However, the customer is happy with my dictionary search-help workaround so I am not researching on this any more.

Thanks for your input anyway!

Igor