Buttonsteuerung ALV-Grid ausprogrammieren
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
6 Beiträge
•
Seite 1 von 1
6 Beiträge
Seite 1 von 1
Beitrag
von 19KnarfRed81 (ForumUser / 19 / 10 /
3
)
»
Hallo Zusammen,
ich habe mir eine Z-Klasse als Unterklasse von einer anderen Z-Klasse erstellt, die wiederum als Oberklasse die CL_ICL_GRID_BASE hat, da ich bereits Funktionen der ersten Z-Klasse bei mir nutzen möchte.
Nun erstelle ich mir hiermit mein ALV-Grid.
Wenn ich nun die Standard-Buttons z.B. "Zeile anhängen", "Zeile einfügen", "Zeile Löschen" betätige, funktioniert auf dem Dynpro auch alles wie erwartet. Nur sind die Änderungen beim nächsten Laden aus dem Memory (pbo_get_data) logischerweise wieder weg, da ich hier aktiv keinen Abgleich mit der iTab vornehme.
Wenn ich einen Breakpoint in der von der Masterklasse (CL_ICL_GRID_BASE) geerbten Methode HANDLE_USER_COMMAND setze, wird diese gar nicht durchlaufen.
Warum ist das so und wo müsste ich mich reinhängen um das Löschen auszuprogrammieren? Das Hinzufügen habe ich in der PAI Methode (pai_set_data) gemacht. Das funktioniert zumindest...
Stehe voll auf dem Schlauch, da ich den Prozess halt auch nicht debuggt bekomme. Wenn ich die Buttons drücke, wird im Frontend die Änderung vollzogen aber der Debugger springt nicht an.
Ich bedanke mich voraus, für Eure Tipps!
ich habe mir eine Z-Klasse als Unterklasse von einer anderen Z-Klasse erstellt, die wiederum als Oberklasse die CL_ICL_GRID_BASE hat, da ich bereits Funktionen der ersten Z-Klasse bei mir nutzen möchte.
Nun erstelle ich mir hiermit mein ALV-Grid.
Code: Alles auswählen.
data: gr_segment_alv TYPE REF TO zcl_segment_alv.
IF gr_segment_alv IS NOT BOUND.
CREATE OBJECT gr_segment_alv
EXPORTING
iv_colorfname = 'ROWCOLOR'
iv_selectfname = 'DETAIL_SELECT'
iv_stylefname = 'CELLSTYLE'.
gr_segment_alv->create_grid( EXPORTING iv_container_name = 'Z_SEGMENT_ALV'
iv_initial_lines = 0
iv_struc_name = 'Z_S_SEGMENT_ALV'
iv_xappl_events = space
).
ENDIF.
Wenn ich einen Breakpoint in der von der Masterklasse (CL_ICL_GRID_BASE) geerbten Methode HANDLE_USER_COMMAND setze, wird diese gar nicht durchlaufen.
Code: Alles auswählen.
METHOD handle_user_command .
CASE e_ucomm.
WHEN mc_fc_item_check.
* Trigger PAI, unless we have system events anyway
IF mv_xappl_events EQ space.
CALL METHOD cl_gui_cfw=>set_new_ok_code
EXPORTING
new_code = mc_dummy_okcode.
ENDIF.
WHEN mc_fc_new_line.
CALL METHOD add_initial_line.
WHEN mc_fc_del_line.
CALL METHOD delete_line.
WHEN OTHERS.
ENDCASE.
ENDMETHOD.
Stehe voll auf dem Schlauch, da ich den Prozess halt auch nicht debuggt bekomme. Wenn ich die Buttons drücke, wird im Frontend die Änderung vollzogen aber der Debugger springt nicht an.
Ich bedanke mich voraus, für Eure Tipps!
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ich glaube, du hast da einen "Fehler" aus deiner ersten Z-Klasse geerbt.
Die Standardfunktionen für "Hinzufügen" und "Entfernen" werden vom Grid nicht direkt weitergegeben, weil die Operationen direkt auf der Tabelle, die man bei SET_TABLE_FOR_FIRST_DISPLAY als CHANGING-Parameter übergeben hat, erfolgen. Das heißt, man muss da eigentlich nichts mehr großartig nacharbeiten. Für den Fall, dass man in der neuen Zeile Ergänzungen oder bei bestehenden Zeilen Korrekturen vornehmen muss, bietet das Grid die DATA_CHANGED-Ereignisse an.
Der Fehler besteht meiner Meinung nach nun darin, dass in der ersten Z-Klasse mit einer lokalen(?) Variable gearbeitet wird, deren Änderung (durch das ALV-Grid) nicht an den Aufrufer durchgereicht wird. Du musst also vermutlich in der ersten Z-Klasse eine Möglichkeit vorsehen, dass die Tabelle die im Grid angezeigt wird mit der Tabelle die an die Z-Klasse übergeben wird abgeglichen wird.
Ich habe mir so ein ähnliches Konstrukt auch schon gebaut, um die ganzen Spezialfunktionen des Grids, die zusätzliche Spalten in der Ausgabetabelle benötigen, abbilden zu können indem zur Laufzeit dynamisch eine interne Tabelle mit den benötigten Spalten erstellt wird. Der Transport der Inhalte zwischen der Ausgabetabelle und dieser eigenen "Anzeigetabelle" erfolgt im Rahmen der DATA_CHANGED-Ereignisse.
Die Standardfunktionen für "Hinzufügen" und "Entfernen" werden vom Grid nicht direkt weitergegeben, weil die Operationen direkt auf der Tabelle, die man bei SET_TABLE_FOR_FIRST_DISPLAY als CHANGING-Parameter übergeben hat, erfolgen. Das heißt, man muss da eigentlich nichts mehr großartig nacharbeiten. Für den Fall, dass man in der neuen Zeile Ergänzungen oder bei bestehenden Zeilen Korrekturen vornehmen muss, bietet das Grid die DATA_CHANGED-Ereignisse an.
Der Fehler besteht meiner Meinung nach nun darin, dass in der ersten Z-Klasse mit einer lokalen(?) Variable gearbeitet wird, deren Änderung (durch das ALV-Grid) nicht an den Aufrufer durchgereicht wird. Du musst also vermutlich in der ersten Z-Klasse eine Möglichkeit vorsehen, dass die Tabelle die im Grid angezeigt wird mit der Tabelle die an die Z-Klasse übergeben wird abgeglichen wird.
Ich habe mir so ein ähnliches Konstrukt auch schon gebaut, um die ganzen Spezialfunktionen des Grids, die zusätzliche Spalten in der Ausgabetabelle benötigen, abbilden zu können indem zur Laufzeit dynamisch eine interne Tabelle mit den benötigten Spalten erstellt wird. Der Transport der Inhalte zwischen der Ausgabetabelle und dieser eigenen "Anzeigetabelle" erfolgt im Rahmen der DATA_CHANGED-Ereignisse.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
19KnarfRed81
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 19KnarfRed81 (ForumUser / 19 / 10 /
3
)
»
Hallo ADT,
danke für den Tipp. Allerdings verstehe ich es noch nicht so ganz... :-|
danke für den Tipp. Allerdings verstehe ich es noch nicht so ganz... :-|
Ich übergebe doch letztendlich nur eine Struktur an die Methode CREATE_GRID welche 1:1 aus der Oberklasse stammt. Daraus wird dann ein protected Klassenattribut MR_ITEM für STFFD. Die Daten werden dann im PBO der geerbten Z-Klasse befüllt. Ich möchte jetzt in meiner 2. Z-Klasse einfach mit diesen Daten arbeiten und halt Änderungen vornehmen.Der Fehler besteht meiner Meinung nach nun darin, dass in der ersten Z-Klasse mit einer lokalen(?) Variable gearbeitet wird, deren Änderung (durch das ALV-Grid) nicht an den Aufrufer durchgereicht wird
Hast du da ein Beispiel oder kannst das noch etwas näher erläutern? Danke.Du musst also vermutlich in der ersten Z-Klasse eine Möglichkeit vorsehen, dass die Tabelle die im Grid angezeigt wird mit der Tabelle die an die Z-Klasse übergeben wird abgeglichen wird.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ja, aber irgendwann willst du Daten ja zurückgeliefert bekommen oder nicht? Und dafür benötigt das ALV Grid (Base) einen Ort wo es die Daten zurückspeichern kann.19KnarfRed81 hat geschrieben: ↑09.02.2023 09:36Ich übergebe doch letztendlich nur eine Struktur an die Methode CREATE_GRID welche 1:1 aus der Oberklasse stammt. Daraus wird dann ein protected Klassenattribut MR_ITEM für STFFD. Die Daten werden dann im PBO der geerbten Z-Klasse befüllt. Ich möchte jetzt in meiner 2. Z-Klasse einfach mit diesen Daten arbeiten und halt Änderungen vornehmen.Der Fehler besteht meiner Meinung nach nun darin, dass in der ersten Z-Klasse mit einer lokalen(?) Variable gearbeitet wird, deren Änderung (durch das ALV-Grid) nicht an den Aufrufer durchgereicht wird
Nachdem du ein protected Attribut erwähnt hast, dürfte das dein "zentraler" Datenspeicher sein. Du musst also schauen, warum da die Daten nicht sauber gespeichert werden.19KnarfRed81 hat geschrieben: ↑09.02.2023 09:36Hast du da ein Beispiel oder kannst das noch etwas näher erläutern? Danke.Du musst also vermutlich in der ersten Z-Klasse eine Möglichkeit vorsehen, dass die Tabelle die im Grid angezeigt wird mit der Tabelle die an die Z-Klasse übergeben wird abgeglichen wird.
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
DATA_CHANGED ist doch zur reinen Prüfbehandlung(!) von direkten(!) Eingaben (editierbares ALV) da und nicht für externe Datenübernahmen. Nach der Prüfbehandlung kann man im DATA_CHANGED_FINISHED das ALV samt Daten manipulieren.a-dead-trousers hat geschrieben: ↑09.02.2023 07:31Für den Fall, dass man in der neuen Zeile Ergänzungen oder bei bestehenden Zeilen Korrekturen vornehmen muss, bietet das Grid die DATA_CHANGED-Ereignisse an.
Wann sonst sollte DATA_CHANGED triggern? Was wäre der Vorteil eines eigenen Triggers von DATA_CHANGED (bei Nicht-Direkteingabe) ggü. einer separaten Methode und ALV-Refreshs?
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
DATA_CHANGED triggert automatisch VOR DATA_CHANGED_FINISHED.tar hat geschrieben: ↑07.10.2024 22:44DATA_CHANGED ist doch zur reinen Prüfbehandlung(!) von direkten(!) Eingaben (editierbares ALV) da und nicht für externe Datenübernahmen. Nach der Prüfbehandlung kann man im DATA_CHANGED_FINISHED das ALV samt Daten manipulieren.a-dead-trousers hat geschrieben: ↑09.02.2023 07:31Für den Fall, dass man in der neuen Zeile Ergänzungen oder bei bestehenden Zeilen Korrekturen vornehmen muss, bietet das Grid die DATA_CHANGED-Ereignisse an.
Wann sonst sollte DATA_CHANGED triggern? Was wäre der Vorteil eines eigenen Triggers von DATA_CHANGED (bei Nicht-Direkteingabe) ggü. einer separaten Methode und ALV-Refreshs?
Es ging mir darum, dass man über diese Ereignis direkt den aktuellen Arbeitsbereich des ALVs manipulieren kann, noch BEVOR die Daten in der Ergebnistabelle landen. Quasi on-the-fly Daten ergänzen, die dann zusätzlich noch durch die Standard ALV-Prüfungen durchlaufen.
Zum Beispiel: Ein Benutzer gibt einen Schlüssel ein, zu dem er eigentlich keine Berechtigung hat, trotzdem wird der beschreibende Text (durch DATA_CHANGED) ergänzt, damit die nachfolgende Fehlermeldung aussagekräftiger wird, weil der beschreibende Text in der ALV-Ausgabe nun auch drinnensteht.
Vergleichbar wäre das Ganze mit DYNP_VALUES_UPDATE wo man in einer F4-Verarbeitung auch noch andere Felder am Dynrpo mitändern kann.
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
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
5076
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®
5
Antw.
Antw.
4301
Views
Views
ALV GRID: Erneutes Lesen der veränderten Daten von der Datenbank und Refresh des ALV GRID
von Steffen » 24.04.2020 14:02 • Verfasst in ABAP® für Anfänger
von Steffen » 24.04.2020 14:02 • Verfasst in ABAP® für Anfänger
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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.