Code: Alles auswählen.
REPORT.
END-OF-SELECTION.
SELECT SPRAS,
LAND1,
LANDX
INTO TABLE @DATA(gt_data)
FROM t005t.
TRY.
cl_salv_table=>factory( EXPORTING
r_container = cl_gui_container=>screen0
IMPORTING
r_salv_table = DATA(go_salv)
CHANGING
t_table = gt_data ).
* lo_salv->get_columns( )->set_exception_column( 'HUGO' ). " Force error
go_salv->display( ).
CATCH cx_root INTO DATA(go_cx_root).
WRITE:/ |Error: { go_cx_root->get_longtext( ) }| COLOR 6.
RETURN.
ENDTRY.
WRITE:/ '.'.
Sehe ich exakt genau so.ralf.wenzel hat geschrieben:Also, ich verwende die 7.40-Sprachkonstrukte sehr oft und gern, weil das Coding deutlich kompakter wird und man sich ganze Bündel von Hilfsvariablen schenken kann.
Wie nicht jede triviale Anweisung, gehört natürlich ein gescheiter, ausführlicher Kommentar dazu (das ist vielen Entwicklern nicht beizubringen), aber das ist dann immer noch deutlich lesbarer als umkommentiert und mit x Hilfsvariablen, die dann noch h_var1, h_var2, etc. heißen.
Ich meinte sowas wie "ich mach jetzt aus einer Liste von Partnerrollen eine Selektionstabele mit Partnerrollen"ewx hat geschrieben:Ein Gedankengang eines Mathematikers entspricht ca. 34 Enno-Gedankengängen...
Insofern ist auch das wieder relativ.
Hat aber mE erst mal nix mit den neuen Sprachelementen zu tun.
Ein Design Pattern ist im Grunde auch EIN Gedankengang.
Kommt darauf an, wieviel Wissen und Erfahrung der andere hat.
Das liegt im Auge des Betrachters. Ich verliere mich schnell in Programmen, die hier und da ständig Hilfsvariablen verwenden (oft nur einmal) oder wo plötzlich in sy-tfill ein 'X' vom Himmel fällt. Bei sowas werde ich wahnsinnig, besonders wenn die dann h_var1 (Hilfsvariable 1) heißen.Daniel hat geschrieben:Viele der Konstrukte sind schlicht Unsinn, die meisten sehr
schlecht lesbar.
Code: Alles auswählen.
FIELD-SYMBOLS:
" nur die hier Deklarationen, die wir nur
" für diese Lösung brauchen:
<txt> type tline,
<sol> type soli.
LOOP AT mailtxt-txt ASSIGNING <txt>.
APPEND INITIAL LINE TO mailtext-sol
ASSIGNING <sol>.
<sol> = <txt>-tdline.
ENDLOOP.
Code: Alles auswählen.
" konvertiere Textinhaltsspalte in Emailtext-Tabelle
mailtext-sol = value #( for <i> in mailtext-txt ( line = <i>-tdline ) ).
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 4):
ewx • wreichelt • black_adept • Haubi
Code: Alles auswählen.
FIELD-SYMBOLS:
<txt> TYPE tline,
<sol> TYPE soli.
LOOP AT t_lines ASSIGNING <txt>.
APPEND INITIAL LINE TO t_soli ASSIGNING <sol>.
<sol> = <txt>-tdline.
ENDLOOP.
Code: Alles auswählen.
LOOP AT t_lines ASSIGNING FIELD-SYMBOL(<ls_line>).
APPEND <ls_line>-tdline TO t_soli.
ENDLOOP.
Code: Alles auswählen.
LOOP AT t_lines ASSIGNING FIELD-SYMBOL(<ls_line>).
APPEND value #( line = <ls_line>-tdline ) TO t_soli.
ENDLOOP.
Code: Alles auswählen.
t_soli = VALUE #( FOR <i> IN t_lines ( line = <i>-tdline ) ).
Code: Alles auswählen.
t_soli = CORRESPONDING #( t_lines MAPPING line = tdline ).
So ganz unrecht hat Daniel aber auch nicht. Hier mal der Ausschnitt des Beispielcodings welches SAP zum neuen Befehl "FILTER" anbietet.Daniel hat geschrieben:Viele der Konstrukte sind schlicht Unsinn, die meisten sehr
schlecht lesbar.
Code: Alles auswählen.
TYPES: BEGIN OF filter,
cityfrom TYPE spfli-cityfrom,
cityto TYPE spfli-cityto,
END OF filter,
filter_tab TYPE HASHED TABLE OF filter
WITH UNIQUE KEY cityfrom cityto.
DATA(filter_tab) = VALUE filter_tab(
( cityfrom = cityfrom cityto = cityto )
( cityfrom = cityto cityto = cityfrom ) ).
SELECT carrid, connid, cityfrom, cityto
FROM spfli
ORDER BY carrid, connid, cityfrom, cityto
INTO TABLE @DATA(spfli_tab).
cl_demo_output=>display(
FILTER #( spfli_tab IN filter_tab
WHERE cityfrom = cityfrom AND cityto = cityto ) ).