Skip to Content

How to work with search helps in WDA – 1: OVS

Search helps and value lists in WDA and how to program them is a recurring theme in the WDA forum. I have tried to put together some tips and how-to’s related to the subject in this blog series. Note that this is not an exhaustive tutorial – if anyone has complementary info, they’re very welcome to comment (or take the blogs further!) In order to warm up, I will start by describing how to create a simple OVS search help and tailor it to your needs. In my opinion, an OVS is the easiest way to hack a search help into fitting specific criteria, some of which can be determined at run-time. In the next blog, I will discuss how to generate dynamic value sets for dropdown lists, both in stand-alone fields and inside a table. h4. A brief overview of search helps  Basically, there are 4 types of search helps: Automatic, where you use the built-in search help for the DD element; Dictionary search help, where you can specify a specific DD search help (for instance, your own); OVS, where you use component WDR_OVS and tailor it to suit your needs; and finally Freely programmed search helps. In this starter blog, I’ll concentrate on the first 3, with specific focus on OVS. The Automatic and Dictionary search helps are fairly simple to use. If your context field is typed on a DD element which has a search help or where the domain has a value help (check table), the F4 key will bring up the related search help. This means you do not have to explicitly do anything in order to get the job done: Sample F4 DD-based search help on Airline codes (field SFLIGHT-CARRID): image The third search help type, and the focus of this blog, is the OVS – Object Value Selector. You use it via the WDR_OVS component. This pre-generates most of the code for you, and all you have to worry about is programming the select logic for the value list (similar to creating a search help user exit). h4. The OVS search help example  Start by defining the WDR_OVS component in your WDA property screen: OVS – Object Value Selector – is used via the WDR_OVS component. This search help is used whenever you want to use the OVS framework – it will provide you with a general method for retrieving the values to display, and you can modify the value list (a bit like creating a search help user exit). Start by including the WDR_OVS component in your WDA property screen: image Then, in the view, create a reference to the same component (related to the Interfacecontroller): image In the view’s context, specify OVS as the search help type and use the name of your OVS component: image Finally, the last part of the configuration work: create an event handler in the view’s methods list by selecting the OVS from the (grey) Event column. Give your method a name as well: image Now for the fun part. Double-clicking on the OVS_AIRPLANE method reveals that a wizard has already been at work. Most of the code has in fact been pre-generated for you – all you have to do is fill in the parts needed to tailor your OVS search help to your specific needs. We want to find all airplane types that have a minimum number of seats as defined by the user in the search help. Here’s the code, after I made my own modifications to the pre-generated OVS template:    method ovs_airplane.  * Structure for search help input   types:     begin of lty_stru_input, *   add fields for the display of your search input here      minimum_seats type s_seatsmax,     end of lty_stru_input.  * Structure for result list from search help   types:     begin of lty_stru_list, *   add fields for the selection list here       planetype type s_planetye,     end of lty_stru_list.    data: ls_search_input  type lty_stru_input,         lt_select_list   type standard table of lty_stru_list,         ls_text          type wdr_name_value,         lt_label_texts   type wdr_name_value_list,         lt_column_texts  type wdr_name_value_list,         lv_window_title  type string,         lv_group_header  type string,         lv_table_header  type string.    field-symbols: co_phase_0.  “configuration phase, may be omitted  * Set texts for Search help box       ls_text-name = `MINIMUM_SEATS`.  “must match a field name of search       ls_text-value = `Minimum number of seats`. “wd_assist->get_text( `001` ).       insert ls_text into table lt_label_texts.        lv_window_title = ‘Airplanes with more seats than…’. *      lv_group_header = wd_assist->get_text( `004` ). *      lv_table_header = wd_assist->get_text( `005` ).        ovs_callback_object->set_configuration(                 label_texts  = lt_label_texts                 column_texts = lt_column_texts                 group_header = lv_group_header                 window_title = lv_window_title                 table_header = lv_table_header                 col_count    = 2                 row_count    = 20 ).       when if_wd_ovs=>co_phase_1.  “set search structure and defaults        ovs_callback_object->context_element->get_static_attributes(           importing static_attributes = ls_search_input ).        ovs_callback_object->set_input_structure(           input = ls_search_input ).       when if_wd_ovs=>co_phase_2.  “Select value list based on user input        if ovs_callback_object->query_parameters is not bound. ******** TODO exception handling       endif.        assign ovs_callback_object->query_parameters->*                               to  is assigned. ******** TODO exception handling       endif.  * Here is where we select plane types based on our seats requirement!       select planetype from saplane           into corresponding fields of table lt_select_list         where seatsmax > selection is not bound. ******** TODO exception handling       endif.        assign ovs_callback_object->selection->* to *Lty_stru_input* is the input structure of our search help. Here, we define which search fields should be present. In our example, this is the minimum number of seats, but adding more fields here enables you to refine the search help. In our example, we will allow the user to specify the minimum number of seats for the airplane type they search for.    *Lty_stru_list* is the structure of the resulting list of values. Normally you would define at least 2 fields here; namely the search value and it’s accompanying text. There’s nothing wrong with displaying more than two columns, if you want the list of values to contain more detailed info.   Resulting search help: search help input Search result: search result
1 Comment
You must be Logged on to comment or reply to a post.