Skip to Content

 

Hello SDNers. This is my first post and i hope you enjoy it.

First of all, have you ever spent a considering (and boring) time when developing the screen logic of a simple report? If yes, this post is for you handle selection screen easily.

 

Handle selection screens using “LOOP AT SCREEN” statement can be very boring and consume some time when developing and maintaining such logic. I developed a simple class which helped me a lot in handling selection screens events like changing the input, visibility or others attributes from parameters and select-options 

 

I will explain how it works using a simple example. We are supposed to create a report which has 2 radio buttons and some additional parameters and select-options. When selecting the first radio button (or the first option), the fields which correspond to this option should be ready for input, and the others which correspond to the other options should be not be ready for input. The same logic applies when selecting the second radio button: the fields for this option must change it status for input ready and the others not.

 

Imagine the situations: there are a lot of fields which must change theirs status when selecting the available radio buttons or the number of radio buttons (options) probably will increase with the time or even worst: the selection screen should follow a crazy logic where not only the input status of parameters and selection options should be changed but also the others attributes basically contained in global structure “SCREEN” (required, color, 3D display, invisible and so on).

 

You can solve this problem using a simple “LOOP AT SCREEN” statement which might be very confusing  and boring to develop and mainly maintaining it. So, a global class (here called “ZCL_DYNPRO_HANDLER”) can solve this error prone situation.

 

The objects created using this class will represent a single configuration of the screen at a given moment. The methods from the class will change the attributes (contained in global structure “SCREEN”) of parameters and selection-options.

 

At the beginning of the report we’ll create the configuration of ours different objects (which will represent a given status of selection screen). After this step, it’s only necessary to apply these configurations when necessary. As in our example there are two options for the user  (represented with radio buttons), two objects must be created.

 

Below is the report from our example and after it the global class with some methods to change some fields’ attributes.

 

  –


REPORT  z_dynpro_report.

DATA: l_o_screen_configuration_1 TYPE REF TO zcl_dynpro_handler,

l_o_screen_configuration_2 TYPE REF TO zcl_dynpro_handler.

DATA: v_carrid TYPE scarr-carrid.

PARAMETERS: r_opt_1 RADIOBUTTON GROUP opt USER-COMMAND option_selected.

PARAMETERS: p_carrid TYPE scarr-carrid.

PARAMETERS: r_opt_2 RADIOBUTTON GROUP opt.

SELECT-OPTIONS: s_carrid FOR v_carrid.

 

INITIALIZATION.

  ” The initial state of selection screen is loaded (just as the screen is declared)

  CREATE OBJECT:

  l_o_screen_configuration_1 TYPE zcl_dynpro_handler,

  l_o_screen_configuration_2 TYPE zcl_dynpro_handler.

 

  ” Configuration of screen state 1

  CALL METHOD l_o_screen_configuration_1->set_input

    EXPORTING

      im_field_name = ‘P_CARRID’

      im_input_mode = abap_true.

 

  CALL METHOD l_o_screen_configuration_1->set_input

    EXPORTING

      im_field_name = ‘S_CARRID-LOW’

      im_input_mode = abap_false.

 

  CALL METHOD l_o_screen_configuration_1->set_input

    EXPORTING

     im_field_name = ‘S_CARRID-HIGH’

      im_input_mode = abap_false.

 

  ” Configuration of screen state 2

  CALL METHOD l_o_screen_configuration_2->set_input

    EXPORTING

      im_field_name = ‘P_CARRID’

      im_input_mode = abap_false.

 

  CALL METHOD l_o_screen_configuration_2->set_input

    EXPORTING

      im_field_name = ‘S_CARRID-LOW’

      im_input_mode = abap_true.

 

  CALL METHOD l_o_screen_configuration_2->set_input

    EXPORTING

      im_field_name = ‘S_CARRID-HIGH’

      im_input_mode = abap_true.

 

” Default configuration

  CALL METHOD l_o_screen_configuration_1->commit_screen.

 

AT SELECTION-SCREEN OUTPUT.

  IF r_opt_1 = ‘X’.

    ” Apply configuration 1

    CALL METHOD l_o_screen_configuration_1->commit_screen.

  ENDIF.

 

  IF r_opt_2 = ‘X’.

    ” Apply configuration 2

    CALL METHOD l_o_screen_configuration_2->commit_screen.

  ENDIF.

 

START-OF-SELECTION.

  ” Here the important part which you will need to worry…

 

h2.  ZCL_DYNPRO_HANDLER Class

 

 *************************************************************************</p><p> Class attributes. *

 ************************************************************************</p><p>Instantiation: Public</p><p>Message class: </p><p>State: Implemented</p><p>Final Indicator: X</p><p>R/3 Release: 700</p><p>************************************************************************</p><p> Public section of class. </p><p>*************************************************************************

 

class ZCL_DYNPRO_HANDLER definition

   public

   final

   create public .

 

  public components of class ZCL_DYNPRO_HANDLER

  do not include other source files here!!

 public section.

  

  methods COMMIT_SCREEN .

   methods CONSTRUCTOR .

   type-pools ABAP .

   methods SET_DISPLAY_3D

     importing

       value(IM_FIELD_NAME) type STRING

       value(IM_DISPLAY_3D) type ABAP_BOOL default ABAP_TRUE .

 

  methods SET_INPUT

     importing

      value(IM_FIELD_NAME) type STRING

       IM_INPUT_MODE type ABAP_BOOL default ABAP_TRUE .

 

  methods SET_INVISIBLE

     importing

       IM_FIELD_NAME type STRING

       IM_INVISIBLE type ABAP_BOOL default ABAP_TRUE .

 

  methods SET_OUTPUT

     importing

       value(IM_FIELD_NAME) type STRING

       value(IM_OUTPUT) type ABAP_BOOL default ABAP_TRUE .

 

  methods SET_REQUIRED

     importing

       IM_REQUIRED type ABAP_BOOL default ABAP_TRUE

       value(IM_FIELD_NAME) type STRING

     preferred parameter IM_REQUIRED .

  

**************************************************************************

 * Private section of class. *

 *************************************************************************</p><p>“* private components of class ZCL_DYNPRO_HANDLER

  do not include other source files here!!

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Sandra Rossi
    I think it would be best to NOT define methods with the parameter ON/OFF, but only define methods which does an explicit job.

    For example, method SET_OUTPUT should set both INPUT to 0, and OUTPUT to 1 (in case default is 1). And maybe other flags should be set.

    Moreover, it simplifies the writing and reading:
    lo_screen_configuration_2->set_output( ‘P_CARRID’ ).

    (0) 
    1. Sandra Rossi
      To terminate my proposition, there could be 4 methods which each set 4 flags:
      1) set_input: input=1, output=1, display_3d=1, invisible=0
      2) set_output: input=0, output=1, display_3d=1, invisible=0
      3) set_as_text: input=0, output=1, display_3d=0, invisible=0
      4) set_password: : input=1, output=1, display_3d=1, invisible=1
      (0) 
      1. Fabio Pagoti Post author
        I didn’t think in that. Really good!
        Using this approach, you can keep the consistency of the selection screen! I’m going to enhance my class with your hints.

        🙂

        (0) 
  2. Anonymous
    Great idea.

    To your third con: Why the LOOP in the setters? you could do a READ TABLE like in the commit method. The name should be unique. Or, just in case, do the LOOP with WHERE name = im_field_name.

    (0) 
  3. Michelle Crapo
    I love it.  With the enhancements suggested in the comments, I love it even more.

    Very nice blog.  I’m glad I went back and read this one!

    Michelle

    (0) 

Leave a Reply