Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to add functionality AFTER an event is triggered?

0 Kudos
585

Hello everyone.

I'm trying to create a listener for an event. If you look at the code below my event does some changes on the alv table that I am providing. I wish that whenever the user triggers this event with their actions to reach the part in the commented code. The reason I am doing this on a local level - in the report(not in the event logic) is because I want to call this screen 0100 over and over again, upon every event trigger. What would be the best way to use achieve this? Creating a static variable - is_triggered, for example and checking if it's true every time is the only thing that comes to mind, but is there a better approach?

    IF o_bl->do_work( i_parameters = i_parameters ) = 0.
      SET HANDLER zcl_zrvftprlp_event=>on_data_changed FOR zcl_zrvftprlp_ui=>alv.
      zcl_zrvftprlp_ui=>do_work( CHANGING c_alv_table = zcl_zrvftprlp_bl=>alv_tab ).
      CALL SCREEN 0100.
*     IF event IS TRIGGERED...
*     do some stuff...
*     CALL SCREEN 0100 again.
*     ENDIF.
    ENDIF.
3 REPLIES 3

matt
Active Contributor
0 Kudos
448

zcl_zrvftprlp_ui, zcl_zrvftprlp_event - lovely meaningful class names. You know, I do remember when ABAP programs were limited to just a few characters, but it was a long time ago. Nowadays you've got 30 characters to play with.

Why do you need to call a screen over and over -> seems a bit a weird. Normally, I just set "next screen" on the screen to be itself. In your case 100.

If you really need to signal back to the calling program there are many ways, but I'd need to understand the relationships between your various objects in the developments first. It's really not clear.

0 Kudos
448

Thank you for your comment.

You see, the whole idea of this report is to show the user some data via alv. The thing is, that i am using the old alv - cl_gui_alv_grid. This screen 0100 is actually a container for my alv display, so I call it to display the output of my alv. The user can change one of the fields from the output, that is when my event gets triggered. Changing one field, they change the contents of another field, thus changing the alv display itself. That is why I want to have an indicator when a field is changed, so I can call the screen again and show the new updated alv to the user.

matt
Active Contributor
448

If the data structure is the same, I see no reason to call the screen again. All you have to do is refresh the ALV in the PAI.
So, in the event handler, set a flag in the application class, that's read by method data_is_dirty, say, and then:

METHOD refresh.
    CALL METHOD alv->refresh_table_display
      EXCEPTIONS
        finished = 1
        OTHERS   = 2.
    IF sy-subrc <> 0.
      MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                 WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
    ENDIF.
ENDMETHOD.



MODULE pai_100 INPUT.
  IF my_app->data_is_dirty( ).
      my_app->refresh( ).
  ENDIF.
  IF okcode EQ 'EXIT' OR okcode EQ'BACK'.
      LEAVE TO SCREEN 0.
  ENDIF.
ENDMODULE.             

Generally speaking, avoid statics unless they're needed for all instances of the class. It can make things much easier if you need to enhance the program in anyway in the future.