ALV - Inhalt aktualisieren und Sortierung geht nach Refresh kaputt
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Hallo zusammen,
ich habe ein ALV des Typs CL_SALV_TABLE. Es ist mit einer eigenwilligen Sortierung definiert, aber das funktioniert gut. So wird die Anzeige des ALV ausgelöst (in einem PBO-Modul des Dynpros):
Jetzt wird ein von mir definierter Toolbar-Button des ALV angeklickt. In dem zugehörigen Event ändert sich der Inhalt der dem ALV zugrundeliegenden internen Tabelle ALV_TABLE (siehe oben bei FACTORY).
ich habe ein ALV des Typs CL_SALV_TABLE. Es ist mit einer eigenwilligen Sortierung definiert, aber das funktioniert gut. So wird die Anzeige des ALV ausgelöst (in einem PBO-Modul des Dynpros):
Code: Alles auswählen.
CALL METHOD CL_SALV_TABLE=>FACTORY
EXPORTING R_CONTAINER = ALV_CONTAINER
IMPORTING R_SALV_TABLE = ALV_OBJECT
CHANGING T_TABLE = ALV_TABLE.
[... diverse Detaildefinitionen zum ALV ...]
ALV_OBJECT->DISPLAY( ).
DATA(SORTOBJECT) = ALV_OBJECT->GET_SORTS( ).
SORTOBJECT->ADD_SORT( COLUMNNAME = 'DOCNUM' SEQUENCE = IF_SALV_C_SORT=>SORT_DOWN GROUP = IF_SALV_C_SORT=>GROUP_WITH_UNDERLINE ).
SORTOBJECT->ADD_SORT( COLUMNNAME = 'CREDAT' SEQUENCE = IF_SALV_C_SORT=>SORT_DOWN ).
SORTOBJECT->ADD_SORT( COLUMNNAME = 'CRETIM' SEQUENCE = IF_SALV_C_SORT=>SORT_DOWN ).
SORTOBJECT->ADD_SORT( COLUMNNAME = 'UPDDAT' SEQUENCE = IF_SALV_C_SORT=>SORT_DOWN ).
SORTOBJECT->ADD_SORT( COLUMNNAME = 'UPDTIM' SEQUENCE = IF_SALV_C_SORT=>SORT_DOWN ).
ALV_OBJECT->REFRESH( ).- Wenn ich jetzt ALV_OBJECT->REFRESH( ) erneut aufrufe, dann wird zwar der Inhalt des ALVs erneut angezeigt, aber die oben gezeigte Sortierung wird nicht mehr korrekt beachtet: So wird nach DOCNUM deutlich erkennbar aufsteigend (statt wie oben definiert absteigend) sortiert.
- Wie kriege ich überhaupt den neuen Inhalt von ALV_TABLE in das ALV rein?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Rufe DISPLAY nach den Add_Sorts auf und lasse REFRESH weg
Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
DeathAndPain
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Vielen Dank, das ist sicherlich eine nette Optimierung, die ich gerade reingemacht habe. Wobei ich aufpassen muss, denn der Code sitzt ja im PBO des Dynpros und darf nur bei erstmaligem Aufruf des Dynpros ausgeführt werden.
Es funktioniert, aber es löst mein Problem nicht, dass ein späterer Refresh (nach einem Toolbar-Button-Ereignis und damit einhergehend geändertem Inhalt von ALV_TABLE) die Sortierung zerschlägt. Und an dieser Stelle werde ich ja sicherlich einen Refresh brauchen. Wobei mir, wie gesagt, auch nicht klar ist, wie ich dem ALV überhaupt sagen soll, dass es jetzt einen neuen Inhalt erhält. Beim FACTORY gebe ich den Parameter CHANGING T_TABLE = ALV_TABLE an. Aber wenn sich zu einem späteren Zeitpunkt (!) der Inhalt von ALV_TABLE verändert hat, wie übergebe ich diesen geänderten Inhalt dann an das ALV?
Es funktioniert, aber es löst mein Problem nicht, dass ein späterer Refresh (nach einem Toolbar-Button-Ereignis und damit einhergehend geändertem Inhalt von ALV_TABLE) die Sortierung zerschlägt. Und an dieser Stelle werde ich ja sicherlich einen Refresh brauchen. Wobei mir, wie gesagt, auch nicht klar ist, wie ich dem ALV überhaupt sagen soll, dass es jetzt einen neuen Inhalt erhält. Beim FACTORY gebe ich den Parameter CHANGING T_TABLE = ALV_TABLE an. Aber wenn sich zu einem späteren Zeitpunkt (!) der Inhalt von ALV_TABLE verändert hat, wie übergebe ich diesen geänderten Inhalt dann an das ALV?
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Also es funktioniert jetzt. Den entscheidenden Tipp bzgl. der Sortierung habe ich hier gefunden:
https://www.abapforum.com/forum/viewtop ... =3&t=14102
Was ich noch nicht verstanden habe, ist, warum es funktioniert. Woher weiß die REFRESH()-Methode, was sich in meiner Tabelle ALV_TABLE verändert hat? Hängt das damit zusammen, dass der Parameter beim Aufruf von FACTORY als Referenz übergeben wird? Aber woher weiß die REFRESH()-Methode, welche Tabelle der FACTORY seinerzeit übergeben bekommen hat?
https://www.abapforum.com/forum/viewtop ... =3&t=14102
Was ich noch nicht verstanden habe, ist, warum es funktioniert. Woher weiß die REFRESH()-Methode, was sich in meiner Tabelle ALV_TABLE verändert hat? Hängt das damit zusammen, dass der Parameter beim Aufruf von FACTORY als Referenz übergeben wird? Aber woher weiß die REFRESH()-Methode, welche Tabelle der FACTORY seinerzeit übergeben bekommen hat?
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Die Factory Methode bekommt die Tabelle als Referenz (= Zeiger in C) übergeben. CHANGING ist in diesem Fall irrelevant und betrifft nur ein editierbares SALV. Somit arbeitet das Grid direkt mit den Daten die in besagter Tabelle stehen anstatt eine "Kopie" davon anzulegen. Man muss dem Grid nur sagen, dass die Daten geändert wurden, damit diese an den GUI geschickt werden. Wofür das REFRESH zuständig ist.
EDIT: Was noch zu beachten ist, dass man man die übergebene Tabelle "global" definiert hat. Lokale Tabellen (z.B. in Methoden) funktionieren zwar auch mit dem SALV (es wird dann halt intern eine Kopie erzeugt) aber man verliert die Fähigkeit der REFRESH Methode.
EDIT: Was noch zu beachten ist, dass man man die übergebene Tabelle "global" definiert hat. Lokale Tabellen (z.B. in Methoden) funktionieren zwar auch mit dem SALV (es wird dann halt intern eine Kopie erzeugt) aber man verliert die Fähigkeit der REFRESH Methode.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
DeathAndPain
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Danke, das ist informativ. Aber auch ganz schön tückisch, weil dadurch die Parametrisierung nicht mehr klar ist. Irgendwann später im Code ändert man den Inhalt einer internen Tabelle, und implizit ändert sich dadurch plötzlich im Dynpro das ALV, wenn parameterlos der REFRESH() aufgerufen wird. Sowas ist schwer zu überblicken, vor allem, wenn man nicht der Autor des Codes ist. Ich hätte es schöner gefunden, wenn die FACTORY-Methode dann zumindest einen REF TO DATA anstelle der Tabelle selbst verlangt hätte; dann wäre es an dieser Stelle zumindest statisch erkennbar, dass hier mit einem Vektor gearbeitet wird, den man im Auge behalten muss (ABAP: Referenz, C: Zeiger, C64: Vektor 😆).
Noch besser fände ich freilich, wenn man die Tabelle beim REFRESH als Parameter mitgeben würde. Der Code wäre nur unwesentlich länger, aber für den Leser wäre bedeutend besser nachvollziehbar, was da passiert.
Noch besser fände ich freilich, wenn man die Tabelle beim REFRESH als Parameter mitgeben würde. Der Code wäre nur unwesentlich länger, aber für den Leser wäre bedeutend besser nachvollziehbar, was da passiert.
Dann fang mal mit einem editierbaren ALV und der damit Verbundenen Kommunikation an.DeathAndPain hat geschrieben: ↑12.10.2023 13:24Noch besser fände ich freilich, wenn man die Tabelle beim REFRESH als Parameter mitgeben würde. Der Code wäre nur unwesentlich länger, aber für den Leser wäre bedeutend besser nachvollziehbar, was da passiert.
Ist beim SALV nur mit Tricks oder in sehr jungen/hohen Releases möglich.
Da muss das Programm aktiv nachdem Änderungen „Fragen“ sonst bleiben diese im FrontEnd. Der „Transport“ erfolgt dann wieder in die globale interne Tabelle ohne explizite Angabe.
Wobei ich es gar nicht mal so schlimm finde das die Daten in einer globalen internen Tabelle gehalten werden, davon kann es ja nur eine geben….erst wenn das Programm verschiedene Daten/Tabellen anzeigen soll wird es spannend: Wie genau macht der Entwickler das. Da gibt es schöne und weniger schöne Lösungswege.
Gruß Hendrik
Dann fang mal mit einem editierbaren ALV und der damit Verbundenen Kommunikation an.DeathAndPain hat geschrieben: ↑12.10.2023 13:24Noch besser fände ich freilich, wenn man die Tabelle beim REFRESH als Parameter mitgeben würde. Der Code wäre nur unwesentlich länger, aber für den Leser wäre bedeutend besser nachvollziehbar, was da passiert.
Ist beim SALV nur mit Tricks oder in sehr jungen/hohen Releases möglich.
Da muss das Programm aktiv nachdem Änderungen „Fragen“ sonst bleiben diese im FrontEnd. Der „Transport“ erfolgt dann wieder in die globale interne Tabelle ohne explizite Angabe.
Wobei ich es gar nicht mal so schlimm finde das die Daten in einer globalen internen Tabelle gehalten werden, davon kann es ja nur eine geben….erst wenn das Programm verschiedene Daten/Tabellen anzeigen soll wird es spannend: Wie genau macht der Entwickler das. Da gibt es schöne und weniger schöne Lösungswege.
Gruß Hendrik
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Warum sich die SAP (noch zu ALV Zeiten) für diesen Weg entschieden hat, liegt an der aufwändigen Aufbereitung der Daten (Feldkatalog, Sortierung, usw.) ehe sie an den GUI geschickt werden können. Wenn das jedes Mal bei einem Refresh wiederholt werden müsste, wäre das ALV einen raschen (vielleicht doch eher "langsamen") Tod gestorben. Um das letzte bisschen an Performance rauszukitzeln haben sie ja später auch noch jede Menge Puffer rund um das ALV drapiert. Deswegen muss man bei bestimmten Änderungen erst einen Reset machen bevor man was sieht.
Das später entwickelte SALV ist ja im Grunde nur ein aufwändiger Überbau und daher konnte man am Grundverhalten nicht viel ändern.
Das später entwickelte SALV ist ja im Grunde nur ein aufwändiger Überbau und daher konnte man am Grundverhalten nicht viel ändern.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1941 / 257 /
412
)
»
Dass die SAP die editierbaren ALVs mies gelöst hat, ist keine Rechtfertigung, das hier auch ungünstig zu machen. Ändern können wir es alle nicht. Wollte halt nur mal laut die Nase rümpfen. (Und von editierbaren ALVs halte ich ohnehin nicht viel. Zum Bearbeiten finde ich Table Controls noch immer anwenderfreundlicher.)
Dass die Tabelle global sein muss, finde ich weniger schlimm, denn wir reden von einer internen Tabelle, die in einem Dynpro dargestellt werden soll. Werte, die in Dynpros dargestellt werden, müssen traditionell immer global sein, da die Dynpromodule alle im globalen Kontext ausgeführt werden. Eine Altlast, ja, aber bei den ALVs auch globale Tabellen zu nutzen, ist da nur konsequent. Aus diesem Grunde war ALV_TABLE in meinem Programm auch schon global, so dass ich an dieser Stelle nichts habe anfassen müssen (als Konsequenz dieses Threads hier).
Dass die Tabelle global sein muss, finde ich weniger schlimm, denn wir reden von einer internen Tabelle, die in einem Dynpro dargestellt werden soll. Werte, die in Dynpros dargestellt werden, müssen traditionell immer global sein, da die Dynpromodule alle im globalen Kontext ausgeführt werden. Eine Altlast, ja, aber bei den ALVs auch globale Tabellen zu nutzen, ist da nur konsequent. Aus diesem Grunde war ALV_TABLE in meinem Programm auch schon global, so dass ich an dieser Stelle nichts habe anfassen müssen (als Konsequenz dieses Threads hier).
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
5007
Views
Views
CL_SALV_TABLE: Refresh zerstört die Sortierung
von donny » 08.04.2008 08:53 • Verfasst in ABAP Objects®
von donny » 08.04.2008 08:53 • Verfasst in ABAP Objects®
4
Antw.
Antw.
5080
Views
Views
ALV Grid Sortierung aktualisieren im grid 1 und grid 2
von c oco » 06.02.2012 10:09 • Verfasst in ABAP Objects®
von c oco » 06.02.2012 10:09 • Verfasst in ABAP Objects®
2
Antw.
Antw.
2714
Views
Views
0
Antw.
Antw.
5036
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1086
vor 2 Tagen von DeathAndPain 4 / 1086
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1086
vor 2 Tagen von DeathAndPain 4 / 1086