You are probably already familiar with one of the following methods to create dynamic popup screens
- FM ‘POPUP_GET_VALUES’
- FM ‘FREE_SELECTIONS_DIALOG’
- CL_CI_QUERY_ATTRIBUTES=>GENERIC( )
But let’s make them a little bit more flexibly in a OOP term.
1) First of all how to transfer context between a SCREEN and your program?
It’s more likely that in selection or regular screens you create special structures. So let’s assume that we are declared one.
BEGIN OF ts_context, p_bukrs TYPE bukrs, p_bdc_m TYPE ettcd_mode, " <-- listbox by domain p_mandt TYPE t001-mandt, " <-- listbox in runtime p_check TYPE xsdboolean, s_user TYPE offline_log_user_itab, " Range <-- cl_ci_query_attributes no SH p_land1 TYPE t005t-land1, p_fld_i TYPE syindex, " do not use i! use from dictionary p_fld_i2 TYPE sytabix, " do not use i! use from dictionary " String & tables also Ok " p_memo TYPE stringval, " t_table TYPE STANDARD TABLE OF t005t WITH DEFAULT KEY, END OF ts_context.
So if we want to pass the initial values to a screen just pass the above structure in
DATA(lo_scr_1020) = NEW zcl_eui_screen( ir_context = new ts_context( p_bukrs = '1000' ) ).
But if we want get inputted vales back we have to create additional
DATA(lr_context) = new ts_context( p_bukrs = '1000' ). " Context transfer DATA(lo_scr_1020) = NEW zcl_eui_screen( iv_dynnr = zcl_eui_screen=>mc_dynnr-dynamic ir_context = lr_context ). " If the user clicked OK CHECK lo_scr_1020->popup( )->show( ) = 'OK'. " Get result DATA(lv_new_bukrs) = lr_context->p_bukrs.
As you already noticed there are could be:
- Memo field (strings)
- And even tables
String & tables fields are not so common, but sometimes they can be very helpful.
2) Screen customization
2.1 – Usually Ok & Cancel buttons are enough, but you can set your own PF-STATUS in SET_STATUS method.
For SET TITLEBAR just pass the title in a string format
DATA(lo_scr_1020) = NEW zcl_eui_screen( iv_dynnr = '1020' )->set_status( VALUE #( title = 'Screen title' prog = sy-cprog name = 'STATUS_MANY_BUTTONS' ) ).
2.2 PBO & LOOP AT SCREEN
Your can use PAI & PBO events for customization
But personally I prefer to pass the PBO logic in rules form, since very often in LOOP AT SCREEN syntax could be very long and quite confusing.
I hope the meaning of this syntax is clear without explanation, since the parameters correspond to the SCREEN fields.
" Gray lo_screen->customize( name = 'P_FLD_01' input = '0' ). " Obligatory & change text lo_screen->customize( name = 'P_FLD_02' required = '1' iv_label = 'Make required' ).
- NAME argument can contain wildcards, and GROUP1 & GROUP2 arguments could be useful for statically declared screens (dynamic screens are created via iv_dynnr = FREE_SEL or DYNAMIC, for statically created screens pass ordinary screen number)
- Also you pass all rules in one IT_ parameter & and update the rules in PBO event.
3) User input validation
To validate user input (PAI) or change behavior in PBO you have to set handlers.
The current ZCL_EUI_SCREEN and previously mentioned ZCL_EUI_ALV class share common ancestor class
That’s why all handlers are set in SHOW method
via IO_HANDLER argument
Closing sy-ucomm command is returned in RV_CLOSE_CMD parameter (‘OK’ or <> ‘OK’ for default PF-STATUS )
In PBO & PAI it is possible to call sender->get_context( ) method to access current context. The context will be updated with new values entered by a user.
For those who think that calling old fashioned FMs non comme il faut: