Code: Alles auswählen.
FORM ok_code_9100 .
DATA: lf_ok_9100 TYPE gui_code.
lf_ok_9100 = ok_9100.
CLEAR ok_9100.
CASE lf_ok_9100.
WHEN 'BACK'.
LOOP AT gt_belege INTO gs_belege
WHERE zvbkz IS NOT INITIAL.
lf_belege_zvbkz = 1.
EXIT.
ENDLOOP.
IF lf_belege_zvbkz IS NOT INITIAL.
CALL FUNCTION 'POPUP_TO_CONFIRM'
EXPORTING
titlebar = text-p01
text_question = text-p02
text_button_1 = text-pok
text_button_2 = text-pca
default_button = '1'
display_cancel_button = space
IMPORTING
answer = gf_reallyquit
EXCEPTIONS
text_not_found = 1
OTHERS = 2.
IF sy-subrc NE 0.
gf_reallyquit = 2.
ENDIF.
ENDIF.
IF gf_really_quit NE 2.
LEAVE TO SCREEN 9000.
ENDIF.
ENDCASE.
ENDFORM. " OK_CODE_9100
Code: Alles auswählen.
IF gf_reallyquit NE 1.
* Belegeübersicht
CALL METHOD g_alv_belege->set_table_for_first_display
EXPORTING
is_layout = gs_layout_belege
it_toolbar_excluding = gt_extool_belege
CHANGING
it_outtab = gt_belege
it_fieldcatalog = gt_fk_belege
it_sort = gt_sort_belege
EXCEPTIONS
invalid_parameter_combination = 1
program_error = 2
too_many_lines = 3
OTHERS = 4.
IF sy-subrc <> 0.
* interner Fehler
MESSAGE e107(ckcc).
ENDIF.
ELSE.
* Anzeige auffrischen
Call METHOD g_alv_belege->refresh_table_display.
ENDIF.
Hallihallo,
das was du beschreibst ist ein nerviges Thema - da kann man sich zu Tode suchen woran es liegt. Ich hab mir dein Coding kurz angeschaut und das Problem ist meines Eindrucks nach die folgende Zeile:
Code: ‹ Download › ‹ Auswählen ›
FREE: cl_container2, cl_grid_alv2, lt_alv_t.
Das sieht ja an sich harmlos aus und du möchtest damit sicher deinen alten dargestellten Grid inkl. des zugehörigen Containers löschen.
Aber wenn ich mich nicht sehr täusche passiert genau dieses nicht.
Grund: Du hast einen Dynpro mit einem Customcontrol. An dieses Control wird dein cl_container_2 gebunden und in diesen container dann dein ALV.
Wenn du nun "nur" ein Free machst, gibst du die Variable scheinbar frei. Aber da der Dynpro noch existiert und der Customcontainer sich in der "Child"-Liste des Dynpros eingetragen hat, wird der Garbagecollector die zugehörigen Objekte noch nicht abräumen. Du hast zwar über die Variablen cl_container2 etc keinen Zugriff mehr darauf - aber sie existieren momentan noch.
Das ist etwa so wie wenn man eine Eventhandlerklasse definiert und beim Registrieren der Handler an ein Objekt (z.B. ein Grid ) innerhalb einer Formroutine vorher eine (form-)lokale Instanz der Klasse erzeugt. Nach Verlassen der Formroutine existiert die grade eben erzeugte (form-lokale) Instanz zwar nicht mehr für dein Programm - aber da der handler registriert wurde existiert sie noch für das Objekt solange bis das Objekt abgebaut wird.
Nun wird dein Coding durchlaufen und mit Code: ‹ Download › ‹ Auswählen › ‹ Aufklappen ›
# IF cl_container2 IS INITIAL.
wird ein neuer Container erzeugt, der sich an denselben Bereich des Dynpros klemmt wie der vorherige. Damit sind dem Bereich des Dynpros nun 2 Customcontainer zugeordnet. Und angezeigt wird immer noch der erste, weil er "vorne" liegt.
Das kannst du überprüfen, indem du im Debugger beim 2. Doppelklick und nach Erzeugung des Customcontrols dir dieses Control anschaust, von hier in den "parent" verzweigst und dir von ebendiesem mal die "Childliste" anschaust. Hier solltest du nun 2 Container vorfinden.
Lösung: Wie kannst du das umgehen?
Du musst dafür sorgen, dass das vorher angezeigte Customcontrol vollständig abgebaut wird - und das machst du am Besten, indem du den Destruktor des Controls aufrufst, welcher üblicherweise "DESTRUCTOR" oder "FREE" heißt, bevor du die am Anfang zitierten Codingzeilen "Free....." aufrufst
_________________
live long and prosper
Stefan
email: black_adept@yaAbb.de