Skip to Content

Popup screen with autoclose after timer interval has finished

Initial requirement

My requirement was to create two reports with ALV Grid output. These reports should be called via transaction codes, and their data gathering should be done thru function modules, for the identical data will be needed for a Web Tool accessing those data via RFC.


For there is no data selection and no selection screen in these reports (and there shouldn’t be one as required), after starting these transactions the users see nothing for several seconds, until the ALV Grid is displayed. So some users became unsure, if they’ve correctly started the transactions.

Looking for a solution

I was looking for some ideas, and I found here on SCN some threads pointing to class CL_GUI_TIMER. So I decided to create a function module calling a screen and closing it, after the timer interval has finished.

Creating the function module

First I thought about the data to be passed to the function module:

  • a heading text for the popup screen
  • an info text, that some action has been started
  • a label text and a value text to tell,  from where the function module has been called
  • an info text, that the screen will be closed automaticall.

Code of the function module

FUNCTION zmy_popup_show.


*”*”Local Interface:









* Filling dynpro fields and interval

  xv_header_text                     =  i_header_text.

  xv_info_text1                      =  i_info_text1.

  xv_info_text2                      =  i_info_text2.

  xv_label_text                      =  i_label_text.

  xv_value_text                      =  i_value_text.

  xv_interval                        =  i_interval.

* Call info screen 9000

  CALL SCREEN                           ‘9000’

    STARTING                        AT  5 5.


Here I pass all input parameters to global defined variables. All text fields will be shown at the screen.

Code of the function group’s TOP include

FUNCTION-POOL zmy_popup.                    “MESSAGE-ID ..

* Definitions

CLASS xcl_event_receiver      DEFINITION DEFERRED.

DATA: xo_event          TYPE  REF TO xcl_event_receiver.”#EC NEEDED

DATA: xv_header_text    TYPE  text80.

DATA: xv_info_text1     TYPE  text80.

DATA: xv_info_text2     TYPE  text80.

DATA: xv_interval       TYPE  i.

DATA: xv_label_text     TYPE  text30.

DATA: xo_timer          TYPE  REF TO cl_gui_timer.

DATA: xv_value_text     TYPE  text50.

* Definition of class XCL_EVENT_RECEIVER

  INCLUDE lzmy_popupcls.

For catching the FINISHED event of class CL_GUI_TIMER a local event receiver class is needed:

Event Receiver Class Definition …


*&  Include           LZMY_POPUPCLS



*   CLASS xcl_event_receiver DEFINITION


CLASS xcl_event_receiver DEFINITION.



      timer_finished       FOR EVENT  finished

                                  OF  cl_gui_timer.

ENDCLASS.                    “xcl_event_receiver DEFINITION

… and Implementation


*&  Include           LZMY_POPUPCLI



*   CLASS xcl_event_receiver IMPLEMENTATION                            *


*   Handle events                                                      *


CLASS xcl_event_receiver IMPLEMENTATION.


*       METHOD timer_finished                                          *


*       Action after timer has finished                                *


  METHOD timer_finished.

        PERFORM                     exit_dynpro.

  ENDMETHOD.                    “timer_finished

ENDCLASS.                    “xcl_event_receiver IMPLEMENTATION

How to leave will be shown in FORM EXIT_DYNPRO later.

Definition of the Info Screen 9000

The flow logic looks pretty simple:


  MODULE call_timer.



  MODULE exit_dynpro.

The screen contains the fields


and some frames:


Remark: Übertschrift means Header/Heading.

Definition of PBO module CALL_TIMER:


*&  Include           LZMY_POPUPO01



*&      Module  CALL_TIMER  OUTPUT


*       Create and start timer


MODULE call_timer OUTPUT.

* Timer setzen

  CREATE  OBJECT                     xo_timer


      OTHERS                      =  4.

  CHECK sy-subrc                 EQ  0.

  SET HANDLER xo_event->timer_finished FOR xo_timer.

  xo_timer->interval              =  xv_interval.

  xo_timer->run( ).


Here the timer object is created, the event handler is set, the timer interval is set and the timer is started.

Definition of optional PAI module EXIT_DYNPRO:


*&  Include           LZMY_POPUPI01



*&      Module  EXIT_DYNPRO  INPUT


*       Leave Screen


MODULE exit_dynpro INPUT.

  CASE  sy-ucomm.


        PERFORM                     exit_dynpro.



This module is optional, if you want to close the info screen manually, too.

Definition of FORM routine EXIT_DYNPRO:


*&  Include           LZMY_POPUPF01



*&      Form  EXIT_DYNPRO


*       Leave Screen


FORM exit_dynpro .

    FREE                                xo_timer.

    CLEAR                               xo_timer.

    LEAVE                           TO  SCREEN 0.

ENDFORM.                    ” EXIT_DYNPRO

And the Function Group ZMY_POPUP looks like::


