Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Hi ABAP-ers!

You are probably already familiar with one of the following methods to create dynamic popup screens




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,
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



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
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: