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.
Issue
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:
*” IMPORTING
*” VALUE(I_HEADER_TEXT) TYPE TEXT80
*” VALUE(I_INFO_TEXT1) TYPE TEXT80
*” VALUE(I_LABEL_TEXT) TYPE TEXT30 OPTIONAL
*” VALUE(I_VALUE_TEXT) TYPE TEXT50 OPTIONAL
*” VALUE(I_INFO_TEXT2) TYPE TEXT80 OPTIONAL
*” VALUE(I_INTERVAL) TYPE I DEFAULT 5
*”———————————————————————-
* 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.
ENDFUNCTION.
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.
PUBLIC SECTION.
CLASS-METHODS:
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:
PROCESS BEFORE OUTPUT.
MODULE call_timer.
*
PROCESS AFTER INPUT.
MODULE exit_dynpro.
The screen contains the fields
- XV_HEADER_TEXT
- XV_INFO_TEXT1
- XV_LABEL_TEXT
- XV_VALUE_TEXT
- XV_INFO_TEXT2
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
EXCEPTIONS
OTHERS = 4.
CHECK sy-subrc EQ 0.
SET HANDLER xo_event->timer_finished FOR xo_timer.
xo_timer->interval = xv_interval.
xo_timer->run( ).
ENDMODULE. ” CALL_TIMER OUTPUT
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.
WHEN ‘ECAN’.
PERFORM exit_dynpro.
ENDCASE.
ENDMODULE. ” EXIT_DYNPRO INPUT
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
CALL FUNCTION ‘Z2V_POPUP_SHOW’
STARTING NEW TASK ‘POPUP’
EXPORTING
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:
CALL FUNCTION ‘TH_USER_INFO’
IMPORTING
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.
Regards,
Klaus
Hi,
Useful Informative post, well the idea is new to me . So no inputs from me.
regards,
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 ?
Regards,
Raymond
(*) 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:
But many thanks for thinking about my issues and trying to help.
Regards,
Klaus
(*) 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.
Regards,
Klaus
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.
Regards,
Klaus
Hi Shai,
I've tested with class CL_GUI_DIALOGBOX_CONTAINER. So I tried to do the following after START-OF-SELECTION:
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' ).
cl_gui_control=>set_focus(
EXPORTING
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.
Regards,
Klaus
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'.
ENDIF.
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?
Regards,
Shai
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.
Regards,
Klaus
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'.
ENDIF.
Regards,
Shai
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
MY_GRID->REFRESH_TABLE_DISPLAY
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,
Klaus.
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,
Shai