REUSE_ALV_GRID_DISPLAY und Callback für GUI-Status und UC
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
3 Beiträge
•
Seite 1 von 1
3 Beiträge
Seite 1 von 1
Hallo!
Ich benutze den FuBa 'REUSE_ALV_GRID_DISPLAY_LVC' mit Callbacks für den GUI-Status 'i_callback_pf_status_set' und für die Auswertung von ok-codes 'i_callback_user_command'.
Im selbst-definierten GUI-Status habe ich eigene Funktionscodes festgelegt, auf die ich in der USER_COMMAND-Callback-Routine reagieren möchte.
Das Problem ist, dass die interne Tabelle des Grids beim Sprung in die USER_COMMAND-Form nicht den aktuellen Stand enthält. Auch wenn ich ein cl_gui_cfw=>flush ausführe ist der Inhalt der internen Tabelle nicht mit dem Inhalt des Grids synchronisiert.
Es ist sogar so, dass der Inhalt auch in mehrfachen Aufrufen hintereinander nicht synchronisiert wird. Dabei findet doch ein automatischer Flush spätestens am Ende von PBO statt.
Das Ganze hängt irgendwie mit den selbst-definierten ok-codes zusammen. Im Beispielprogramm 'BCALV_FULLSCREEN_GRID_EDIT' ist die Funktionalität so, wie ich sie haben wollte, nur dass dort der GUI-Status-Callback nicht genutzt wird.
Wenn ich im selbst definierten GUI-Status ebenfalls den ok-code '&DATA_SAVE' nenne, funktioniert übrigens alles reibungslos (weil wohl zuerst die eigenen Behandlungsroutinen für diesen ok-code greifen). Wenn ich den ok-code aber 'EXPORT' betitele, funzt es nicht.
Sicherlich könnte ich auch die Grid-Klasse verwenden, ist aber eigentlich etwas Overkill für die Kleinigkeit, die ich vorhatte.
Kann mir da jemand weiterhelfen?
Danke im Voraus.
Gruß, Markus.
Ich benutze den FuBa 'REUSE_ALV_GRID_DISPLAY_LVC' mit Callbacks für den GUI-Status 'i_callback_pf_status_set' und für die Auswertung von ok-codes 'i_callback_user_command'.
Im selbst-definierten GUI-Status habe ich eigene Funktionscodes festgelegt, auf die ich in der USER_COMMAND-Callback-Routine reagieren möchte.
Das Problem ist, dass die interne Tabelle des Grids beim Sprung in die USER_COMMAND-Form nicht den aktuellen Stand enthält. Auch wenn ich ein cl_gui_cfw=>flush ausführe ist der Inhalt der internen Tabelle nicht mit dem Inhalt des Grids synchronisiert.
Es ist sogar so, dass der Inhalt auch in mehrfachen Aufrufen hintereinander nicht synchronisiert wird. Dabei findet doch ein automatischer Flush spätestens am Ende von PBO statt.
Das Ganze hängt irgendwie mit den selbst-definierten ok-codes zusammen. Im Beispielprogramm 'BCALV_FULLSCREEN_GRID_EDIT' ist die Funktionalität so, wie ich sie haben wollte, nur dass dort der GUI-Status-Callback nicht genutzt wird.
Wenn ich im selbst definierten GUI-Status ebenfalls den ok-code '&DATA_SAVE' nenne, funktioniert übrigens alles reibungslos (weil wohl zuerst die eigenen Behandlungsroutinen für diesen ok-code greifen). Wenn ich den ok-code aber 'EXPORT' betitele, funzt es nicht.
Sicherlich könnte ich auch die Grid-Klasse verwenden, ist aber eigentlich etwas Overkill für die Kleinigkeit, die ich vorhatte.
Kann mir da jemand weiterhelfen?
Danke im Voraus.
Gruß, Markus.
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Offenbar geht es einfach um die Frage:
Wie informiere ich mein ALV-Grid davon, dass ein User-Command von meinem GUI-Status abgesetzt wurde und dass ich bitteschön die aktuellen Daten des Grids in meiner internen Tabelle wiederfinden möchte (in PAI)?
Ein Flush bringt komischerweise nichts. Dabei sollte doch dadurch die Automation Queue abgearbeitet werden UND die Daten (Layout-Struktur, Feldkatalog, interne Tabelle) abgeglichen werden, oder irre ich mich?
Ich habe als nächsten Schritt doch die Grid-Klasse verwendet und einen eigenen GUI-Status => dasselbe Problem! In PAI-stehen die Daten des Grids nicht in der internen Tabelle.
Eine Lösung habe ich gefunden:
Nach der Methode CHECK_CHANGED_DATA stehen die aktualisierten Daten in der internen Tabelle.
Die Lösung reicht mir eigentlich, aber ich wüsste gern, wie man so etwas bei den REUSE-Bausteinen hinkriegt? Schließlich habe ich dort keine Referenzvariable zum Grid und kann daher auch keine Methoden aufrufen.
Freue mich über jeden Beitrag!
Gruß, Markus
Wie informiere ich mein ALV-Grid davon, dass ein User-Command von meinem GUI-Status abgesetzt wurde und dass ich bitteschön die aktuellen Daten des Grids in meiner internen Tabelle wiederfinden möchte (in PAI)?
Ein Flush bringt komischerweise nichts. Dabei sollte doch dadurch die Automation Queue abgearbeitet werden UND die Daten (Layout-Struktur, Feldkatalog, interne Tabelle) abgeglichen werden, oder irre ich mich?
Ich habe als nächsten Schritt doch die Grid-Klasse verwendet und einen eigenen GUI-Status => dasselbe Problem! In PAI-stehen die Daten des Grids nicht in der internen Tabelle.
Eine Lösung habe ich gefunden:
Code: Alles auswählen.
CASE sy-ucomm.
WHEN 'SAVE_DATA'.
CALL METHOD gx_grid->check_changed_data
IMPORTING
e_valid = l_valid
CHANGING
c_refresh = l_refresh.
Die Lösung reicht mir eigentlich, aber ich wüsste gern, wie man so etwas bei den REUSE-Bausteinen hinkriegt? Schließlich habe ich dort keine Referenzvariable zum Grid und kann daher auch keine Methoden aufrufen.
Freue mich über jeden Beitrag!
Gruß, Markus
Seite 1 von 1
Vergleichbare Themen
6
Antw.
Antw.
5563
Views
Views
2
Antw.
Antw.
3156
Views
Views
REUSE _ ALV _ LIST _ DISPLAY - Zeile nicht markieren
von Gast » 12.09.2005 08:42 • Verfasst in ABAP® Core
von Gast » 12.09.2005 08:42 • Verfasst in ABAP® Core
1
Antw.
Antw.
2741
Views
Views
4
Antw.
Antw.
2525
Views
Views
suche fieldcatalog - Name für Spaltenkopf bei REUSE-ALV-GRID
von jogi » 20.04.2005 15:23 • Verfasst in Dialogprogrammierung
von jogi » 20.04.2005 15:23 • Verfasst in Dialogprogrammierung
Frage die ABAP Experten
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 19 Stunden von ralf.wenzel 104 / 10243
vor 19 Stunden von ralf.wenzel 104 / 10243
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 19 Stunden von ralf.wenzel 104 / 10243
vor 19 Stunden von ralf.wenzel 104 / 10243