Problem mit OO-ALV
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
Hallo zusammen,
ich habe ein typisches Dynpro mit diversen Eingabefeldern und einem (eingabebereitem!) OO-ALV, welches mittels
und
angelegt ist und somit bei Betätigen von ENTER die PBO- und PAI-Ablauflogik des Dynpros durchläuft. Eines der PAI-Module hat die Aufgabe, die eingegebenen Werte in den Dynprofeldern UND den ALV-Feldern zu checken. Damit hier im Ablauf von PAI die eingegebenen ALV-Werte aktuell zur Verfügung stehen, wird im PAI vor den Checks noch die Methode
aufgerufen. Danach enthält die dem ALV zugrunde liegene Tabelle GT_ALV die aktuellen Werte, und alles kann im PAI gecheckt werden und ggf. mit bösen Fehler-Messages belohnt werden.
Problem:
PAI wird ja auch durchlaufen, wenn im ALV z.B. auf einen Button der Toolbar gedrückt wird. Das möchte ich aber nicht. Kann ich irgendwie im PAI herausfinden, "was genau" im ALV gemacht oder gedrückt wurde, damit ich dann wirklich nur bei ENTER im ALV durch PAI mit seinen Checks renne? Momentan arbeiten wir im PAI mit dem OK_CODE des Dynpros, welches bei Aktionen im ALV recht kryptische Inhalte hat, wie z.B. "%_GC 144 19". Die hintersten beiden Ziffern stehen dabei scheinbar immer für einen "Event" des ALV, zumindest lassen sich diese Ziffern in den Attributen der cl_gui_alv_grid Klasse wiederfinden. Wir wissen aber nicht, ob wir diesen Dingern "trauen" können. Gibt es keine andere Methode, um rauszufinden, WAS im ALV zuletzt "gemacht" oder ausgelöst wurde?
MfG, JE
ich habe ein typisches Dynpro mit diversen Eingabefeldern und einem (eingabebereitem!) OO-ALV, welches mittels
Code: Alles auswählen.
CREATE OBJECT alv
EXPORTING
i_parent = cont
i_appl_events = 'X'.Code: Alles auswählen.
CALL METHOD alv->register_edit_event
EXPORTING
i_event_id = cl_gui_alv_grid=>mc_evt_enter.Code: Alles auswählen.
CALL METHOD alv->check_changed_data.Problem:
PAI wird ja auch durchlaufen, wenn im ALV z.B. auf einen Button der Toolbar gedrückt wird. Das möchte ich aber nicht. Kann ich irgendwie im PAI herausfinden, "was genau" im ALV gemacht oder gedrückt wurde, damit ich dann wirklich nur bei ENTER im ALV durch PAI mit seinen Checks renne? Momentan arbeiten wir im PAI mit dem OK_CODE des Dynpros, welches bei Aktionen im ALV recht kryptische Inhalte hat, wie z.B. "%_GC 144 19". Die hintersten beiden Ziffern stehen dabei scheinbar immer für einen "Event" des ALV, zumindest lassen sich diese Ziffern in den Attributen der cl_gui_alv_grid Klasse wiederfinden. Wir wissen aber nicht, ob wir diesen Dingern "trauen" können. Gibt es keine andere Methode, um rauszufinden, WAS im ALV zuletzt "gemacht" oder ausgelöst wurde?
MfG, JE
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 / 4397 / 223 /
1182
)
»
Schau dir mal die Events des ALV an.
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
Ich habe mir heute schon den ganzen Tag lang die Klasse cl_gui_alv_grid angesehen, komme aber dennoch nicht weiter. Muss dazu aber auch sagen, dass ich nicht gerade sehr erfahren im OO-Bereich von ABAP oder im Umgang mit ALV bin. Bin schon froh über das, was ich bis jetzt auf die Beine gestellt habe. Wenn du also einen etwas "konkreteren" Tipp haben solltest, wäre ich sehr dankbar... 
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
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 black_adept (Top Expert / 4093 / 127 /
940
)
»
Hallo JE,
warum registrierst du überhaupt alle Ereignisse als Application-Events? Lass das weg ( damit hast du dann alles als Systemereignis ) und löse gezielt ein PAI aus bei den Ereignissen, die du im PAI behandeln möchtest ( z.B. mit CL_GUI_CFW=>SET_NEW_OK_CODE ).
warum registrierst du überhaupt alle Ereignisse als Application-Events? Lass das weg ( damit hast du dann alles als Systemereignis ) und löse gezielt ein PAI aus bei den Ereignissen, die du im PAI behandeln möchtest ( z.B. mit CL_GUI_CFW=>SET_NEW_OK_CODE ).
Das Ereignis, das ich im ALV behandeln möchte, ist ENTER, und zwar ohne wenn und aber.
Dies scheint man aber nur in Verbindung mit der Tatsache, dass im ALV Daten verändert wurden (DATA_CHANGED halt), behandeln zu können. Ich kenne keinen Weg, ein ENTER im ALV abzufangen, OHNE dass im gleichen Schritt auch Daten im ALV verändert wurden.
Daher der Weg über
und gleichzeitig
So habe ich garantiert, dass ich nach ENTER im ALV durch meinen Code laufen kann.
Nur, und das ist mein Problem, erkenne ich hier leider nicht mehr, ob es im ALV nun ENTER war, oder ein RIGHT-BUTTON-CLICK, oder vielleicht ein TOOLBAR-CLICK, der der Auslöser war. Ich habe nur diesen kryptischen OK_CODE des Dynpros, aber keine schöne Methode des ALV, die mir verrät, was zuletzt im ALV passiert ist...
Dies scheint man aber nur in Verbindung mit der Tatsache, dass im ALV Daten verändert wurden (DATA_CHANGED halt), behandeln zu können. Ich kenne keinen Weg, ein ENTER im ALV abzufangen, OHNE dass im gleichen Schritt auch Daten im ALV verändert wurden.
Daher der Weg über
Code: Alles auswählen.
i_appl_events = 'X'Code: Alles auswählen.
CALL METHOD alv->register_edit_event
EXPORTING
i_event_id = cl_gui_alv_grid=>mc_evt_enter.Nur, und das ist mein Problem, erkenne ich hier leider nicht mehr, ob es im ALV nun ENTER war, oder ein RIGHT-BUTTON-CLICK, oder vielleicht ein TOOLBAR-CLICK, der der Auslöser war. Ich habe nur diesen kryptischen OK_CODE des Dynpros, aber keine schöne Methode des ALV, die mir verrät, was zuletzt im ALV passiert ist...
Vielleicht kannst du mit CL_GUI_ALV_GRID=>GET_FOCUS noch abfragen, ob der Cursor im Grid stand oder nicht.
Bin mir nicht sicher, ob das (a) funktioniert und (b) verlässlich ist.
Aber einen Versuch ist evtl. Wert.
Bin mir nicht sicher, ob das (a) funktioniert und (b) verlässlich ist.
Aber einen Versuch ist evtl. Wert.
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Hallo JE,
ohne das allgemeine Setzen von Application-Events ist der einfachste Weg wohl folgender: Statt des üblichen Grid nimmst du eine abgeleitete Version. Und in dieser Version sorgst du halt dafür, dass der von dir immer noch registrierte ENTER-Event auch einen PAI triggert. Kann man auch schön in eine eigene Klasse im DDIC packen, wenn man so was häufiger mal braucht.
Beispiel:
P.S.: Das direkte Triggern des PAI ist hier deiner Anforderung geschuldet. Falls du eine allgemeine Klasse im DDIC ablegst solltest du bei abgefangenem ENTER-Event eine neu in der abgeleiteten Klasse definierten Exception via RAISE auslösen und dich in deinem Programm dann auf diesen neuen Event registrieren und dort den PAI mittels cl_gui_cfw=>set_new_ok_code triggern.
ohne das allgemeine Setzen von Application-Events ist der einfachste Weg wohl folgender: Statt des üblichen Grid nimmst du eine abgeleitete Version. Und in dieser Version sorgst du halt dafür, dass der von dir immer noch registrierte ENTER-Event auch einen PAI triggert. Kann man auch schön in eine eigene Klasse im DDIC packen, wenn man so was häufiger mal braucht.
Beispiel:
Code: Alles auswählen.
CLASS my_grid DEFINITION INHERITING FROM cl_gui_alv_grid.
PUBLIC SECTION.
METHODS dispatch REDEFINITION.
ENDCLASS.
CLASS my_grid IMPLEMENTATION.
METHOD dispatch.
super->dispatch( EXPORTING
cargo = cargo
eventid = eventid
is_shellevent = is_shellevent
is_systemdispatch = is_systemdispatch
EXCEPTIONS
cntl_error = 1
OTHERS = 2 ).
IF eventid = mc_evt_enter.
cl_gui_cfw=>set_new_ok_code( EXPORTING
new_code = 'Grid:ENTER' ).
ENDIF.
ENDMETHOD.
ENDCLASS.
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Hallo JE,
wenn du andererseits keinen Einfluss darauf hast was für einen Grid du nehmen willst sondern auf den Standard-ALV-Grid zurückgreifen musst, könntest du auch den kryptischen OK-Code analysieren um zu schauen, ob es ein ENTER-Event war.
Der OK-Code ist beispielsweise wie folgt aufgebaut: %_GC 211 19
%_GC: Das ist eine Konstante
211: Ist die interne Nummer eines Objekts
19: Ist ?meist? die Eventid
Wenn du also schauen willst, ob "dein" Grid den ENTER-Event gefeuert hat könntest du das wie folgt analysieren:
wenn du andererseits keinen Einfluss darauf hast was für einen Grid du nehmen willst sondern auf den Standard-ALV-Grid zurückgreifen musst, könntest du auch den kryptischen OK-Code analysieren um zu schauen, ob es ein ENTER-Event war.
Der OK-Code ist beispielsweise wie folgt aufgebaut: %_GC 211 19
%_GC: Das ist eine Konstante
211: Ist die interne Nummer eines Objekts
19: Ist ?meist? die Eventid
Wenn du also schauen willst, ob "dein" Grid den ENTER-Event gefeuert hat könntest du das wie folgt analysieren:
Code: Alles auswählen.
DATA: lv_shellid_i TYPE i,
lo_subscriber TYPE REF TO cl_gui_control.
TRY.
SPLIT ok_code AT space INTO DATA(dummy) DATA(shellid_c) DATA(lv_eventid).
lv_shellid_i = shellid_c.
cl_gui_cfw=>get_subscriber_by_id( EXPORTING shellid = lv_shellid_i
IMPORTING subscriber = lo_subscriber ) .
IF lo_subscriber = alv AND lv_eventid = cl_gui_alv_grid=>mc_evt_enter.
BREAK-POINT.
ENDIF.
CATCH cx_root.
ENDTRY.@black_adept: Dickes DANKE, tut wie Sau! Das ist genau das, was wir brauchten!black_adept hat geschrieben:Code: Alles auswählen.
CLASS my_grid DEFINITION INHERITING FROM cl_gui_alv_grid. PUBLIC SECTION. METHODS dispatch REDEFINITION. ENDCLASS. CLASS my_grid IMPLEMENTATION. METHOD dispatch. super->dispatch( EXPORTING cargo = cargo eventid = eventid is_shellevent = is_shellevent is_systemdispatch = is_systemdispatch EXCEPTIONS cntl_error = 1 OTHERS = 2 ). IF eventid = mc_evt_enter. cl_gui_cfw=>set_new_ok_code( EXPORTING new_code = 'Grid:ENTER' ). ENDIF. ENDMETHOD. ENDCLASS.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
2180
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
Umherspringende Methoden im quelltextbasierten Class Builder
vor 2 Stunden von ralf.wenzel 104 / 9990
vor 2 Stunden von ralf.wenzel 104 / 9990
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 2 Stunden von ralf.wenzel 104 / 9990
vor 2 Stunden von ralf.wenzel 104 / 9990