*   System-defined Include-files.                                 *


  INCLUDE lzmy_popuptop.                     ” Global Data

  INCLUDE lzmy_popupuxx.                     ” Function Modules


*   User-defined Include-files (if necessary).                    *


  INCLUDE lzmy_popupcli.                     ” Class Implementation

  INCLUDE lzmy_popupf01.                     ” FORM Routines

  INCLUDE lzmy_popupi01.                     ” PAI-Modules

  INCLUDE lzmy_popupo01.                     ” PBO-Modules

Now the Function Group ZMY_POPUP and Function Module ZMY_POPUP_SHOW are complete.

Calling Function Module ZMY_POPUP_SHOW from report

After testing this function module in SE37, I added an asynchronous RFC call to my ALV Grid reports looking like


     STARTING          NEW TASK  ‘POPUP’


       i_header_text          =  text-hdr

       i_info_text1           =  text-in1

       i_label_text           =  text-lbl

       i_value_text           =  xv_text_val

       i_info_text2           =  xv_text_in2

       i_interval             =  xk_interval.

And the result looks like


The screen closes automatically and all could be fine, if there were no …

Further issues

First issue is, that for calling this function module in ARFC mode you need a free user mode. If you have no free user mode, the call won’t work. So I’ve coded a workaround, that this function module is only called, if a free user mode is availabale:



      act_sessions            =  xv_s_act

      max_sessions            =  xv_s_max.

   CHECK  xv_s_max           GT  xv_s_act.

This is no fine solution but a workaround only..

The other issue is, that to process a function module in RFC mode you need the authority to do it, like

Authority object:      S_RFC

Authority field:       RFC_TYPE      Value:    FUGR

Authority field:       RFC_NAME      Value:    ZMY_POPUP

Authority field:       ACTVT         Value:    16

Looking for improvement

So I’m searching for an improvement of this solution, where I don’t need a free user mode and I don’t need additional authorities.

I’m looking forward to seeing your suggestions.



