Hallo, Ich mag deine Videos, und editierbare ALVs sind sicher eine hilfreiche Sache - aber... 😬 Das Beispiel ist zwar schnell geschrieben, aber nicht schön. Das geht auch mit OO, und nicht mit FORMS und TABLES - das sollte man heutzutage wirklich nicht mehr verwenden, auch wenn es "schnell zur Hand" ist. Frage: Wozu brauche ich die interne Tabelle IT_CHANGES, wenn ich nach der Befüllung nichts mehr mit ihr anfange? Da ist es mMn besser gleich ein MODIFY auf die gesamte Tabelle zu machen, und kann sich auch die Compare-Tabelle sparen. (Außer man braucht es später noch irgendwo. ZB zum Feststellen, ob etwas geändert wurde, und falls nicht dem User ein Meldung "Keine Änderung - nichts zu Speichern" anzuzeigen). Anfrage: Gibt es irgendwo (z.B. Github) die Möglichkeit deine Code-Beispiele runterzuladen? Wäre cool. LG Michael
Nun ja, erlaubt ist was funktioniert.😀 Forms und Tables sind jetzt nicht "alt" aber es funktioniert in jedem Release. Eine OO Lösung um ein ALV zu editieren und zu speichern gibt es meines Wissens nur ab 756 und ist ein "Hack". Verwendet ihr eine funktionierende OO Lösung? Bin immer offen für andere Lösungen 😀 Das Update erfolgt im Loop weil man hier z.B. noch Prüfungen einbauen könnte. Die IT_CHANGES dient nur als Übersicht. Die kann man ausgeben oder versenden. Aber ja kann man auch nicht verwenden. Diese Lösung ist (für mich) deutlich bequemer als die Pflege über SM30. Aber kommt halt auch auf den Anwendungfall an 🤗 Auf Github habe ich leider keine public repositories. Wenn ihr praktische Codesnippets habt von denen du glaubst dass sie auch andere Entwickerler intessieren könnten würde ich mich auf die Zusendung freuen. 🤗
@@CustAndCode Hallo, Ich hab mich damit jetzt nochmal etwas intensiver beschäftigt. Zum einen gibt es den von dir erwähnten "Hack" für SALV - ja, der ist nicht schön, und funktioniert auch nur bedingt. Zumal man hier mE zu tief in die Eingeweide von der ALV-Technik eingreift. Andererseits heißt es von SAP, dass die beiden REUSE-Funktionsbausteine obsolet sind, und man doch (gefälligst) die CL_SALV_TABLE verwenden soll, nur dass die halt nur über die Hack-Lösung eine Möglichkeit zum Editieren bietet. Da beißt sich die Katze halt in den Schwanz. Andererseits verwendet SAP selbst die REUSE-Bausteine in ihren eigenen Klassen, also können die so obsolet auch wieder nicht sein. Ich habe jetzt eine Lösung gebastelt, die zum Großteil OO ist. Eine FORM-Routine konnte ich leider nicht vermeiden, und das ist jene, die aus dem REUSE-Baustein gerufen wird. Wäre schön gewesen, wenn man stattdessen eine statische Methode hätte rufen können - ist aber nicht... Was ich mir erspare, sind viele der DATA-Definitionen, den PF-Status, sowie dieTABLES-Definition. Falls du schauen möchtest - ich habe meine Lösung hier hochgeladen: github.com/mwcem/Z_DEMO/blob/main/ZZDEMO_EDIT_SALV LG mwcem
Hallo,
Ich mag deine Videos, und editierbare ALVs sind sicher eine hilfreiche Sache - aber... 😬
Das Beispiel ist zwar schnell geschrieben, aber nicht schön. Das geht auch mit OO, und nicht mit FORMS und TABLES - das sollte man heutzutage wirklich nicht mehr verwenden, auch wenn es "schnell zur Hand" ist.
Frage: Wozu brauche ich die interne Tabelle IT_CHANGES, wenn ich nach der Befüllung nichts mehr mit ihr anfange? Da ist es mMn besser gleich ein MODIFY auf die gesamte Tabelle zu machen, und kann sich auch die Compare-Tabelle sparen. (Außer man braucht es später noch irgendwo. ZB zum Feststellen, ob etwas geändert wurde, und falls nicht dem User ein Meldung "Keine Änderung - nichts zu Speichern" anzuzeigen).
Anfrage: Gibt es irgendwo (z.B. Github) die Möglichkeit deine Code-Beispiele runterzuladen? Wäre cool.
LG
Michael
Nun ja, erlaubt ist was funktioniert.😀 Forms und Tables sind jetzt nicht "alt" aber es funktioniert in jedem Release. Eine OO Lösung um ein ALV zu editieren und zu speichern gibt es meines Wissens nur ab 756 und ist ein "Hack". Verwendet ihr eine funktionierende OO Lösung? Bin immer offen für andere Lösungen 😀
Das Update erfolgt im Loop weil man hier z.B. noch Prüfungen einbauen könnte. Die IT_CHANGES dient nur als Übersicht. Die kann man ausgeben oder versenden. Aber ja kann man auch nicht verwenden. Diese Lösung ist (für mich) deutlich bequemer als die Pflege über SM30. Aber kommt halt auch auf den Anwendungfall an 🤗
Auf Github habe ich leider keine public repositories. Wenn ihr praktische Codesnippets habt von denen du glaubst dass sie auch andere Entwickerler intessieren könnten würde ich mich auf die Zusendung freuen. 🤗
@@CustAndCode Hallo,
Ich hab mich damit jetzt nochmal etwas intensiver beschäftigt. Zum einen gibt es den von dir erwähnten "Hack" für SALV - ja, der ist nicht schön, und funktioniert auch nur bedingt. Zumal man hier mE zu tief in die Eingeweide von der ALV-Technik eingreift. Andererseits heißt es von SAP, dass die beiden REUSE-Funktionsbausteine obsolet sind, und man doch (gefälligst) die CL_SALV_TABLE verwenden soll, nur dass die halt nur über die Hack-Lösung eine Möglichkeit zum Editieren bietet. Da beißt sich die Katze halt in den Schwanz.
Andererseits verwendet SAP selbst die REUSE-Bausteine in ihren eigenen Klassen, also können die so obsolet auch wieder nicht sein. Ich habe jetzt eine Lösung gebastelt, die zum Großteil OO ist. Eine FORM-Routine konnte ich leider nicht vermeiden, und das ist jene, die aus dem REUSE-Baustein gerufen wird. Wäre schön gewesen, wenn man stattdessen eine statische Methode hätte rufen können - ist aber nicht...
Was ich mir erspare, sind viele der DATA-Definitionen, den PF-Status, sowie dieTABLES-Definition.
Falls du schauen möchtest - ich habe meine Lösung hier hochgeladen: github.com/mwcem/Z_DEMO/blob/main/ZZDEMO_EDIT_SALV
LG
mwcem