0

I create internal table by two steps, both refer to the RTTS-techniques. The first step loads and parses a tab-delimited file into a table. The second step reads this table by RTTI, then, hardcoded, adds some other columns in front of the old columns from the file and, finally adds the old fields back again, the table now has about 12 new hardcoded columns, in front of those from the file. The RTTS helps to create the final table, which then is passed as the data source to the ALV grid.

My former requirement did not take into account that the ALV-grid-toolbar-functions will ever be needed by the end-user, however, as always, this has changed. I enabled the toolbar functions, the default ones, without any custom button.

So, now the user can remove some columns from the display or add them back again, she/he can also change their order. Everything is fine but I never encountered this situation with a table, which is created during runtime.

Are there special culprits I need to be aware of ?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
icbytes
  • 1,831
  • 1
  • 17
  • 27

2 Answers2

1

<ITAB> created using RTTS functionality is fully supported either by the REUSE_ALV_LIST_DISPLAY or one of ALV OOPS technologies. All the layouts should work fine. In fact I think in the cl_salv_table=>factory RTTS is responsible for automatic creation of the field catalog of the ITAB since it do not need field catalog passed by the parameter. The only thing that I heard is lost pointers of the <ITAB> ant this leads to refresh problems and so on but this is different story.

stack overflow user
  • 79
  • 5
  • I did that with cl_table factory, it returned the fieldcat nice. I just ask because, if a layout will be saved by an user, and, later on, some columns of the file change, which are referenced in the layout, and the user applies it again, can I expect a dump? – icbytes Feb 07 '17 at 20:29
  • Thats interesting case. I think there wouldn't be a dump because we could ge same situation like this: ITAB is created statically, some user create it's own layout and then programer remove field from ITAB. We get same situation, missing field in the layout and it would not make a dump. – stack overflow user Feb 07 '17 at 20:58
  • On purpouse no, but this is fairly common situation and it's esay to test. Saldy I could not test on computer which I am using right now – stack overflow user Feb 07 '17 at 21:08
  • If You are still interested in this topic I test situation as I mention before when ITAB is created statically, user create it's own layout and the some column from ITAB is removed and despite that layout was working without any problems, it just doesn't look at the removed columns and if you add these columns again it will use these columns as before – stack overflow user Feb 08 '17 at 07:17
  • THX a lot for the testing, in fact our PI vendor now told me, that he has set up the server, which we will reach by PI. The filecontents were just, to simulate the PI results, which now can be tested as reals scenario. I will now test that, and look, what happens to a layout, which is set up on columns at T=1 and then, after change, at T=2, and also verify that. – icbytes Feb 10 '17 at 09:12
  • Subsystem still not reachable, tests by consultant seem to confirm, even with runtime generated source table, the alv-layout-functionality is working. For all people, who might forget: show_table_for_first_display ( EXPORTING i_save) is not an boolean. Use 'A' for user specific layout saving mode. – icbytes Feb 17 '17 at 09:58
-1

From my experience, ALV column maximum size is 120 characters. So if your file could have more than that, you could have a problem. Otherwise, do not expect any major thing.

Denis
  • 31
  • 2
  • 8