ALV Grid Error Protocol

[Emir1919]

Hallo zusammen,
Ich habe ein Dynpro mit einem ALV (CL_GUI_ALV_GRID). Der ALV ist editierbar und ich nutze beim Editieren das Error Protokoll des ALVs (CL_ALV_CHANGED_DATA_PROTOCOL). Das klappt auch wunderbar.

Wenn der Benutzer das Fenster schließen will und es noch fehlerhafte Eingaben gibt, soll das Protokol nochmal ausgegeben werden.
Die fehlerhaften Eingaben kann ich herausfinden. Jetzt besteht nur noch das Problem, dass Protokoll auszugeben.

An das Protokoll kommt man aber nur ran, wenn man das Event DATA_CHANGED abfängt (was ich beim ändern des ALVS auch mache). Dann hat man die Referenz er_data_changed und kann das Protokoll behandeln. Anders kommt man meines Wissens nach nicht an das Protokoll heran oder?

Hat jemand eine Idee, wie ich das Problem umgehen kann?
Die Fehlermeldungen müssten eigentlich auch noch in dem Protokoll drin stehen (da sie vorher schonmal angezeigt wurden). Nur leider gibt es keine Methode zum Anzeigen des Protokols.

Meine Ansätze:

1. Eigenes Obejekt von CL_ALV_CHANGED_DATA_PROTOCOL erzeugen und ausgeben. Die Fehlermeldungen kann man ganz einfach hinzufügen. Das Anzeigen klappt schon teilweise. Er kennt die Feldnamen des ALVs natürlich nicht, weil er den gesamten ALV nicht kennt. Dann zeigt er die Spaltenbezeichnungne nicht an (also die Feldnamen, bei denen der Fehler aufgetreten ist).
Damit könnte ich noch leben, aber beim Schließen des Protokolls möchte das Protokoll den Focus setzen im ALV und dann gibt es einen DUMP, weil das Protokol das Feld natürlich nicht findet.

2. Im ALV gibt es die Möglichkeit, dass Event DATA_CHANGED mit der Methode CHECK_DATA_CHANGED auszulösen. Dafür müsste es aber zu erst eine Änderung geben. Die Änderungen wurden aber schon behandelt und es gibt dementsprechend keine Änderungen und das Event wird nicht ausgelöst.
Dann dachte ich mir, ich simuliere einfach eine Änderung und trickse den ALV aus. Der lässt sich leider nicht austricksen. Ich müsste die ALV-internen Tabellen ändern. Das ändern des Feldkataloges und de Refresh des ALVs reichen nicht aus.
Kann ich den ALV auf diese Weise irgendwie austricksen?

Ansonsten habe ich nur noch die Idee mir selbs ein kleines Log zu schreiben (zum Beispiel SBAL) und auszugeben. Das sieht aber natürlich dann 1. etwas anders aus und 2. kann ich mir nicht vorstellen, dass ich das Protokol des ALVs nicht irgendwie verwenden kann

Danke und viele Grüße
Henrik

[ewx]

Du kannst bei check_changed_data den Parameter E_VALID abfragen. Wenn du einen Protokolleintrag vom Typ "E" bei data_changed abgesetzt hast, dann wird E_VALID immer space sein und die Verarbeitung kann nicht fortgesetzt werden. es wird dann wieder in data_changed gesprungen und die Werte können dann erneut überprüft werden.

[Emir1919]

Danke erstmal.
Leider hatte ich noch keinen Erfolg.

Den Parameter e_valid kenn ich, aber ich ich habe es bis jetzt nicht geschafft, ihn auf space zu bekommen. Wenn er auf 'X' steht, wird das Event DATA_CHANGED gefeuert und ich habe gewonnen...

Folgendes habe ich nun probiert:
1. Fehlermeldungen im ALV erzeugt. (Protokoll wird angezeigt): Es wurden auch Protokolleinträge vom Typ E angelegt
2. Schließen knopf gedrückt. Die Methode CHECK_DATA_CHANGED aufrufen führt wieder nicht zum Erfolg (e_vaild = space).

Der Debugger sagt mir aber auch, dass das Attribut mr_changed_data iniitial ist. Das würde ja bedeuten, dass das Protokoll gelöscht wird. Ich habe auch mal einen anderen Knopf auf das Dynpro gebaut und auch nach dem Betätigen dort ist das Attribut mr_changed_data ebenfalls initial, obwohl ich vorher Protokolleinträge vom Typ E verfasst habe.

Habe ich was nicht beachtet?

[ewx]

