Problems using WDR_SELECT_OPTIONS

[Former Member]

Hi Gurus,

I am trying to model the following scenario (just a very simple version of POWL):

- View 1 (V1): some LinksToAction + ViewContainerUIElement in which V2 is going to be embedded. Depending on clicked link, ViewContainer will be displayed accordingly. Basically, this view is something like Active Queries section in POWL.

- View 2 (V2): some filter fields (WDR_SELECT_OPTIONS used as component usage) + standard table to display the selected results.

- Window 1 (W1): default view = V1. This is to be used as general module displaying all different queries.

- Window 2 (W2): default view = V2. To be invoked from some application parts when a concrete search is going to be performed (hence header links in V1 are not needed).

These views are embedded by using dynamic navigation from the main application component (main app layout = left section + content section).

Running the main application, if I click on a link pointing to W1, W1 is properly displayed in the content frame, but as soon as I click on a link pointing to W2, a short dump arises because fields in the component usage WDR_SELECT_OPTIONS seems to be duplicated somehow (ADD_SELECTION_FIELD method). If I click first on W2 and then on W1, exactly the same problem arises.

I have tried to remove all items (MT_SELECTION_FIELDS) from the component usage on initializing, but it does not work...

The only workaround I have found out is to ensure that the component usage is always created from scratch when initializing V2u2026

l_ref_cmp_usage = wd_this->wd_cpuse_select_options( ).
  IF l_ref_cmp_usage->has_active_component( ) IS NOT INITIAL.
    l_ref_cmp_usage->delete_component( ).
  ENDIF.
  l_ref_cmp_usage->create_component( ).

u2026but I am afraid that such piece of code is not so good!

Some ideas on how should I model this situation?

Many thanks in advance and best regards

Vicente

[saravanan_narayanan · Accepted solution]

Hello Vincent,

If re-initialising the component usage is not good option then check whether the following solution suits you

1. Create a member variable (attribute) in component controller (say MV_SELECTION_SCREEN_POPULATED of type boolean)

2. In V2, check whether MV_SELECTION_SCREEN_POPULATED is ABAP_TRUE

3. if its ABAP_FALSE, then populate the selection screen fields and then set the value of MV_SELECTION_SCREEN_POPULATED to ABAP_TRUE

3. if its ABAP_TRUE, then simply the call the method IF_WD_SELECT_OPTIONS->RESET_ALL_SELECTION_FIELDS.

Note: the method REMOVE_ALL_SEL_SCREEN_ITEMS will remove only the fields that are in the main block. If you added your custom block then this method is no good. I dont know whether this method is implemented in this way intentionally.

BR, Saravanan

[Former Member · Accepted solution]

Sara,

First of all, many thanks for your inputs.

Indeed, using RESET_ALL_SELECTION_FIELDS and REMOVE_ALL_SEL_SCREEN_ITEMS methods was my first approach, but it didn't work

Anyway, do you consider that deleting the component usage always in WDDOINIT is not a good practice?

I have always seen this set of sentences to initialize comp. usages:

  lo_cmp_usage =   wd_this->wd_cpuse_ovs_usage_name( ).
  IF lo_cmp_usage->has_active_component( ) IS INITIAL.
    lo_cmp_usage->create_component( ).
  ENDIF.

All in all, I know that create_component cannot be called again if comp. usage was already instantiated, but I am not sure whether deleting it if already created and then creating it again is a good practice...

Thanks again for your comments

BR

Vicente

[saravanan_narayanan · Accepted solution]

Hello Vincente,

I know that REMOVE_ALL_SEL_SCREEN_ITEMS method will not delete the selection fields in the custom blocks. But I expect the RESET_ALL_SELECTION_FIELDS method to work. I remember using this method and it was working.

Coming back to your question whether deleting the component usage is a good practice. Its another solution and nothing wrong in doing so. only overhead here would be the little bit of performance because all the selection screen fields are created again. If the performance impact of recreating the selection fields (incase of huge number of selection fields) is not acceptable then you can goahead with the approach I proposed earlier. (having a flag in component controller and then creating the selection fields only if the flag is not set). For this you need to check again whether RESET_ALL_SELECTION_FIELDS method is really not working.

So my proposal here would be go with the Flag approach and use the RESET_ALL_SELECTION_FIELDS method to clear the selection field values. If this method is not working then go ahead by re-creating the component usage.

BR, Saravanan