Easy popup screens

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