Also ich habe folgenden Test gemacht:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1.   METHOD handle_data_changed.
2. ******************************************
3. *** HandleDataChanged                  ***
4. ******************************************
5.     FIELD-SYMBOLS <good>                TYPE lvc_s_modi.
6.  
7. *** alle Inhalte der geänderten Zellen in die interne Tabelle schreiben
8.     LOOP AT er_data_changed->mt_good_cells ASSIGNING <good>.
9. *** Dazu auf die richtige Zeile in der ITAB positionieren:
10.       READ TABLE <itab> ASSIGNING <wa> INDEX <good>-row_id.
11.       IF sy-subrc = 0.
12. *** Und das geänderte Feld dem Feldsymbol zuweisen
13.         ASSIGN COMPONENT <good>-fieldname OF STRUCTURE <wa> TO <feld>.
14.         IF sy-subrc = 0.
15. *** Feldwert zuweisen
16.           <feld> = <good>-value.
17. *          <good>-error = 'X'.
18.           if <feld> > 5.
19.           CALL METHOD er_data_changed->add_protocol_entry
20.             EXPORTING
21.               i_msgid     = 'OO'
22.               i_msgty     = 'W'
23.               i_msgno     = '000'
24.               i_msgv1     = 'TEST1'
25.               i_msgv2     = 'TEST2'
26.               i_msgv3     = 'TEST3'
27.               i_msgv4     = 'TEST4'
28.               i_fieldname = <good>-fieldname
29.               i_row_id    = 1
30.               i_tabix     = 1.
31.         ENDIF.
32.         ENDIF.
33.       ENDIF.
34.     ENDLOOP.

GeSHi ©

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. MODULE user_command_4000 INPUT.
2.  
3.   CASE sy-ucomm.
4.     WHEN 'BACK'.
5.       ref_alv->check_changed_data( importing e_valid = gv_valid ).
6.       check gv_valid = 'X'.

GeSHi ©

Wenn ich nun in dem ALV in einem Feld einen Wert größer 5 eingebe, dann habe ich das Protokoll-Fenster und kann auch mit dem grünen Pfeil das Dynpro nicht verlassen.
Also im Grunde genau das, was du haben möchtest, wenn ich dich richtig verstanden habe. Ansonsten mach ein abgespecktes Minimal-Programm, dann können wir das vielleicht besser nachvollziehen...

Wenn er auf 'X' steht, wird das Event DATA_CHANGED gefeuert und ich habe gewonnen...

Das ist genau anders herum: mit check_changed_data wird versucht "zu sichern" und DATA_CHANGED wird durchlaufen. Wenn keine E-Meldungen gesetzt werden, ist E_VALID = 'X'.

[Emir1919]

Vielen Dank schonmal für deine Mühe!!!

Wenn er auf 'X' steht, wird das Event DATA_CHANGED gefeuert und ich habe gewonnen...

Das ist genau anders herum: mit check_changed_data wird versucht "zu sichern" und DATA_CHANGED wird durchlaufen. Wenn keine E-Meldungen gesetzt werden, ist E_VALID = 'X'.

Ja genau, das hatte ich gestern etwas verdreht. Du hast natürlich recht.

Ich habe jetzt Schritt für Schritt ein Beispielprogramm gebaut das meinem Original Programm am nächsten kommt:

Angefangen habe ich so wie du auch und es funktionierte wunderbar.

Dann habe ich eine globale Klasse erstellt und dort den Event-Handler HANDLE_DATA_CHANGED implementiert.
Es funktionierte immer noch alles und ich war schon am verzweifeln.

Da das ganze Programm aus Objekten besteht werden Funktionsbausteine genutzt, um die Dynpros anzuzeigen (in methoden ist call screen nicht erlaubt...).
Das habe ich dann auch noch realisiert. Und jetzt funktioniert es nicht mehr.

Mein Minimal-Programm:

Klassen
globale Klasse ZHEL_CL_EVENT (kein ABAP CODE!)
Atribute:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. public   gt_mara         type EXPO_MARA_T
2. public   gx_alv            type ref to CL_GUI_ALV_GRID
3. private gt_fcat           type LVC_T_FCAT        
4. private gx_container   type CL_GUI_CUSTOM_CONTAINER
5.  

GeSHi ©

Methoden:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. public constructor
2. private build_alv
3. private handle_data_changed
4.            Ereignishandler für DATA_CHANGED von CL_GUI_ALV_GRID
5.           Attribut er_data_changed
6.  

GeSHi ©

Im Constructor wird dann der ALV aufgebaut und die Daten selektiert:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. METHOD constructor.
2.   SELECT *
3.       FROM mara
4.       INTO CORRESPONDING FIELDS OF TABLE gt_mara
5.       UP TO 100 ROWS.
6.  
7.   CALL METHOD build_alv.
8.  
9. ENDMETHOD.
10.  

