Easy popup screens

[former_member351591]

Hi ABAP-ers!

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 ir_context parameter.

    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 lr_contextvariable.

    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:

• Parameters


• Select-options


• Checkboxes


• Listboxes


• Memo field (strings)


• And even tables

result based on a structure

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:

• Another documentation


• Github project