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.
cancel
Showing results for 
Search instead for 
Did you mean: 
RichHeilman
Developer Advocate
Developer Advocate

The other day, "Blag" raised a question on Twitter around this topic.  He was having trouble with a program where there were multiple table controls on a single screen.  He asked if there was some kind of limit as to how many you could possibly have on a screen, I answered, "There shouldn't be any limit".  And so, I left it at that, figuring that he would figure out his error eventually.  Then today, he tweeted again, mentioning that he simply could not get it working.  So I spend a few minutes, trying to recreate this issue on my system, and what do you know, I was seeing some real issues also.  For example, none of my data was showing in any of the table controls.  I was sure that I had coded everything correctly, and I even used the table control wizard to create the table controls, so everything should be fine, right? 

Here is the quick and dirty test program.  It is very simple, one screen(100) with four table controls in it, each representing an internal table, Itab1, Itab2, Itab3, and Itab4. This program will add a record to each internal table and simply throw the screen.

REPORT  zmult_tcs.

TYPES: BEGIN OF t_tab,
               field1(20) TYPE c,
               field2(20) TYPE c,
              END OF t_tab.

DATA: itab1 TYPE TABLE OF t_tab WITH HEADER LINE.
DATA: itab2 TYPE TABLE OF t_tab WITH HEADER LINE.
DATA: itab3 TYPE TABLE OF t_tab WITH HEADER LINE.
DATA: itab4 TYPE TABLE OF t_tab WITH HEADER LINE.

DATA: ok_code TYPE sy-ucomm.

CONTROLS: itab1tc TYPE TABLEVIEW USING SCREEN 0100.
CONTROLS: itab2tc TYPE TABLEVIEW USING SCREEN 0100.
CONTROLS: itab3tc TYPE TABLEVIEW USING SCREEN 0100.
CONTROLS: itab4tc TYPE TABLEVIEW USING SCREEN 0100.

START-OF-SELECTION.

  itab1-field1 = 'Itab1-Field1'.
  itab1-field2 = 'Itab1-Field2'.
  APPEND itab1.
  itab2-field1 = 'Itab2-Field1'.
  itab2-field2 = 'Itab2-Field2'.
  APPEND itab2.
  itab3-field1 = 'Itab3-Field1'.
  itab3-field2 = 'Itab3-Field2'.
  APPEND itab3.
  itab4-field1 = 'Itab4-Field1'.
  itab4-field2 = 'Itab4-Field2'.
  APPEND itab4.

  CALL SCREEN 100.
*&---------------------------------------------------------------------*
*&      Module  STATUS_0100  OUTPUT
*&---------------------------------------------------------------------*
MODULE status_0100 OUTPUT.
  SET PF-STATUS '0100'.
  SET TITLEBAR '0100'.

ENDMODULE.                 
*&---------------------------------------------------------------------*
*&      Module  USER_COMMAND_0100  INPUT
*&---------------------------------------------------------------------*
MODULE user_command_0100 INPUT.

  CASE ok_code.
    WHEN 'BACK'.
      LEAVE PROGRAM.
  ENDCASE.

ENDMODULE.                 

So when I run this progam, the output is very strange.  There is no data in my tables? Why?  While debugging, I could see that the data was there, just before throwing the screen.

 

After going over the program again and again, including the screen flow logic, I realized that I got a message when I created the second table control.  It mentioned that when using multiple table controls in one screen, it was important that the screen flow logic was in the order of the table controls on the screen, from left->right, and top->bottom.  I didn't think much of it at the time, as I had never seen this message before, and it was an information message.  I then checked the screen flow logic and noticed that the table control wizard had written the coding in such a way that it was in reverse order, coding for Itab4 was first, Itab3 was second, and so on. 

  PROCESS BEFORE OUTPUT.

  LOOP AT   itab4
       WITH CONTROL itab4tc
       CURSOR itab4tc-current_line.
*&SPWIZARD:   MODULE ITAB4TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  LOOP AT   itab3
       WITH CONTROL itab3tc
       CURSOR itab3tc-current_line.
*&SPWIZARD:   MODULE ITAB3TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  LOOP AT   itab2
       WITH CONTROL itab2tc
       CURSOR itab2tc-current_line.
*&SPWIZARD:   MODULE ITAB2TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  LOOP AT   itab1
       WITH CONTROL itab1tc
       CURSOR itab1tc-current_line.
*&SPWIZARD:   MODULE ITAB1TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  MODULE status_0100.

 

This had to be the problem, so I changed the order of the coding, so that it reflects the order of the table controls on the screen.  From left to right, and from top to bottom.  Sure enough, the data showed up in the table controls.

 

  PROCESS BEFORE OUTPUT.

  LOOP AT   itab1
       WITH CONTROL itab1tc
       CURSOR itab1tc-current_line.
*&SPWIZARD:   MODULE ITAB1TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  LOOP AT   itab2
       WITH CONTROL itab2tc
       CURSOR itab2tc-current_line.
*&SPWIZARD:   MODULE ITAB2TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  LOOP AT   itab3
       WITH CONTROL itab3tc
       CURSOR itab3tc-current_line.
*&SPWIZARD:   MODULE ITAB3TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  LOOP AT   itab4
       WITH CONTROL itab4tc
       CURSOR itab4tc-current_line.
*&SPWIZARD:   MODULE ITAB4TC_CHANGE_FIELD_ATTR
  ENDLOOP.

  MODULE status_0100.

As mentioned before, I don't remember ever seeing this information message about multiple table controls on one screen, but the last time that I had done so, I was working on a 46c system, and maybe that message is not there in that release.  This could be the reason why Blag had such an issue, as I believe he is currently working in 46c.  I believe that Blag has since abandoned the table controls and went with ALVs instead, but In any case, I hope this blog post clears up the issue, and saves others from the same misery that Blag has gone through lately.

13 Comments