Remove filter in ALV (cl_gui_alv_grid)

[uta_bchner]

Hi everybody,

I am using cl_gui_alv_grid to display data in a classical module pool dynpro on a tab subscreen.

When I set a filter in the ALV and afterwards leave to screen 0 and move back to the ALV screen, the filter is still set. The ALV will continue showing the same filtered data, even if I start it with completely different content.

I tried to remove the filter by calling cl_gui_alv_grid->set_filter_criteria with an empty filter table, but unfortunately this does not work. Also, initializing the ALV container and grid objects does not help.

Any other ideas?

Thank you,

Uta

[VXLozano]

try to flush something... I noticed that behaviour is common in all grids since I'm working with S4, but I assume it's something GUI related.

I cannot give you an answer, but the flush maybe works.

[Sandra_Rossi]

You say "When I set a filter in the ALV", is it manually? (so that I try to reproduce)

[uta_bchner]

Hi Vicenc,

cl_gui_cfw=>flush( ) is already being called, and so is cl_gui_alv_grid->refresh_table_display.

Unfortunately this does not help.

And I forgot to say that I'm working in a classical R/3 environment.

[uta_bchner]

Hi Sandra,

yes, the filter is being set manually in the UI.

[Sandra_Rossi]

Sorry, I don't reproduce. Probably it's not your exact code (selection screen instead of dynpro), but it's technically similar to what you described. See if you have all the elements below in your program.

CLASS lcl_app DEFINITION.
  PUBLIC SECTION.
    METHODS start_of_selection.
    METHODS at_selection_screen_output.
    METHODS at_selection_screen
      IMPORTING
        ucomm TYPE sscrfields-ucomm.
    METHODS at_selection_screen_on_exit.
  PRIVATE SECTION.
    DATA: carriers TYPE STANDARD TABLE OF scarr,
          alv      TYPE REF TO cl_gui_alv_grid.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
  METHOD start_of_selection.
    CALL SELECTION-SCREEN 1010.
  ENDMETHOD.
  METHOD at_selection_screen_output.
    SELECT * FROM scarr INTO TABLE @carriers.
    CASE sy-dynnr.
      WHEN 1020.
        alv = NEW cl_gui_alv_grid( i_parent = cl_gui_container=>screen0 ).
        alv->set_table_for_first_display(
            EXPORTING i_structure_name = 'SCARR'
            CHANGING  it_outtab = carriers ).
    ENDCASE.
  ENDMETHOD.
  METHOD at_selection_screen.
    CASE sy-dynnr.
      WHEN 1010.
        IF ucomm = 'VIEW_ALV'.
          CALL SELECTION-SCREEN 1020.
        ENDIF.
    ENDCASE.
  ENDMETHOD.
  METHOD at_selection_screen_on_exit.
    alv->free( ).
    FREE alv.
  ENDMETHOD.
ENDCLASS.

TABLES sscrfields.
SELECTION-SCREEN BEGIN OF SCREEN 1010.
SELECTION-SCREEN PUSHBUTTON /1(20) view_alv USER-COMMAND view_alv.
SELECTION-SCREEN END OF SCREEN 1010.
SELECTION-SCREEN BEGIN OF SCREEN 1020.
PARAMETERS dumm1020.
SELECTION-SCREEN END OF SCREEN 1020.

LOAD-OF-PROGRAM.
  DATA(app) = NEW lcl_app( ).
  view_alv = 'View ALV'.
AT SELECTION-SCREEN OUTPUT.
  app->at_selection_screen_output( ).
AT SELECTION-SCREEN.
  app->at_selection_screen( sscrfields-ucomm ).
AT SELECTION-SCREEN ON EXIT-COMMAND.
  app->at_selection_screen_on_exit( ).
START-OF-SELECTION.
  app->start_of_selection( ).

[VXLozano]

Sandra, to know if your system has the same behaviour just do this:

- open SE16 (the old and nice one) for any table, any data selection

- perform some filtering/sorting/whatevering

- go back (the old and nice F3)

