Grid refresh Issue after screen switch
At vendor master screen enhancement, I create several customized screens to achieve the below purposes:
- Screen 100- The main screen holds 1st/2nd level key fields along with Vendor no. and purchase org, provides buttons to create/modify/view address, etc.
- Screen 200- Single address maintenance screen
- Screen 300-View already maintained addresses using grid refer to cl_gui_alv_grid
Switching between screens:
- Button ‘Create/Modify Address’ will call screen 200 to support single address maintenance.
- Button ‘View Address’ will call screen 300 to display lists of already maintained addresses.
- Call screen 200 when double-click a single line at screen 300, and the user can modify already existed address details at 200 and click return then get back to screen 300.
Now the issue is:
At above point 3, the newest modification at screen 200 will not be reflected when back to screen 300 (already update the global data used by ALV grid at screen 300), now an extra ‘Refresh’ button has been created to achieve this refreshment. But it’s quite annoying and not user-friendly. Many very similar issues had been brought out like the below questions:
- To refresh the ALV grid display (question link)
Refresh ALV Grid after execution of secondary screen (question link)
Refresh ALV Report after return from dialog screen(question link)
I try the below approaches:
Call Method grid->refresh_table_display
- Call refresh method at end of double click Event for screen 300 is triggered, but not working.
- Call refresh method at PAI of screen 200 is triggered, but not working.
- Call refresh method at PBO of screen 200 is not triggered at all.
Call method cl_gui_cfw=>flush
- Call this method along with refresh_table_display is not working
LEAVE TO SCREEN 300 at return button of screen 200
- using LEAVE TO SCREEN 300 instead of LEAVE TO SCREEN 0 will call another 300 with the initial screen and conflict with the original 300~
Call method set_new_ok_code
- call the below code at the return button and no refresh as well~
CALL METHOD cl_gui_cfw=>set_new_ok_code EXPORTING new_code = 'REFRESH'. CALL METHOD cl_gui_cfw=>flush.
Function module ‘SAPGUI_SET_FUNCTIONCODE’
- call the below code at the return button and it’s working!!!
CALL FUNCTION 'SAPGUI_SET_FUNCTIONCODE' EXPORTING functioncode = 'REFRESH' EXCEPTIONS function_not_supported = 1 OTHERS = 2. LEAVE TO SCREEN 0.
The documentation for this FM:
Functionality This module simulates user input in the command field. This enables you to run screen sequences without user input. Example A screen contains a single output field: Counter ____ with the field reference "count". This field is changed in the single flow logic module: process before output. module pbo. and the default function code "=" is processed: module pbo output. add 1 to count. if count > 20. leave to screen 0. endif. call function 'SAPGUI_SET_FUNCTIONCODE'. endmodule. Notes Since the function SAPGUI_SET_FUNCTIONCODE is not implemented for all front end platforms, you may need to use a substitute solution. For example: call function 'SAPGUI_SET_FUNCTIONCODE' exporting functioncode = 'ABCD' exceptions function_not_supported = 1. if sy-subrc <> 0. suppress dialog. endif. "For Motif etc.
One blog explains how to force Enter event by using this FM.
I’m not a master of the screen painter, please kindly let me know if any wrong 😀
refresh_table_display SHOULD work, unless you are doing something wrong, but It's difficult to understand the situation without the code (but it would be better to prepare a distinct minimal reproducible code and to discuss based on it). You wouldn't need to have a REFRESH button. And so, you shouldn't need to execute a function code programatically.
In your case, theoretically, there could be an unlimited number of screen calls switching between 200 and 300, but it's limited to 50 CALL SCREEN. Either you agree on that limit, if a user does more than 50 screen calls, that will short dump, and the user will have to restart. Otherwise, I would suggest that you use SET SCREEN instead. If needed, you can internally stack the situation in memory.
Thanks for your comments, it's very helpful! Get your point, going to recheck my code and try to use SET SCREEN instead! I'll not list messy code here as too many screens are involved : D