Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Chaining Table Control columns

0 Kudos

Hi developers,

in my first post ever I have this challenge to offer:

Is there, in ABAP dynpro programming of table controls, in analogy to the PAI construct


  LOOP AT field_attrib_tab.
    CHAIN.
    FIELD crms_es_attr_data_scrn-field_id,
              crms_es_attr_data_scrn-select_ind.
      MODULE check_attribute ON CHAIN-REQUEST.
    ENDCHAIN.
  ENDLOOP.

in which each line of of the table control is checked in CHECK_ATTRIBUTE

and maybe and error-message is thrown therein, which would unlock the

current line for correcting;

an anlogue construct for complete columns in a table control?

I mean a way of telling the table control to unlock two complete columns for correction

after an error-message occurred, and not only a single row.

I already tried the following things without success:

1. Using an i-message instead of an e-message would leave all fields open, but it also triggers again a PBO and (in my case) navigates then away from the screen. An information message here would also not be to the point.

2. Calling CHECK_ATTRIBUTE outside of the loop simply would lock all fields of the

table since they are not grouped in chains.

3. Within the loop, calling


     field CRMS_ES_ATTR_DATA_SCRN-select_ind
    MODULE check_attribute on chain-input.

would simply lock the complete table after the error occurred, although select_ind certainly

is a part of the table control structure used.

I am not sure whether I really reached a dead-end of ABAP programming, since I think I might have seen a customizing-dialog with a table control that was able to unlock a complete column after an error. But I am not sure about this.

Do you perhaps have an idea?

Many thanks & best regards,

Konrad

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi Konrad Loster,

Column in a table control can not be disabled within or using CHAIN...ENDCHAIN statement.

Instead it can be done explicitly.

Just declare a ERROR FLAG i.e. Single char variable and a variable to hold required COLUMN name.

Once you got the required COLUMN, then add following code in the MODULE within LOOP...ENDLOOP in PBO:


  MODULE ZTC_GET_LINES OUTPUT.
    LOOP AT SCREEN.
      IF SCREEN-NAME = V_CNAM.
        SCREEN-INPUT = 'O'.
        MODIFY SCREEN.
      ENDIF.
    ENDLOOP.
    G_ZTC_LINES = SY-LOOPC.
  ENDMODULE.

Here, V_CNAM contains the SCREEN FIELD NAME of the required column. i.e. like WA-MATNR.

WA is the work area.

Regards,

R.Nagarajan.

-


We can -


4 REPLIES 4

Former Member
0 Kudos

Hi Konrad Loster,

Column in a table control can not be disabled within or using CHAIN...ENDCHAIN statement.

Instead it can be done explicitly.

Just declare a ERROR FLAG i.e. Single char variable and a variable to hold required COLUMN name.

Once you got the required COLUMN, then add following code in the MODULE within LOOP...ENDLOOP in PBO:


  MODULE ZTC_GET_LINES OUTPUT.
    LOOP AT SCREEN.
      IF SCREEN-NAME = V_CNAM.
        SCREEN-INPUT = 'O'.
        MODIFY SCREEN.
      ENDIF.
    ENDLOOP.
    G_ZTC_LINES = SY-LOOPC.
  ENDMODULE.

Here, V_CNAM contains the SCREEN FIELD NAME of the required column. i.e. like WA-MATNR.

WA is the work area.

Regards,

R.Nagarajan.

-


We can -


0 Kudos

Hello Nagarajan Ramamoorthy,

thanks a lot for your early response.

I adapted your suggestion to my situation like this:

1. In PAI, within the loop over the table being displayed in the table control, but outside a CHAIN ... ENDCHAIN construct, I am performing my checks on the contents the user has changed.

Errors occurring there would fill a flag. (This is what I did also before)

2. In PAI, after the loop over the table being displyded, I am calling a module which raises an

e-message in case the flag mentioned above is filled. The e-message here would stop calling

the PBO hereafter and stay on the screen for editing. But it would also disable all screen input, because

the feature from point 1 is not bound in a chain.

But in order to make your suggestion work, I changed that message to

MESSAGE i284(crm_es) DISPLAY LIKE 'E'.

and also raised a flag there:

lv_lang_err_flag = abap_true.

3. In PBO of that dynpro I created a new module to realize your example for table controls like this:

(My columns in question are put in two separate screen groups)


   LOOP AT tc_attributes-cols INTO cols.
    IF ( ( cols-screen-group1 EQ 'LKY' ) OR ( cols-screen-group1 EQ 'TXT' ) )
      AND ( lv_lang_err_flag eq abap_true ).
      cols-screen-input =  0 .
        MODIFY tc_attributes-cols FROM cols.
    ENDIF.
  ENDLOOP.

  clear lv_lang_err_flag.

The result is, that after the error occurred, the message is displayed, the flag is set and the system then navigates away from the screen. So no matter what loops over the screen I make - since PBO is called again and the navigation event is fired, I cannot prevent the system from navigating away.

This means that unfortunately only an E-message can skip PBO, and it would also allow only fields in a row to be edited again when they are part of a chain construct.

The conclusion I draw now is that ABAP by design is not able to handle such a simple case and I have to think of a completely different solution.

Thanks & regards,

Konrad

0 Kudos

Hi Konrad Loster,

In PBO, just check the ERROR FLAG and restrict the navigation event. Obviously this flag will be initial while the PBO executed first time. i.e. as follows.


  IF FLG_ERR = 'X'.
    .....
  ENDIF.
  SET PF-STATUS 'ZGUI'.

You should not do enything else once this flag is set.

Make sure that you are not checking and setting this flag within CHAIN...ENDCHAIN statement.

Regards,

R.Nagarajan.

-


We can -


0 Kudos

Thanks Nagarajan Ramamoorthy,

but I simply cannot prevent navigation, since the error occurs on a subscreen that displays the panels of nodes belonging to an ALV Tree. When the user triggers navigation, this is done globally from the main dynpro and cannot be prevented.

I am forced by the system to handle this problem with an e-message and the CHAIN-construct only.

No flags can help in this case unfortunately, I am convinced now.

Thanks & regards,

Konrad