- change (or don't) the selection and try again (the old and nice F8)

Your grid settings have been saved somewhere, and your grid keeps your last sorting/filtering/whatevering.

It's weird.

----

Uta, if the flushing thing doesn't work, I guess it will be something SAPGui related. Not sure how to fight the SAPGui, sorry 😞

[Sandra_Rossi]

vicen.lozano Nothing strange to me. There's no SAP GUI bug, it's due to how apps are written. Well I wanted the OP to provide an example so that we can help her, but as you ask, here is the code to reproduce the strange behavior, which is not strange (code needs a dynpro 0100 with custom container CONTAINER_DOC because I can't reproduce with a selection screen). Just uncomment the mentioned line ***** and you solve the APP bug:

CLASS lcl_app DEFINITION.
  PUBLIC SECTION.
    METHODS start_of_selection.
    METHODS at_selection_screen
      IMPORTING
        ucomm TYPE sscrfields-ucomm.
    METHODS screen_0100_pbo.
    METHODS screen_0100_pai.
  PRIVATE SECTION.
    DATA: carriers TYPE STANDARD TABLE OF scarr,
          alv      TYPE REF TO cl_gui_alv_grid,
          custom_container TYPE REF TO cl_gui_custom_container.
ENDCLASS.
CLASS lcl_app IMPLEMENTATION.
  METHOD start_of_selection.
    CALL SELECTION-SCREEN 1010.
  ENDMETHOD.
  METHOD screen_0100_pbo.
    IF alv IS NOT BOUND.
      SELECT * FROM scarr INTO TABLE @carriers.
      custom_container = NEW cl_gui_custom_container( container_name = 'CONTAINER_DOC' ).
      alv = NEW cl_gui_alv_grid( i_parent = custom_container ).
      alv->set_table_for_first_display(
          EXPORTING i_structure_name = 'SCARR'
          CHANGING  it_outtab = carriers ).
    ENDIF.
    SET PF-STATUS space.
  ENDMETHOD.
  METHOD screen_0100_pai.
    IF sy-ucomm = 'BACK'.
******alv->free( ). FREE alv. custom_container->free( ). FREE custom_container.
      SET SCREEN 0.
    ENDIF.
  ENDMETHOD.
  METHOD at_selection_screen.
    CASE sy-dynnr.
      WHEN 1010.
        IF ucomm = 'VIEW_ALV'.
          CALL SCREEN 100.
        ENDIF.
    ENDCASE.
  ENDMETHOD.
ENDCLASS.

TABLES sscrfields.
SELECTION-SCREEN BEGIN OF SCREEN 1010.
SELECTION-SCREEN PUSHBUTTON /1(20) view_alv USER-COMMAND view_alv.
SELECTION-SCREEN END OF SCREEN 1010.

LOAD-OF-PROGRAM.
  DATA(app) = NEW lcl_app( ).
  view_alv = 'View ALV'.
AT SELECTION-SCREEN.
  app->at_selection_screen( sscrfields-ucomm ).
START-OF-SELECTION.
  app->start_of_selection( ).
  ASSERT 1 = 1. " debug helper

MODULE status_0100 OUTPUT.
  app->screen_0100_pbo( ).
ENDMODULE.
MODULE user_command_0100 INPUT.
  app->screen_0100_pai( ).
ENDMODULE.

[VXLozano]

flush, free... what's the difference? XD

As we have no access to the OP's code, we cannot know what does he do. And I'm a bit tired of reading messy code (I have enough mess with mine) so I want not to check it.

BUT in my system, that behaviour (to keep filters and so) is shown in SE16, and because that (I assume that t-code is not been maintained since the end of WWII) I thought it could be a GUI thing.

[uta_bchner]

Hi Sandra,

great, thank you, the free() method solved the issue. Apparently it's enough to call it on the custom container object and simply initialize the grid object.

Thanx a lot for your help!

Uta

[abo]

sandra.rossi

another answer hiding in plain sight under the guise of a comment 😉

[Sandra_Rossi]

c5e08e0478aa4727abc4482f5be390b2 In my preferred help site, Stack Overflow, this doesn't deserve an Answer, just a comment, and the question itself would be edited a lot or even more probably closed 😉

What is of interest is how fast the future visitors can find an answer to their query. I'm afraid someone looking for a FREE problem cannot find this question, and a person looking for a FILTER problem will not be interested by the answer. I prefer to keep it as a comment to not make future visitors lose their time.

[uta_bchner]

andreaborgia sandra.rossi

Should I change the question topic or close the question?
Sorry, I'm not that familiar with how this site works...

[abo]

uta.bchner

personally, I have edited my questions a lot when receiving feedback via comments.

Closing the question should be done once an answer is accepted or you find a solution yourself (don't forget to explain what you did, in this case!)