GeSHi ©

in handle_data_changed mach ich fast dasselbe wie ENNO:
Bei mir kommt bei der EIngabe 'BLA' die Fehlermeldung

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. method HANDLE_DATA_CHANGED.
2.  
3.       FIELD-SYMBOLS:
4.        <fs_mara>             type mara,
5.        <feld>                type any,
6.        <good>                TYPE lvc_s_modi.
7.  
8.     LOOP AT er_data_changed->mt_good_cells ASSIGNING <good>.
9.  
10. *     eintrag in gt_mar suchen und Feldsymbol zuweisen
11.       READ TABLE gt_mara ASSIGNING <fs_mara>  INDEX <good>-row_id.
12.       IF sy-subrc = 0.
13.  
14. *       wert ändern
15.         ASSIGN COMPONENT <good>-fieldname OF STRUCTURE <fs_mara>  TO <feld>.
16.         IF sy-subrc = 0.
17.           <feld> = <good>-value.
18.           if <feld> = 'BLA'. "Fehlermeldung einfügen, wenn der Benutzer BLA eingibt
19.           CALL METHOD er_data_changed->add_protocol_entry
20.             EXPORTING
21.               i_msgid     = 'OO'
22.               i_msgty     = 'E'
23.               i_msgno     = '000'
24.               i_msgv1     = 'TEST1'
25.               i_msgv2     = 'TEST2'
26.               i_msgv3     = 'TEST3'
27.               i_msgv4     = 'TEST4'
28.               i_fieldname = <good>-fieldname
29.               i_row_id    = 1
30.               i_tabix     = 1.
31.         ENDIF.
32.         ENDIF.
33.       ENDIF.
34.     ENDLOOP.
35.  
36. endmethod.
37.  

GeSHi ©

Funktionsbaustein zum Aufruf des Dynpros

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. FUNCTION ZHEL_CALL_DYNPRO.
2. *"----------------------------------------------------------------------
3. *"*"Lokale Schnittstelle:
4. *"----------------------------------------------------------------------
5.  
6. call screen 2000.
7.  
8. ENDFUNCTION.

GeSHi ©

Dynpro 2000

im PBO wird dann das Object erstellt von der obigen Klasse

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. module CREATE_OBJECT output.
2.  
3.   create object gx_event.
4.  
5. endmodule.  

GeSHi ©

Der User Command:

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. module USER_COMMAND_2000 input.
2.  
3.  DATA:
4.    lv_valid     type char1,
5.    lv_okcode    type syucomm.
6.  
7.   lv_okcode = gv_okcode.
8.   clear gv_okcode.
9.  
10.   CASE lv_okcode.
11.     WHEN 'EXIT'.
12.       leave program.
13.     WHEN 'BACK'.
14. *     soll das protokoll checken.
15.       gx_event->gx_alv->check_changed_data( IMPORTING e_valid = lv_valid ).
16.       CHECK lv_valid = 'X'.
17.  
18.     WHEN OTHERS.
19.   ENDCASE.
20.  
21. endmodule.  

GeSHi ©

Im Programm wird dann einfach

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. start-of-selection.
2.  
3. CALL FUNCTION 'ZHEL_CALL_DYNPRO'.
4.  

GeSHi ©

der FUBA aufgerufen. Das Dynpro wird aufgebaut und der ALV wird angezeigt.


Vorgehen:

1. Irgendwo 'BLA' eingeben -> Error Protokoll erscheint.
2. Auf 'zurück' klicken (FCODE: BACK)
Protokoll wird nicht angezeigt
check_changed_data liefert e_valid = X und das Ereignis HANDLE_DATA_CHANGED wird nicht aufgerufen.

Und ich habe keine Ahnung wodran das liegt. Eigentlich kennen sich doch alle Beteiligten.

Weiß da jemand weiter?

Danke und Viele Grüße,
Henrik

[ewx]

Und du erzeugst das Objekt nicht mehrmals?

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1. create object gx_event.

GeSHi ©

[Emir1919]

Uppssss

Jap in meinem Testprogramm schon. Das hatte ich vor lauter eifer völlig übersehen-

Dann funktioniert es auch! Ich werde nachher nochmal das Original Programm debuggen. Dort gibt es einige Objekte. Leider sitze ich nicht alleine an dem Programm. Da muss ich wohl ne Zeit lang Debuggen!!!

Ich melde mich nochmal...
Danke dir!

[Marc2511]

Hallo Henrik,

ich denke dieses Beispiel-Programm könnte hilfreich sein:
http://www.kerum.pl/infodepot/00034

Gruss,
K.