Problem mit CL_GUI_ALV_GRID Event data_changed
12 Beiträge
•
Seite 1 von 1
12 Beiträge
Seite 1 von 1
Beitrag
von Herr Müller (ForumUser / 5 / 0 /
0
)
»
Hallo zusammen,
ich habe da ein Problem mit einem ALV und seinem Event Data_Changed. Dieses Problem besteht an zwei Stellen meiner Anwendung:
Fall 1:Ich habe in einem modalen Dynpro ein ALV instanziert und eine Handler Methode für das Ereignis angelegt. Das Event habe ich mit der Modified-Konstante registriert, so dass nach jeder Eingabe das Event gefeuert werden sollte. Dem ist in 90% der Fälle auch so, sodass meine Methode prozessiert wird.
Dieses ALV hat eine editierbare Spalte, die dann von oben nach unten ausgefüllt werden kann: Eingabe -> Tab drücken -> Eingabe -> Tab drücken ...
Wenn die letzte Zelle erreicht wird, und dann der ALV per drücken der Tabulator-Taste verlassen wird, wird das Ereignis nicht ausgelöst. Da das modale Fenster über einen OK-Code verlassen wird, habe ich kurzerhand die Methode, check_changed_data aufgerufen. Dann wird der Handler aufgerufen und evtl. Eingabefehler ausgegeben.
Fall 2:
Ich verwende in einem dynamisch aufgebauten Splitting Container n Instanzen der ALV-Klasse. Diese ALVs besitzen wieder eine editierbare Spalte, die von oben nach unten per Tabulator gefüllt werden. Wurde die letzte Zelle bearbeitet und dann die Tabulator-Taste gedrückt wird wieder kein Event ausgelöst. Da aber jetzt kein OK-Code ausgelöst wird, sondern nur der Cursor in das nächste eingabebereite Feld gesetzt wird, z.B. erstes Feld zweiter ALV, habe ich keine Möglichkeit die o.g. Methode auszuführen und somit die Überprüfung des ALVs zu erzwingen.
Grundsätzlich: Seltsamerweise wird das Event auch nicht, wie man es erwarten würde, nach einer Eingabe, oder nachdem die Zelle den Fokus verloren hat, gerufen, sondern, wenn eine andere Zelle des selben ALVs den Fokus erhält. D.h. wenn man die letzte Zelle editiert und dann auf eine andere Zelle des ALVs klickt oder SHIFT-TAB drückt, wird das Ereignis ausgelöst.
Hat hier vielleicht jemand eine Idee, wie ein Workaround aussehen könnte? Auf Wunsch kann ich auch Code Ausschnitte liefern...
Vielen Dank im Voraus!
Herr Müller
ich habe da ein Problem mit einem ALV und seinem Event Data_Changed. Dieses Problem besteht an zwei Stellen meiner Anwendung:
Fall 1:Ich habe in einem modalen Dynpro ein ALV instanziert und eine Handler Methode für das Ereignis angelegt. Das Event habe ich mit der Modified-Konstante registriert, so dass nach jeder Eingabe das Event gefeuert werden sollte. Dem ist in 90% der Fälle auch so, sodass meine Methode prozessiert wird.
Dieses ALV hat eine editierbare Spalte, die dann von oben nach unten ausgefüllt werden kann: Eingabe -> Tab drücken -> Eingabe -> Tab drücken ...
Wenn die letzte Zelle erreicht wird, und dann der ALV per drücken der Tabulator-Taste verlassen wird, wird das Ereignis nicht ausgelöst. Da das modale Fenster über einen OK-Code verlassen wird, habe ich kurzerhand die Methode, check_changed_data aufgerufen. Dann wird der Handler aufgerufen und evtl. Eingabefehler ausgegeben.
Fall 2:
Ich verwende in einem dynamisch aufgebauten Splitting Container n Instanzen der ALV-Klasse. Diese ALVs besitzen wieder eine editierbare Spalte, die von oben nach unten per Tabulator gefüllt werden. Wurde die letzte Zelle bearbeitet und dann die Tabulator-Taste gedrückt wird wieder kein Event ausgelöst. Da aber jetzt kein OK-Code ausgelöst wird, sondern nur der Cursor in das nächste eingabebereite Feld gesetzt wird, z.B. erstes Feld zweiter ALV, habe ich keine Möglichkeit die o.g. Methode auszuführen und somit die Überprüfung des ALVs zu erzwingen.
Grundsätzlich: Seltsamerweise wird das Event auch nicht, wie man es erwarten würde, nach einer Eingabe, oder nachdem die Zelle den Fokus verloren hat, gerufen, sondern, wenn eine andere Zelle des selben ALVs den Fokus erhält. D.h. wenn man die letzte Zelle editiert und dann auf eine andere Zelle des ALVs klickt oder SHIFT-TAB drückt, wird das Ereignis ausgelöst.
Hat hier vielleicht jemand eine Idee, wie ein Workaround aussehen könnte? Auf Wunsch kann ich auch Code Ausschnitte liefern...
Vielen Dank im Voraus!
Herr Müller
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Moin,
Eine Sychronisation zwischen Dynpro PAI/PBO und den Events von z.B. ALV-Grid kann man mit der Methode CL_GUI_CFW=>SET_NEW_OK_CODE herstellen.
gruß Jens
Eine Sychronisation zwischen Dynpro PAI/PBO und den Events von z.B. ALV-Grid kann man mit der Methode CL_GUI_CFW=>SET_NEW_OK_CODE herstellen.
gruß Jens
<:: XING-Gruppe Tricktresor::>
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Die deutsche Rechtschreibung ist Freeware, du darfst sie kostenlos nutzen –
Aber sie ist nicht Open Source, d. h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Welchen der EDIT-Events hast du regestriert?
Ich glaub der MC_EVT_MODIFIED ist derjenige den du brauchst.
CL_GUI_ALV_GRID=>REGISTER_EDIT_EVENT
Der wird meines Wissens immer beim VERLASSEN der Spalte ausgelöst, wenn sich etwas geändert hat.
Du könntest alternativ auch immer nach der EVENT-Verarbeitung im aktuellen Grid die check_changed_data der anderen Grids aufrufen.
(ACHTUNG: Du musst dann auch sicherstellen, dass die Grids sich nicht über die EVENTS gegenseitig rekursiv aufrufen)
Das könnte aber uU recht inperformat sein, kommt auch die Anzahl deiner Grids an.
lg ADT
Welchen der EDIT-Events hast du regestriert?
Ich glaub der MC_EVT_MODIFIED ist derjenige den du brauchst.
CL_GUI_ALV_GRID=>REGISTER_EDIT_EVENT
Der wird meines Wissens immer beim VERLASSEN der Spalte ausgelöst, wenn sich etwas geändert hat.
Du könntest alternativ auch immer nach der EVENT-Verarbeitung im aktuellen Grid die check_changed_data der anderen Grids aufrufen.
(ACHTUNG: Du musst dann auch sicherstellen, dass die Grids sich nicht über die EVENTS gegenseitig rekursiv aufrufen)
Das könnte aber uU recht inperformat sein, kommt auch die Anzahl deiner Grids an.
lg ADT
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 a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Das hat er IMHO eh schon gelöst (Punkt 1)Tron hat geschrieben:Eine Sychronisation zwischen Dynpro PAI/PBO und den Events von z.B. ALV-Grid kann man mit der Methode CL_GUI_CFW=>SET_NEW_OK_CODE herstellen.
Das größere Problem scheint der Fokuswechsel zwischen den Grids zu sein. In Grid A gibt es Änderungen und mit TAB wird auf Grid B gesprungen, dann scheint (laut Beschreibung) der Event von Grid A nicht ausgelöst zu werden.
lg ADT
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 Herr Müller (ForumUser / 5 / 0 /
0
)
»
Hallo zusammen,
vielen Dank für die prompten Antworten! Im Gegensatz zu den anderen Antworten in gewissen Herstellerforen, habt Ihr mein Problem verstanden!
Das hier ist das Coding für die Initialisierung des ALV aus dem ersten Fall (modales Fenster mit editierbaren Feldern):
Und noch die SUPER->Methode, der Vollständigkeit halber.
Die Symptomatik nochmal in Kurzform:
Fenster wird aufgerufen.
Erstes Feld wird gefüllt und mit TAB zum zweiten Feld gesprungen -> Event data_changed wird ausgelöst und Handler prozessiert, Even data_changed_finished wird ausgelöst und Handler prozessiert
zweites Feld wird gefüllt und mit Tab zum dritten Feld gesprungen -> s.o.
.
.
.
letztes Feld wird gefüllt mit TAB wird auf ein NON-ALV-Element gesprungen (z.B. OK-Button des modalen Modus oder in Fall 2 erstes Feld zweiter ALV)-> kein Ereignis, kein Handler...
Klick in irgendein Feld des gerade bearbeiteten ALVS ->Event data_changed wird ausgelöst und Handler prozessiert, Even data_changed_finished wird ausgelöst und Handler prozessiert
Beim Klick auf einen Button check_changed_data zu rufen, halte ich für einen Workaround, der seinen Zweck auch nicht richtig erfüllt, aber das liegt an der genauen Anforderung an das Popup in Fall 1, die tragen allerdings nichts technischen Problemstellung bei.
Vielleicht hilft das Coding weiter. Ich sehe wahrscheinlich den Wald vor lauter Bäumen nicht..
Gruß
Herr Müller
vielen Dank für die prompten Antworten! Im Gegensatz zu den anderen Antworten in gewissen Herstellerforen, habt Ihr mein Problem verstanden!
Das hier ist das Coding für die Initialisierung des ALV aus dem ersten Fall (modales Fenster mit editierbaren Feldern):
Code: Alles auswählen.
METHOD init_alv.
[...]
CALL METHOD super->init_alv
EXPORTING
io_container = io_container.
me->go_alv->set_table_for_first_display(
EXPORTING
* i_buffer_active =
* i_bypassing_buffer =
* i_consistency_check =
* i_structure_name =
* is_variant =
* i_save =
* i_default = 'X'
is_layout = ls_layout
* is_print =
* it_special_groups =
it_toolbar_excluding = me->gt_functions_excl
* it_hyperlink =
* it_alv_graphics =
* it_except_qinfo =
* ir_salv_adapter =
CHANGING
it_outtab = me->gt_outtab
it_fieldcatalog = me->gt_fcat
* it_sort =
* it_filter =
EXCEPTIONS
invalid_parameter_combination = 1
program_error = 2
too_many_lines = 3
OTHERS = 4
).
ls_f4-fieldname = 'TAXKM'.
ls_f4-register = 'X'.
ls_f4-getbefore = space.
ls_f4-chngeafter = space.
APPEND ls_f4 TO lt_f4.
me->go_alv->register_f4_for_fields( it_f4 = lt_f4 ).
me->go_alv->register_edit_event(
EXPORTING
i_event_id = cl_gui_alv_grid=>mc_evt_modified
EXCEPTIONS
error = 1
OTHERS = 2
).
CALL METHOD me->go_alv->set_ready_for_input
EXPORTING
i_ready_for_input = 1.
SET HANDLER me->on_change_finished FOR me->go_alv.Code: Alles auswählen.
METHOD init_alv.
CREATE OBJECT me->go_alv
EXPORTING
i_parent = io_container.
* Vor lauter Verzweiflung habe ich dann auch noch Enter registriert hat aber auf die TAB-Problematik keine Auswirkung gehabt...
me->go_alv->register_edit_event(
EXPORTING
i_event_id = cl_gui_alv_grid=>mc_evt_enter
EXCEPTIONS
error = 1
OTHERS = 2
).
SET HANDLER me->on_modified FOR me->go_alv. "data_changed
SET HANDLER me->on_f4 FOR me->go_alv.
ENDMETHOD.Fenster wird aufgerufen.
Erstes Feld wird gefüllt und mit TAB zum zweiten Feld gesprungen -> Event data_changed wird ausgelöst und Handler prozessiert, Even data_changed_finished wird ausgelöst und Handler prozessiert
zweites Feld wird gefüllt und mit Tab zum dritten Feld gesprungen -> s.o.
.
.
.
letztes Feld wird gefüllt mit TAB wird auf ein NON-ALV-Element gesprungen (z.B. OK-Button des modalen Modus oder in Fall 2 erstes Feld zweiter ALV)-> kein Ereignis, kein Handler...
Klick in irgendein Feld des gerade bearbeiteten ALVS ->Event data_changed wird ausgelöst und Handler prozessiert, Even data_changed_finished wird ausgelöst und Handler prozessiert
Beim Klick auf einen Button check_changed_data zu rufen, halte ich für einen Workaround, der seinen Zweck auch nicht richtig erfüllt, aber das liegt an der genauen Anforderung an das Popup in Fall 1, die tragen allerdings nichts technischen Problemstellung bei.
Vielleicht hilft das Coding weiter. Ich sehe wahrscheinlich den Wald vor lauter Bäumen nicht..
Gruß
Herr Müller
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
hi!
Auf den ersten Blick wirkt es wie ein Fehler im SAP Standard, entweder im Control am Frontend oder in ABAP am Backend.
Ich kenn hier jetzt aber auch nicht den technischen Hintergrund im ALV, ob es sich nicht doch um ein "gewünschtes" Verhalten handelt.
Eine mögliche Erklärung wäre, dass man die Events nur "innerhalb" des Controls welches diese wirft verarbeiten darf. Wenn man nun mit TAB auf ein anderes Control wechselt, könnte dessen Ablauflogik beeinflusst sein. (weil z.B. der Focus wieder zurückwechselt)
Wenn man sich die Release-Notes der SAPgui Versionen durchliest, findet man immer wieder Probleme die von ungewünschten Interaktionen zwischen Controls herrühren. Von da her hab ich die starke Vermutung, dass dies von SAP aus "Stabilitätsgründen" so gehandhabt wird.
Vielleicht blockt aber ja nur der DISPATCHER die Rückmeldung vom GUI-Control ab. Am Besten du setzt einen Break-Point in die DISPATCH-MEthode des ALV (Systemdebugging nicht vergessen) und gehst über die Aufruf-Hierarchie zum Auslösepunkt des Events (meist in CL_GUI_CFW). Dort wieder einen Break-Point setzten. Dann deinen Ablauf mit TAB und verlassen des ALV Grid testen und schauen ob der Debugger anspringt.
Wenn hier der Debugger anspringt, kann man den SAPgui als "Fehlerquelle" ausschließen. Dann muss man sich noch genauer anschauen aufgrund welcher Konstellation es nicht zum Auslösen des Events im ALV-Grid kommt.
Wenn der Debugger nicht anspringt wird der Event schon vom SAPgui oder dem OCX-Control abgeblockt. Dann könntest du nur noch versuchen den neuesten SAPgui zu installieren. Wenn das nicht hilft, kannst du es auch mit einer OSS versuchen. Dazu würde ich dann aber eine "abgespeckte" Version deines Programms erstellen, sodass die SAP den Fehler gleich erkennen kann.
lg ADT
Auf den ersten Blick wirkt es wie ein Fehler im SAP Standard, entweder im Control am Frontend oder in ABAP am Backend.
Ich kenn hier jetzt aber auch nicht den technischen Hintergrund im ALV, ob es sich nicht doch um ein "gewünschtes" Verhalten handelt.
Eine mögliche Erklärung wäre, dass man die Events nur "innerhalb" des Controls welches diese wirft verarbeiten darf. Wenn man nun mit TAB auf ein anderes Control wechselt, könnte dessen Ablauflogik beeinflusst sein. (weil z.B. der Focus wieder zurückwechselt)
Wenn man sich die Release-Notes der SAPgui Versionen durchliest, findet man immer wieder Probleme die von ungewünschten Interaktionen zwischen Controls herrühren. Von da her hab ich die starke Vermutung, dass dies von SAP aus "Stabilitätsgründen" so gehandhabt wird.
Vielleicht blockt aber ja nur der DISPATCHER die Rückmeldung vom GUI-Control ab. Am Besten du setzt einen Break-Point in die DISPATCH-MEthode des ALV (Systemdebugging nicht vergessen) und gehst über die Aufruf-Hierarchie zum Auslösepunkt des Events (meist in CL_GUI_CFW). Dort wieder einen Break-Point setzten. Dann deinen Ablauf mit TAB und verlassen des ALV Grid testen und schauen ob der Debugger anspringt.
Wenn hier der Debugger anspringt, kann man den SAPgui als "Fehlerquelle" ausschließen. Dann muss man sich noch genauer anschauen aufgrund welcher Konstellation es nicht zum Auslösen des Events im ALV-Grid kommt.
Wenn der Debugger nicht anspringt wird der Event schon vom SAPgui oder dem OCX-Control abgeblockt. Dann könntest du nur noch versuchen den neuesten SAPgui zu installieren. Wenn das nicht hilft, kannst du es auch mit einer OSS versuchen. Dazu würde ich dann aber eine "abgespeckte" Version deines Programms erstellen, sodass die SAP den Fehler gleich erkennen kann.
lg ADT
Zuletzt geändert von a-dead-trousers am 11.09.2013 15:20, insgesamt 1-mal geändert.
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
Wenn ich das richtig gesehen habe registrierst Du den Edit-Event nach dem Aufruf von SET_TABLE_FOR_FIRST_DISPLAY. Hast Du mal probiert, diese beiden Aufrufe zu tauschen?
(Klingt zwar blöd, ich hatte ein ähnliches Problem aber auch schon mal und danach hat's getan...)
Grüße,
Haubi
(Klingt zwar blöd, ich hatte ein ähnliches Problem aber auch schon mal und danach hat's getan...)
Grüße,
Haubi
Das beschrieben Verhalten kann man auch im Testreport: BCALV_GRID_EDIT nachvollziehen. Auf dem SelScreen die erste Checkbox (Update bei Zellenwechsel) markieren! Dann mal das letzte Feld in der letzten Zeile ändern. In das letzte Feld Währung einen ungültigen Wert eingeben. Wird das Feld mit TAB verlassen kommt keine Fehlermeldung, bei ENTER nach der Eingabe gibt es eine FehlermeldungHerr Müller hat geschrieben:Vielleicht hilft das Coding weiter. Ich sehe wahrscheinlich den Wald vor lauter Bäumen nicht..
Scheint demnach nicht ein deinem Coding zu liegen, sondern ein SAP "Problem" zu sein. Evtl. mal einen Call bei SAP aufmachen, wobei die Editierfunktion an sich ja nicht freigegeben ist.
Gruß Hendrik
Beitrag
von Herr Müller (ForumUser / 5 / 0 /
0
)
»
Hallo nochmal,
das mit dem Debugging habe ich mal ausprobiert weder in Methode cl_gui-cwf->DISPATCH_SYSTEM_EVENTS noch cl_gui-cwf->DISPATCH hält er im "Fehlerfall" an...
SAP-GUI hab ich schon aktualisiert und auf anderen Versionsständen macht er das auch nicht. OSS habe ich derzeit keinen Zugriff drauf.
Vielen Dank soweit!
das mit dem Debugging habe ich mal ausprobiert weder in Methode cl_gui-cwf->DISPATCH_SYSTEM_EVENTS noch cl_gui-cwf->DISPATCH hält er im "Fehlerfall" an...
SAP-GUI hab ich schon aktualisiert und auf anderen Versionsständen macht er das auch nicht. OSS habe ich derzeit keinen Zugriff drauf.
Vielen Dank soweit!
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Hallo Herr Müller,
ich glaube mit dem Problem muss man leben.
Das Control reagiert (sinnvollerweise) nicht auf einen Fokuswechsel. Daher kann dieses nicht als auslösendes Ereignis für einen Event herhalten. Somit ist die einzige Chance die das Control hat um zu erkennen dass sich der Cursor aus einer Zelle herausbewegt hat das Platzieren in einer anderen Zelle. Und genau das passiert auch.
Da dieses ganze Handling aber im Control selber ( also unterhalb der GUI ) abläuft wird es auch keine Chance geben sich hier gezielt einzuklinken - es sei denn das Control stellt einen bisher nicht verwendeten Event bereit der nicht in der CL_GUI_... _Klasse gespiegelt ist. Aber selbst da fällt mir nicht ein, worauf denn das Control reagieren sollte.
ich glaube mit dem Problem muss man leben.
Das Control reagiert (sinnvollerweise) nicht auf einen Fokuswechsel. Daher kann dieses nicht als auslösendes Ereignis für einen Event herhalten. Somit ist die einzige Chance die das Control hat um zu erkennen dass sich der Cursor aus einer Zelle herausbewegt hat das Platzieren in einer anderen Zelle. Und genau das passiert auch.
Da dieses ganze Handling aber im Control selber ( also unterhalb der GUI ) abläuft wird es auch keine Chance geben sich hier gezielt einzuklinken - es sei denn das Control stellt einen bisher nicht verwendeten Event bereit der nicht in der CL_GUI_... _Klasse gespiegelt ist. Aber selbst da fällt mir nicht ein, worauf denn das Control reagieren sollte.
Beitrag
von Herr Müller (ForumUser / 5 / 0 /
0
)
»
Hallo Stefan,
danke für die Antwort. Allerdings frage ich mich dann, warum die SAP da wieder ein Event "modified" bereitstellt, wenn man nicht auf ALLE Änderungen reagieren kann... Naja, die Wege der SAP bleiben unergründlich...
Danke soweit!
Gruß
Jan Martin
danke für die Antwort. Allerdings frage ich mich dann, warum die SAP da wieder ein Event "modified" bereitstellt, wenn man nicht auf ALLE Änderungen reagieren kann... Naja, die Wege der SAP bleiben unergründlich...
Danke soweit!
Gruß
Jan Martin
Beitrag
von black_adept (Top Expert / 4086 / 126 /
940
)
»
Hallo Jan Martin,Herr Müller hat geschrieben:... Allerdings frage ich mich dann, warum die SAP da wieder ein Event "modified" bereitstellt, wenn man nicht auf ALLE Änderungen reagieren kann
das Problem ist nicht, dass SAP das nicht möchte oder nicht kann. Das Problem ist, dass das Control (ohne Umbegungswissen sondern für sich allein) gar nicht entscheiden kann, ob eine Änderung vorliegt oder nicht.
Wenn der Fokus die Zelle verlässt und der Zelleninhalt sich dann geändert hat ist die Situation ja klar, wohingegen keine Prüfung stattfinden soll solange die Zelle nicht verlassen wird. Aber hier liegt ja auch der Hase im Pfeffer. Woher soll das Control wissen, dass du nicht z.B. in ein (außerhalb von SAP laufendes) Browserfenster geklickt oder einfach mittels ALT-TAB dahin gewechselt hast und nicht in einen anderen Control in deinem aktuellen Modus?
Seite 1 von 1
Vergleichbare Themen
0
Antw.
Antw.
2291
Views
Views
DATA-CHANGED-PROTOCOL vom ALV-Grid manipulieren
von Frog » 27.05.2008 21:31 • Verfasst in ABAP Objects®
von Frog » 27.05.2008 21:31 • Verfasst in ABAP Objects®
2
Antw.
Antw.
2747
Views
Views
1
Antw.
Antw.
10159
Views
Views
Getting the displayed data from an ALV Grid.
von Meurant » 22.11.2005 03:55 • Verfasst in Development Related
von Meurant » 22.11.2005 03:55 • Verfasst in Development Related
1
Antw.
Antw.
2129
Views
Views
17
Antw.
Antw.
7275
Views
Views
alv grid und event handle_data_changed
von hadde85 » 27.05.2008 10:10 • Verfasst in ABAP® für Anfänger
von hadde85 » 27.05.2008 10:10 • 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
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 17 Stunden von DeathAndPain 4 / 830
vor 17 Stunden von DeathAndPain 4 / 830
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 17 Stunden von DeathAndPain 4 / 830
vor 17 Stunden von DeathAndPain 4 / 830