You must be Logged on to comment or reply to a post.
  • More user friendly than good old SAPGUI_PROGRESS_INDICATOR (at least more funny to code 😉 )

    To bypass the no node available, you could execute the selection/layout of data in a RFC function (*) in a new task calling a method at end, and display the pop-up in the main (interactive) node ?



    (*) Actually, you already did that for Web application ?

    • Hi Raymond,

      thanks for your reply. I’ve used the SAPGUI_PROGRESS_INDICATOR first, but it shows nothing, if a transaction is called with function code input /oMY_TCODE.

      At the moment the aRFC call is before starting the data selection fm in non-RFC mode.

      Do I unterstand you right:

      The call of the screen should be in the normal report while the data gathering and layout creation should be done in aRFC mode with the data gathering fm.

      Hm, I’m not sure, but I think the layout creation can stay in the normal report. And if I use option PERFORMING ON END OF TASK  in the aRFC call of the data gathering rfc this looks like a working idea for me.

      But I think this is no solution for my both issues:

      • I still need an additional user mode and
      • I still nedd a RFC authority (but then for the function group of the data gathering fm).

      But many thanks for thinking about my issues and trying to help.



      (*) While the 1st transaction is running on PROD system now, the Web team will sonn start to create their Web application (outside SAP).

  • Hi,

    Interesting implementation.

    However, I have two remarks:

    1. Why not using standard FM SAPGUI_PROGRESS_INDICATOR?

    2. If you are still interested in popup, you may check class cl_gui_dialogbox_container, which allows floating window in the same session.

    • Hi Shai,

      I’m using SAPGUI_PROGRESS_INDICATOR additionally, but the users don’t look at the indicator line, while there is nothing changing on the screen. And while calling with function code input /oMY_TCODE the indicator doesn’t show anything.

      I’ll try to use class cl_gui_dialogbox_container (never used it before !).

      Thank you for this inspiration. I’ll tell you the result.



      • Hi,

        I created a simple sample report to test the new session (/o option) behaviour and it seems you are right.

        As far as I can tell from ABAP/SAPGUI architecture, it’s probably related to the fact that no interaction with presentation server/user is required (Since no selection screen is displayed).

        May I ask why selection screen shouldn’t be displayed?

        • Hi,

          the data selection is clearly defined and the users have no chance to modify something there, because the data have to be the same as in the web tool, which displays the same data on a huge display board.

          When the data gathering has finished, the users can do some sort or filter options in the ALV Grid. Those settings are removed after pressing the refresh button to keep the data identical to the current display board data, which will be automatically refreshes after a short period.

          So no parameters and select-options are needed and the users don’t want to be stopped by an empty selection screen with a dummy parameter (for this will spend additional time).

          Yesterday I tokk a look at class  cl_gui_dialogbox_container and I’m still not sure how to use it without having a screen and keeping my report running. Maybe a docking container may help me there. But for urgent other issues I have to stop this action now and will continue working on it next week. I’ll tell you the results here.



    • Hi Shai,

      I’ve tested with class CL_GUI_DIALOGBOX_CONTAINER. So I tried to do the following after START-OF-SELECTION:

      1. Create and display the dialogbox.
      2. Call the function module to get all data
      3. Close the dialogbox
      4. Show the data in a grid

      But the issue is, that the dialogbox is displayed not until step 4 is reached. I’ve checked this with different parent and lifetime options, but it isn’t displayed immediately.

      I added a step between steps 1. and 2. to call a screen with SUPPRESS DIALOG at PBO and LEAVE SCREEN at PAI, but the result remains the same.

      I’ve added lines like

        xo_dialog->set_visible( ‘X’ ).



            control                       =  xo_dialog


        cl_gui_cfw=>flush( ).

      where xo_dialog is my dialogbox container, but nothing changes. I think, the dialogbox can only be displayed, if there is at least one screen shown in this user mode. And this is the same also, when the parent is cl_gui_container=>desktop.

      Finally I’ve created a selection screen with a dummy parameter to analyze this issue. And the issue remains the same. The dialogbox container is appearing, if the next screen wil be sent to the GUI.

      Maybe there will exist a GUI method to solve my issue, but still I hvaen’t found it.



      • Hi Klaus,

        It seems you are right (dialogbox isn’t displayed when no screen is available).

        However, in the meanwhile, I though of a much simpler approach, which doesn’t involve CL_GUI_DIALOGBOX_CONTAINER.

        For a matter of fact, it’s just a small tweak of your original solution: Use real screen instead of popup screen.

        1. END-OF-SELECTION.

              CALL SCREEN 9999. ” Loading screen

        2. MODULE init_screen_9999.

               PERFORM call_timer.

        3. METHOD timer_finished.

               PERFORM select_data.

               LEAVE TO SCREEN 100. ” Actual screen

        or alternatively (this one can be encapsulated in standalone FM):

        1. END-OF-SELECTION.

              CALL SCREEN 100.

        2. MODULE init_screen_0100.

                IF gv_init IS INITIAL.

                   CALL SCREEN 9999.

                   gv_init = ‘X’.


        3. MODULE init_screen_9999.

                   PERFORM call_timer.

        3. METHOD timer_finished.

               PERFORM select_data IN PROGRAM calling_report.

               LEAVE TO SCREEN 0.

        What do you think?



        • Hi Shai,

          I’m not sure that I’ve got you idea. The screen that you name 0100 is that standard output screen of CL_GUI_ALV_GRID, where the data will be displayed, right? I don’t think that I can make any changes there.

          And when will you start data selection via fm ? If I understand right you are starting after timer_finished event, while I want to display information during the data selection process.

          I can’t imagine that one of these alternatives will work in the way I wanted to use it.

          Many thanks anyway for your ideas. I’ve used CL_GUI_DIALOGBOX_CONTAINER meanwhile in another program, where I have to display a PDF file (with given URL) as a user guide. There it is working fine.



          • Hi Klaus,

            Yes, screen 0100 is that standard ALV screen.

            The trick is that screen 9999 (custom “loading” screen) is displayed immediately, while data selection is executed just afterwards (via timer_finished).

            Please examine the second alternative. It should fulfill your requirements.

            You may even encapsulate it in a standalone FM.

            FM should look as below:

            1. FM ZCA_LOADING_SCREEN

                   gv_form = iv_form.

                   gv_calling_report = iv_report.

                   CALL SCREEN 9999.

            2. MODULE init_9999 OUTPUT.

                  PERFORM call_timer.

            3. METHOD timer_finished.

                   PERFORM (gv_form) IN PROGRAM (gv_calling_report).

                   LEAVE TO SCREEN 0.

            Then, the only thing you have to add in the standard report is:

            MODULE init_screen_0100.

                    IF gv_init IS INITIAL.

                      CALL FUNCTION ‘ZCA_LOADING_SCREEN’.

                      gv_init = ‘X’.




          • Hi Shai,

            thank you, I’ve tested your idea.

            If I call my transaction with ‘/oMY_TCODE’ the loading screen appears, and it also automatically disappears, when the data screen of the ALV Grid appears.

            If I call MY_TCODE directly first empty data screen appears, and then after one second the loading screen appears. When the function module has finished, the loading screen automatically disappears.

            In both cases I had an empty data screen, so I needed a


            call to see the data.

            I’ve set the timer to one second, for this is the lowest working value for the timer. The timer interval is wasted time, but needed for the timer_finished event.

            But although this solution has a wasted time period of one second, I think this is a better solution than mine described above, for I need only one user mode here

            Best regards,


          • Hi Klaus,

            I’m glad to see that it helped you.

            Not sure why you have one second delay before loading screen is displayed, though.

            As you’ve mentioned there is one “wasted” second. However, since timer is being triggered by loading screen, loading screen should be displayed immediately.

            Best regards,