Eigenes Dynpro --> interne Tabelle füllen und anzeigen

[Nikita4217]

Hallo!

Ich brauch mal einen kleinen Denkanstoß. Ich will ein Progrämmchen basteln, weiss aber noch nicht wie und ob das so funktioniert, wie ich mir das denke:

In diese Programm möchte ich auf einem Dynpro ein Eingabefeld bereitstellen. Darin soll eine Nr. eingegeben werden. Zu dieser Nummer sollen wenn Enter gedrückt wird(o.ä.) Stammdaten ausgelesen werden und an eine interne Tabelle angehängt werden. Dann soll die nächste Nummer eingegeben werden und auch diese Stammdaten ausgelesen werden und an die interne Tabelle angehängt werden. Dei interne Tabelle soll also durch die Eingaben immer weiter gefüllt werden. Gleichzeitig soll die interne Tabelle, die sich immer füllt, auch auf dem Dynpro angezeigt werden.

Wenn man irgendwann mal fertig ist mit eingeben, sollen mit den Daten in der internen Tabelle noch weitere Aktionen gemacht werden, aber das ist zweitrangig, das sollte ja dann kein Problem sein.

Ich weiss aber nicht so recht ob und wie das mit der sich füllenden internen Tabelle möglich ist. Hat jemand vielleicht nen kleinen Tip in die Richtung?

Gruß
Sascha

[Andrew85]

Das sollte kein grosses Problem darstellen...

Ich könnte mir da zB ein Screen vorstellen, mit einem Eingabebereich und einem ALV-Grid.

Im PAI des Screens wird dann geprüft, ob sich die Nummer geändert hat.
Falls ja wird die DB-Selektion durchgeführt, die Daten der Tabelle angehängt und das ALV aktualisiert.

[Nikita4217]

Ja, so in etwa hab ich mir das auch gedacht. Mit Sub-Screens, o.ä.
War mir nur nicht ganz sicher, ob die interne Tabelle im Hintergrund erhalten bleibt.

Wobei ich noch nicht so genau weiss, ob ich das ALV-Grid per Funktionsbaustein aufrufe. Geht das überhaupt, das ich den ALV-Grid auf einem bestimmten Sub-Screen aufrufe? Wenn ja, wie ungefähr?

[Andrew85]

Ich benutze in der Regel die Klasse CL_GUI_ALV_GRID. Diese ist fix einem Custom Container zuzuteilen.

Auf dem (Sub-)Screen wo das ALV Grid dargestellt werden soll, muss ein Custom Container vorhanden sein, im folgenden Beispiel muss dieser CC_DATA heissen.

Globale Datendefinition:

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

1. DATA:
2.   cc_data     TYPE REF TO cl_gui_custom_container,
3.   tc_data     TYPE REF TO cl_gui_alv_grid,
4.  
5.   it_daten    TYPE TABLE OF ...
6.  

GeSHi ©

Initialisierung im PBO des (Sub-)Screens:

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

1.   IF cc_data IS INITIAL.
2.  
3. *   container initialisieren
4.     CREATE OBJECT cc_data
5.       EXPORTING
6.         container_name = 'CC_DATA'.
7.  
8. *   alv-grid initialisieren
9.     CREATE OBJECT tc_data
10.       EXPORTING
11.         i_parent = cc_data.
12.  
13.   ENDIF.

GeSHi ©

Zum Anzeigen des ALV grid wird dann noch die Methode SET_TABLE_FOR_FIRST_DISPLAY benötigt - diese benötigt auch noch einen Feldkatalog.

Zum aktualisieren des ALVs nachdem Änderungen an der Datentabelle (it_daten) vorgenommen wurden, kann dann widerum die Methode REFRESH_TABLE_DISPLAY aufgerufen werden. Diese braucht keine parameter.

Wo dabei die Tabelle "it_daten" befüllt wird, spielt keine Rolle, da diese global definiert ist.

Ich hoffe du kommst mit meiner "schnell-schnell-Erklärung" klar, ansonsten einfach "nachhaken"