Die letzte Änderung eines Feldes von alv wurde nicht gemerkt
15 Beiträge
•
Seite 1 von 1
15 Beiträge
Seite 1 von 1
Hallo zusammen,
Ich habe eine alv Liste und die Liste ist editierbar. Auf einer Zeile möchte ich mehrere Felder ändern. Ich habe die Ereignisse benutzt, nämlich cl_gui_alv_grid=>mc_evt_modified und cl_gui_alv_grid=>mc_evt_enter und data_changed OF cl_gui_alv_grid für die Änderung. ZB: ich möchte das Feld A ändern und beim Debugger habe ich gesehen, dass das Änderung-Ereignis wird nur ausgelöst, wenn nach der Cursor zum anderen Feld gesprungen wurde. Dh, bei der letzte Änderung, solange wenn die Cursor nicht zu einem anderen Feld gesprungen wurde, wurde das Ereignis nicht ausgelöst, so dass die letzte Änderung nicht geändert werden konnte. Wie kann man das Problem lösen? Ich habe wirklich keine Idee mehr.
Vielen Dank für jede Hilfe.
cuncon
Ich habe eine alv Liste und die Liste ist editierbar. Auf einer Zeile möchte ich mehrere Felder ändern. Ich habe die Ereignisse benutzt, nämlich cl_gui_alv_grid=>mc_evt_modified und cl_gui_alv_grid=>mc_evt_enter und data_changed OF cl_gui_alv_grid für die Änderung. ZB: ich möchte das Feld A ändern und beim Debugger habe ich gesehen, dass das Änderung-Ereignis wird nur ausgelöst, wenn nach der Cursor zum anderen Feld gesprungen wurde. Dh, bei der letzte Änderung, solange wenn die Cursor nicht zu einem anderen Feld gesprungen wurde, wurde das Ereignis nicht ausgelöst, so dass die letzte Änderung nicht geändert werden konnte. Wie kann man das Problem lösen? Ich habe wirklich keine Idee mehr.
Vielen Dank für jede Hilfe.
cuncon
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 / 4414 / 224 /
1186
)
»
Ich nehme mal an, dein Problem bezieht sich darauf, dass dann im Anschluss bei einem PAI/PBO-Ereignis die Daten nicht zur Verfügung stehen, oder?
Den Feldtransport vom ALV-Grid kann man auch mit der Methode CHECK_CHANGED_DATA manuell anstoßen.
Den Feldtransport vom ALV-Grid kann man auch mit der Methode CHECK_CHANGED_DATA manuell anstoßen.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
cuncon
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
Hallo a-dead-trousers,a-dead-trousers hat geschrieben:Ich nehme mal an, dein Problem bezieht sich darauf, dass dann im Anschluss bei einem PAI/PBO-Ereignis die Daten nicht zur Verfügung stehen, oder?
Den Feldtransport vom ALV-Grid kann man auch mit der Methode CHECK_CHANGED_DATA manuell anstoßen.
Sorry, ich muss etwas korrigieren. Eigentlich ist es, ob ich mehrere Änderungen oder nur eine Änderung gemacht habe. Angenommen, ich habe nur ein Feld geändert und solange, wenn ich kein Enter gedrückt habe oder die Cursor in anderem Feld gesetzt habe, dann wird überhaupt kein Ereignis ausgelöst für die Änderung. Dh, in der Tabelle MT_GOOD_CELLS von der Klasse cl_alv_changed_data_protocol ist leer. Daher konnte die geänderte Daten von dem Feld nicht abfangen. Die alv haben dann die alte Daten. Dann wie kann man den Feldtransport vom ALV-Grid auch mit der Methode CHECK_CHANGED_DATA manuell anstoßen, wenn ich die geänderte Daten nicht abfangen konnte? Oder war das ein Denkfehler von mir?
Danke.
cuncon
Beitrag
von a-dead-trousers (Top Expert / 4414 / 224 /
1186
)
»
Ok, die Frage die sich mir stellt, ist, wofür brauchst du die geänderten Daten, wenn du dich mit dem Cursor noch in dem Feld befindest?
Wie du schon bemerkt hast, kann man einen Event registrieren, der beim Verlassen des Feldes (nach einer Änderung) ausgelöst wird oder erst wenn man Enter drückt (und etwas geändert hat).
Die beiden Events machen insofern Sinn, als dass man entweder sofort beim Wechsel auf ein anderes Feld schon auf die (validierten) Daten des zuvor geänderten Feldes zugreifen kann, oder wenn man mehrere Felder gleichzeitig (nach Enter) prüfen möchte. Daher denke ich eher, du hast da einen Denkfehler in deiner Applikation, denn ich sehe keinen Sinn, warum man die geänderten Daten sofort während des Änderns schon prüfen sollte (in einer Applikation die mit "Buchungen" arbeitet, die SAP ja ist)
Ich habe mir bei meiner ursprünglichen Antwort gedacht, du meinst, dass vielleicht, wenn man bei der letzten Änderung eines Feldes sofort auf einen Speichern-Knopf drückt der PAI/PBO auslöst, die Events nicht ordnungsgemäß ausgelöst werden und daher deine Feldprüfungen nicht durchlaufen werden. Das editierbare ALV Grid ist in diesem Bereich meines Erachtens nicht sehr ausgereift und kann unter Umständen auch mal etwas unerwartet reagieren. Daher die Erwähnung der Methode CHECK_CHANGED_DATA. Aber inzwischen glaube ich, dass das nicht dein Problem ist.
lg ADT
Wie du schon bemerkt hast, kann man einen Event registrieren, der beim Verlassen des Feldes (nach einer Änderung) ausgelöst wird oder erst wenn man Enter drückt (und etwas geändert hat).
Die beiden Events machen insofern Sinn, als dass man entweder sofort beim Wechsel auf ein anderes Feld schon auf die (validierten) Daten des zuvor geänderten Feldes zugreifen kann, oder wenn man mehrere Felder gleichzeitig (nach Enter) prüfen möchte. Daher denke ich eher, du hast da einen Denkfehler in deiner Applikation, denn ich sehe keinen Sinn, warum man die geänderten Daten sofort während des Änderns schon prüfen sollte (in einer Applikation die mit "Buchungen" arbeitet, die SAP ja ist)
Ich habe mir bei meiner ursprünglichen Antwort gedacht, du meinst, dass vielleicht, wenn man bei der letzten Änderung eines Feldes sofort auf einen Speichern-Knopf drückt der PAI/PBO auslöst, die Events nicht ordnungsgemäß ausgelöst werden und daher deine Feldprüfungen nicht durchlaufen werden. Das editierbare ALV Grid ist in diesem Bereich meines Erachtens nicht sehr ausgereift und kann unter Umständen auch mal etwas unerwartet reagieren. Daher die Erwähnung der Methode CHECK_CHANGED_DATA. Aber inzwischen glaube ich, dass das nicht dein Problem ist.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
cuncon
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
a-dead-trousers hat geschrieben:vielen Dank für deine Antwort. Ich habe die Methode CHECK_CHANGED_DATA aufgerufen, nachdem man ein Feld geändert hat UND das Feld NICHT verlassen hat oder KEIN ENTER gedückt hat, dann habe ich bei Debugger gesehen, dass der Flag für die Änderung gesetzt wurde, dh es gab Änderung, aber die Tabelle MT_GOOD_CELLS war leer, so dass man die Änderung nicht holen konnte und
vielen Dank für deine Antwort. Ich habe die Methode CHECK_CHANGED_DATA für die Abfrage auch verwendet, ob es Änderung gibt oder nicht, aber habe Feldtransport vom ALV nicht gemacht, weil ich nicht weiß genau, wie man das macht.a-dead-trousers hat geschrieben:Ok, die Frage die sich mir stellt, ist, wofür brauchst du die geänderten Daten, wenn du dich mit dem Cursor noch in dem Feld befindest?
Wie du schon bemerkt hast, kann man einen Event registrieren, der beim Verlassen des Feldes (nach einer Änderung) ausgelöst wird oder erst wenn man Enter drückt (und etwas geändert hat).
Die beiden Events machen insofern Sinn, als dass man entweder sofort beim Wechsel auf ein anderes Feld schon auf die (validierten) Daten des zuvor geänderten Feldes zugreifen kann, oder wenn man mehrere Felder gleichzeitig (nach Enter) prüfen möchte. Daher denke ich eher, du hast da einen Denkfehler in deiner Applikation, denn ich sehe keinen Sinn, warum man die geänderten Daten sofort während des Änderns schon prüfen sollte (in einer Applikation die mit "Buchungen" arbeitet, die SAP ja ist)
Ich habe mir bei meiner ursprünglichen Antwort gedacht, du meinst, dass vielleicht, wenn man bei der letzten Änderung eines Feldes sofort auf einen Speichern-Knopf drückt der PAI/PBO auslöst, die Events nicht ordnungsgemäß ausgelöst werden und daher deine Feldprüfungen nicht durchlaufen werden. Das editierbare ALV Grid ist in diesem Bereich meines Erachtens nicht sehr ausgereift und kann unter Umständen auch mal etwas unerwartet reagieren. Daher die Erwähnung der Methode CHECK_CHANGED_DATA. Aber inzwischen glaube ich, dass das nicht dein Problem ist.
lg ADT
Ich glaube mit dem Bild kann ich mein Problem besser beschreiben. Auf dem Bild sieht man die weiße Felder, bei den man die Werte ändern kann. Zum Beispiel ich möchte bei dem Feld Posnr ändern, statt 3 schreibe ich 4 und drücke auf den Button 'Übernehmen', dh, ich habe kein ENTER gedrückt und nicht zu einem anderen Feld gesprungen, dann habe ich bei Debugger gesehen, dass die Tabelle MT_GOOD_CELLS von der Klasse cl_alv_changed_data_protocol LEER war, obwohl der Flag von der Methode CHECK_CHANGED_DATA auf 'X' gesetzt wurde, das bedeutet, dass das System gemerkt hat, es gibt Änderung, aber die geänderte Daten wurde leider nicht gespeichert und auf der alv List standen nur die alten Daten nach der Änderung, weil ich KEIN ENTER gedrückt oder zu einem anderen Feld gesprungen habe, sondern direkt auf dem Button 'Übernehmen' gedrückt habe. Es kann solchen Fall passieren. Der Benutzer kann nicht immer an ENTER-Drücken oder die Cursor auf einem anderen Feld extra klicken muss, damit die Änderung abgespeichert werden muss. Das ist auch Benutzerunfreundlich. Aber ich glaube es muss eine Lösung dafür geben, aber welche ich bin im Moment überfragt
. Hast du oder hat jemand eine Idee ?Vielen Dank für Eure Hilfe
cuncon
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Hallo cuncon,
ich habe es folgendermaßen realisiert:
Zuerst eine Methode, die auf das Event DATA_CHANGED der Klasse CL_GUI_ALV_GRID reagiert. Die hat als Importparameter
ER_DATA_CHANGED
E_ONF4
E_ONF4_BEFORE
E_ONF4_AFTER
E_UCOMM
Die neuen/ gelöschten/ geänderten Zellen stehen dann in:
Hast du das Event am ALV Objekt registriert?
Grüße 4Byte
ich habe es folgendermaßen realisiert:
Zuerst eine Methode, die auf das Event DATA_CHANGED der Klasse CL_GUI_ALV_GRID reagiert. Die hat als Importparameter
ER_DATA_CHANGED
E_ONF4
E_ONF4_BEFORE
E_ONF4_AFTER
E_UCOMM
Die neuen/ gelöschten/ geänderten Zellen stehen dann in:
Code: Alles auswählen.
er_data_changed->mt_inserted_rows
er_data_changed->mt_mod_cells
er_data_changed->mt_deleted_rowsGrüße 4Byte
Es gibt 10 Menschen die binär verstehen 
Ja, ich habe die Methode geschrieben, die auf der Klasse CL_GUI_ALV_GRID reagiert. Die Änderung wurde auch gemacht, aber nur wenn ich entweder auf ENTER gedrückt habe oder das geänderte Feld verlassen und zum anderen Feld springen und dann auf den Button 'Übernehmen' drücken. Dann steht auf der ALV List die geänderten Daten. Aber wenn ich ein Feld geändert habe und ohne ENTER gedrückt, sondern direkt auf den Button 'Übernehmen' drücke, dann wurde Ereignis für die Änderung nicht ausgelöst, sondern nur PAI ausgelöst wegen Drücken des Buttons 'Übernehmen'. Nach der alv refresh sehe ich die alte Daten von vor der Änderung, also die Änderung wurde nicht gemacht. Aber mein Ziel ist, wenn der Benutzer ein Feld geändert habe und muss nicht auf ENTER drücken, sondern nur auf den Button 'Übernehmen' drücken, soll aber die Änderung erfolgt werden.4byte hat geschrieben:Hallo cuncon,
ich habe es folgendermaßen realisiert:
Zuerst eine Methode, die auf das Event DATA_CHANGED der Klasse CL_GUI_ALV_GRID reagiert. Die hat als Importparameter
ER_DATA_CHANGED
E_ONF4
E_ONF4_BEFORE
E_ONF4_AFTER
E_UCOMM
Die neuen/ gelöschten/ geänderten Zellen stehen dann in:Code: Alles auswählen.
er_data_changed->mt_inserted_rows er_data_changed->mt_mod_cells er_data_changed->mt_deleted_rows
Hast du das Event am ALV Objekt registriert?
Grüße 4Byte
Unten ist mein coding:
Code: Alles auswählen.
CLASS: lcl_handler DEFINITION.
PUBLIC SECTION.
METHODS: on_data_changed_310 FOR EVENT data_changed OF cl_gui_alv_grid
IMPORTING er_data_changed.
ENDCLASS.
CLASS: lcl_handler IMPLEMENTATION.
METHOD on_data_changed_310.
PERFORM data_changed_310 USING er_data_changed.
ENDMETHOD.
ENDCLASS.
FORM data_changed_310 USING p_data_changed TYPE REF TO
cl_alv_changed_data_protocol.
...
...
LOOP AT p_data_changed->mt_good_cells INTO ls_good.
...
ENDLOOP.
ENDFORM.
MODULE create_and_transfer_0310 OUTPUT.
...
...
CREATE OBJECT g_handler.
CALL METHOD go_alv_grid_310->register_edit_event
EXPORTING
i_event_id = cl_gui_alv_grid=>mc_evt_modified."mc_evt_enter.
CALL METHOD go_alv_grid_310->register_edit_event
EXPORTING
i_event_id = cl_gui_alv_grid=>mc_evt_enter.
SET HANDLER g_handler->on_data_changed_310 FOR go_alv_grid_310.
CALL METHOD go_alv_grid_310->set_table_for_first_Display
...
ENDMODULE.
Hallo cuncon,
damit das Event getriggert wird, musst du ein ALV Event auslösen. Mein Lösungsvorschlag wäre die ALV Toolbar einzublenden und einen eigenen Button hinzuzufügen, der dann Übernehmen heißt
Oder man erzwingt das ALV Event irgendwie wenn man den Button auf deinem Dynpro klickt.
Grüße 4Byte
damit das Event getriggert wird, musst du ein ALV Event auslösen. Mein Lösungsvorschlag wäre die ALV Toolbar einzublenden und einen eigenen Button hinzuzufügen, der dann Übernehmen heißt
Oder man erzwingt das ALV Event irgendwie wenn man den Button auf deinem Dynpro klickt.
Grüße 4Byte
Es gibt 10 Menschen die binär verstehen
Man könnte beim schließen des PopUps auch die Übernahme der ALV-Änderungen triggern:4byte hat geschrieben:Oder man erzwingt das ALV Event irgendwie wenn man den Button auf deinem Dynpro klickt.
CL_GUI_ALV_GRID->CHECK_CHANGED_DATA()
Über den Rückgabewert p_valid weiß man ob die Datenänderung im ALV verarbeitet werden kann oder ob der User nochmal ran muss (PAI verlassen, PopUp muss offen bleiben!)
Gruß Hendrik
Obwohl der Beitrag schon etwas älter ist, schreibe ich hier mal meinen Senf dazu, da ich ein sehr ähnliches Problem hatte und über die Suche auf diesen Thread gestoßen bin. Wie ich mich kenne, werde ich in ein paar Monaten wieder der sein, der so ein Problem hat und dann finde ich hier wieder meine Lösung 😉
Problem: Mein editierbarer ALV funktionierte soweit so gut, auch Änderung in einem Feld und gleich Speichern drücken ohne aus dem Feld zu navigieren ging, da ich CL_GUI_ALV_GRID->CHECK_CHANGED_DATA() aufgerufen habe und damit das ON_DATA_CHANGED Event ausgelöst und meine Methode durchlaufen wurde (wie oben im Thread erwähnt).
Was aber nicht ging, war auf einen Button im ALV zu drücken, der im ON_BUTTON_CLICK Event einige Werte veränderte, CL_GUI_ALV_GRID->CHECK_CHANGED_DATA() aufzurufen und dann zu speichern. Die geänderten Werte wurden korrekt im ALV angezeigt, aber beim Speichern (da wird auch nochmal CL_GUI_ALV_GRID->CHECK_CHANGED_DATA() aufgerufen) war der ALV der Meinung, es hätte sich nichts geändert.
ON_DATA_CHANGED wurde beim "Aufruf" aus ON_BUTTON_CLICK und beim Speichern nicht durchlaufen. Um den ALV auf den Trichter zu bringen, dass sich doch was geändert hat, habe ich versucht mit
den Durchlauf von ON_DATA_CHANGED zu erreichen, was auch geklappt hat, allerdings mit leeren Attributen (er_data_changed->mt_good_cells, ...), so dass das für mich auch nicht funktionierte.
Letztendliche Lösung ist nun, dem ALV die Änderungen über CL_GUI_ALV_GRID->SET_DELTA_CELLS mitzuteilen:
ON_DATA_CHANGED wird dann beim Aufruf von CHECK_CHANGED_DATA() durchlaufen, diesmal mit den entsprechenden Werten in den Attributen.
Vielleicht hilft es ja dem Ein oder der Anderen, auf der Suche nach einer Lösung zu diesem Problem.
Problem: Mein editierbarer ALV funktionierte soweit so gut, auch Änderung in einem Feld und gleich Speichern drücken ohne aus dem Feld zu navigieren ging, da ich CL_GUI_ALV_GRID->CHECK_CHANGED_DATA() aufgerufen habe und damit das ON_DATA_CHANGED Event ausgelöst und meine Methode durchlaufen wurde (wie oben im Thread erwähnt).
Was aber nicht ging, war auf einen Button im ALV zu drücken, der im ON_BUTTON_CLICK Event einige Werte veränderte, CL_GUI_ALV_GRID->CHECK_CHANGED_DATA() aufzurufen und dann zu speichern. Die geänderten Werte wurden korrekt im ALV angezeigt, aber beim Speichern (da wird auch nochmal CL_GUI_ALV_GRID->CHECK_CHANGED_DATA() aufgerufen) war der ALV der Meinung, es hätte sich nichts geändert.
ON_DATA_CHANGED wurde beim "Aufruf" aus ON_BUTTON_CLICK und beim Speichern nicht durchlaufen. Um den ALV auf den Trichter zu bringen, dass sich doch was geändert hat, habe ich versucht mit
Code: Alles auswählen.
CL_GUI_ALV_GRID->IF_CACHED_PROP~set_prop( propname = 'GridModified' propvalue = '1' ) Letztendliche Lösung ist nun, dem ALV die Änderungen über CL_GUI_ALV_GRID->SET_DELTA_CELLS mitzuteilen:
Code: Alles auswählen.
DATA(lt_delta_cells) = VALUE lvc_t_modi(
( fieldname = 'FELD1'
row_id = es_row_no-row_id
value = 'WERT1'
tabix = 1 )
( fieldname = 'STATUS_GESAMT'
row_id = es_row_no-row_id
value = gc_stat_rueckfrage
tabix = 1 ) ).
go_alv_grid->set_delta_cells(
EXPORTING
it_delta_cells = lt_delta_cells
i_modified = abap_true ).
Vielleicht hilft es ja dem Ein oder der Anderen, auf der Suche nach einer Lösung zu diesem Problem.
Folgende Benutzer bedankten sich beim Autor Murdock für den Beitrag (Insgesamt 2):
ewx • a-dead-trousers
du hättest dir doch einfach einen eigenen "Merker" setzen können, wenn die Funktion ON_BUTTON_CLICK aufgerufen wurde?
Ja klar, hätte ich, aber davon wäre on_data_changed (wo ich so einiges mache) auch nicht durchlaufen worden. Ich hätte mir also wieder extra merken müssen, was geändert wurde und evtl. auch wieder darauf extra reagieren,... etc.
So wie es jetzt ist, läuft es nun genauso wie erwartet und gewünscht (auch wenn mich das ein paar Stunden im Debugger und drumherum gekostet hat 😉 ).
Ich fand (und finde) es schon echt seltsam, dass der ALV die Änderung im ON_BUTTON_CLICK nicht richtig mitkriegt.
Danke für deine Rückmeldung!
Mal gucken, ob ich Zeit finde, das mal auszuprobieren...
Ich denke, da kann man sich drüber streiten, denn bei button_click müssen ja nicht unbedingt Datenänderungen gemacht werden. Von daher wäre für mich logisch - oder zumindest nachvollziehbar - dass das data_Changed Event nicht reagiert. ansonsten könnte man data_changed auch selbst aufrufen, muss aber die Parameter natürlich selber füllen. Von daher ist der Aufruf von SET_DELTA_CELLS eine gute Lösung.
Mal gucken, ob ich Zeit finde, das mal auszuprobieren...
Das stimmt, im button_click müssen nicht unbedingt Änderungen gemacht werden und daher braucht der data_changed auch erstmal nicht zu reagieren. Wenn ich nun aber im button_click Änderungen an der Ausgabetabelle mache (die durch ...refresh auch angezeigt werden) und dann explizit mittels check_changed_data() sage "guck doch mal ob sich was geändert hat und reagiere bitte darauf wie sonst auch", erwarte ich schon, dass der ALV bemerkt dass etwas geändert wurde und dann den data_changed auslöst.
check_data_changed guckt ja nicht auf Änderungen der Tabelle, sondern nur, ob durch die direkte Eingabe etwas geändert wurde.
Seite 1 von 1
Vergleichbare Themen
3
Antw.
Antw.
5482
Views
Views
2
Antw.
Antw.
1669
Views
Views
Wie letzte Auftragsfertigungsnummer abfangen???
von spooky » 25.06.2008 19:35 • Verfasst in ABAP® für Anfänger
von spooky » 25.06.2008 19:35 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 5 Tagen von a-dead-trousers 5 / 2181
vor 5 Tagen von a-dead-trousers 5 / 2181
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
CL_GUI_ALV_GRID - Zeilen auf Read-Only / Editierbar schalten
vor 5 Tagen von a-dead-trousers 5 / 2181
vor 5 Tagen von a-dead-trousers 5 / 2181