Screen Stack - Kurzdump LIST_TOO_MANY_LPROS

[Emir1919]

Hallo zusammen,
Wir haben bei uns ein Tool entwickelt (ähnlich den Solution Manager, falls es der Vorstellungskraft dient ), indem viele Dynpros aufgerufen werden müssen.
Durch die gegebene Architektur haben wir ziemlich oft den Befehlt "Call Screen xxx" verwendet.

Wenn man etwas länger mit dem Tool herumspielt, kommt es dann zu einem Kurzdump, dass der Stack voll ist.



Ich habe bereits gegoogelt und leider nur Lösungen gefunden, die ich schwer in die Architektur einbringen kann:

1.

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

1. LEAVE TO SCREEN 0.

GeSHi ©

Das geht leider nicht so einfach in dem Programm. Da im Screen 0 einfach direkt wieder ein Dynpro aufgerufen wird. Ich habe den Umbau auch schon getestet. Leider zerschießt mir das ziemlich viel und man müsste viele Anpassungen vornehmen.

2.

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

1. CALL TRANSACTION

GeSHi ©

Quelle:
[url]http://www.georgwiesinger.de/sap/daily-abap/daily-abap/archive/2010/february/article/kurzdump-list-too-many-lpros-die-zweite.html?tx_ttnews[day]=07&cHash=ce0ac6b7f5[/url].

Das wäre theoretisch möglich, allerdings dauert der Aufbau des Programms ca. 5 Sekunden, da viele Daten gepuffert werden und ein ALV TREE aufgebaut wird.


Ich habe mal nach FUBAs gesucht und bin sogar fündig geworden:

FUBA: STACK_RESET

Allerdings kann ich mir fast nicht vorstellen, dass es so einfach ist:
der Code ist nämlich nur:

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

1. function stack_reset.
2. *"----------------------------------------------------------------------
3. *"Lokale Schnittstelle:
4. *"----------------------------------------------------------------------
5.  
6.   n-stack = 0.
7.   clear: stack.
8.   refresh: stack.
9.  
10.  
11. endfunction.

GeSHi ©

Der Verwendungsnachweis ist ziemlich düftig:

Wenn ich Mal Kommentare finde, sehen die so aus:
"Baut den internen Stack der Folgebildsteuerung ab."

Das ist doch eigentlich genau das was ich brauche oder sehe ich das falsch?

Hat vielleicht jemand schonmal dasselbe Problem gehabt und eine Lösung parat

Vielen Dank schonmal und Gruß,
Henrik

[ewx]

Hi Henrik! Du musst in der Regel kaum einen CALL SCREEN programmieren. Es reicht, wenn du die neue Dynpro-Nummer im PAI mit "SET SCREEN 1234" setzt.
Der erwähnte Baustein stack_reset findet wohl eher Anwendung bei der "generellen Folgebildsteuerung": Transaktion VFBS. Wird z.B. in der SAPMV45A Auftragsbearbeitung verwendet. Bei wirklichen vielen Screens wäre das vielleicht auch eine gute Alternative, denn mit der VFBS kann man die Folgebildsteuerung einstellen, d.h. es wären bei einer Änderung keine Programmänderungen notwendig. Selbst benutzt habe ich es allerdings auch noch nicht.

[Emir1919]

Hi Enno, danke dir schonmal.

Aber so einfach ist es leider nicht...
SET SCREEN kann ich nicht verwenden, da der Aufruf aus SUBSCREENS erfolgt und es kommt dann die Fehlermeldung "SET SCREEN aus SUBSCREENS nicht möglich).

Vielleicht nochmal kurz etwas zum Aufbau des Programms.
Links ist ein Baum, indem ich Doppelklicks machen kann und dann öffnet sich rechts ein Dynpro mit den Informationen. Dort sind auch SUBSCREENS etc. zu finden.
Wenn ich nun im Subscreen etwas ändere kann es gut sein, dass ich das gesamte Dynpro refresehen muss. Dies geht leider nur mit CALL SCREEN, da ich in einem SUBSCREEN bin. Meine Idee das einfach nochmal im PAI des Hauptdynpros zu machen funktioniert leider nicht. Wenn ich nämlich erst die Subscreens abarbeite kennt er die Änderungen vom Dynpro noch nicht und ich kann die Daten nicht handhaben -> Teufelskreis),

Dasselbe Problem besteht zum Beispiel auch, wenn ich im Baum zu einem anderen Dynpro navigieren möchte und ich mich in einem SUBSCREEN befinde...

Die Folgebildsteuerung kenne ich so auch nicht. Allerdings ist das für meinen Fall glaube ich nicht sehr hilfreich, da es eine ziemlich flache Navigationshierachie verwendet wird. Eigentlich nur Dynpro rechts. Der Zurück-Knopf ist nur zum Start-Screen anzeigen vorgesehen.


Gruß
Henrik

[Ilja583]

Hallo Hendrik,

Dasselbe Problem besteht zum Beispiel auch, wenn ich im Baum zu einem anderen Dynpro navigieren möchte und ich mich in einem SUBSCREEN befinde

Heißt das, dass du für den Baum einen Event für deine Navigation registriert hast und wenn der User den Event triggert, dass du dann mit "CALL SCREEN" deine Verarbeitung voranbringst ohne den Event auch zu beenden.
Falls ja hast du ein Problem. Denn durch das CALL SCREEN wird die Event-Behandlung nicht abgeschlossen und ich erinnere mich an Codingfragmente der Eventhandler, wo explizit darauf abgeprüft wird, ob es noch einen "offenen" Event auf dem Stack gibt.

Wenn ich nun im Subscreen etwas ändere kann es gut sein, dass ich das gesamte Dynpro refresehen muss. Dies geht leider nur mit CALL SCREEN, da ich in einem SUBSCREEN bin. Meine Idee das einfach nochmal im PAI des Hauptdynpros zu machen funktioniert leider nicht. Wenn ich nämlich erst die Subscreens abarbeite kennt er die Änderungen vom Dynpro noch nicht und ich kann die Daten nicht handhaben -> Teufelskreis

Das kann ich so nicht glauben. Subscreens sind zwar ein wenig tricky was die Datenschieberei angeht - aber machbar ist fast alles.
Gib doch mal ein (auf das minimale reduzierte) Beispiel wo es an der Datenbeschaffung hapert. Meist ist es nur eine Kleinigkeit die geändert werden muss (Zeitpunkt des Subscreenaufrufs, FIELD-Anweisungen, ... )
Denn letztlich hat ewx völlig recht - ein Dump "LIST_TOO_MANY_LPROS" ist (fast) immer vermeidbar bei geschicktem Programmaufbau.

[Emir1919]

Hi Stefan,
Danke dir!!!

Heißt das, dass du für den Baum einen Event für deine Navigation registriert hast und wenn der User den Event triggert, dass du dann mit "CALL SCREEN" deine Verarbeitung voranbringst ohne den Event auch zu beenden.
Falls ja hast du ein Problem. Denn durch das CALL SCREEN wird die Event-Behandlung nicht abgeschlossen und ich erinnere mich an Codingfragmente der Eventhandler, wo explizit darauf abgeprüft wird, ob es noch einen "offenen" Event auf dem Stack gibt.

Oh ja, da hast du wohl Recht. Das hatten wir auch nicht bedacht. Das hört sich auch nicht gut an, allerdings kann ich sagen, dass wir damit bis jetzt keine Probleme hatten...

Aber wäre es denn bei "SET SCREEN" etwas anderes? Da würde er doch auch auf dem SCREEN stecken bleiben oder...

Das kann ich so nicht glauben. Subscreens sind zwar ein wenig tricky was die Datenschieberei angeht - aber machbar ist fast alles.
Gib doch mal ein (auf das minimale reduzierte) Beispiel wo es an der Datenbeschaffung hapert. Meist ist es nur eine Kleinigkeit die geändert werden muss (Zeitpunkt des Subscreenaufrufs, FIELD-Anweisungen, ... )
Denn letztlich hat ewx völlig recht - ein Dump "LIST_TOO_MANY_LPROS" ist (fast) immer vermeidbar bei geschicktem Programmaufbau.

Hm das kann gut sein. Leider würde das nun etwas größere Anpassungen bedeuten. Wir haben das gerade nochmal bei uns besprochen und vermutlich hast du Recht: Wir haben das alles nicht optimal aufgebaut. Es würde jetzt allerdings eine erheblichere Anpassung bedeuten, die Architektur umzubauen.
Zum Beispiel setzen wir in den Subscreen-PAI den okcode neu, um ihn später verarbeiten zu können. Außerdem haben wir noch eine Filterfunktion etc.

Das sieht für uns gerade nach etwas mehr Arbeit aus. Und da es eigentlich in einer ersten Version jetzt bald fertig sein sollte, werden wir die Änderungen vermutlich verschieben, wenn es nicht noch deutliche Beschwerden gibt. Weil das Programm ansonsten eigentlich gut funktionert und wir nun auch nicht alles kaputt machen wollen.
Wir streben natürlich eine optimale Lösung an und werden es dann auch hoffentlich in kurzer Zeit in die Tat umsetzen!!!

Gruß
Henrik

PS:
Ich hatte auf einen FuBa gehofft, der mir einfach den Stack löscht. Der Stack wird nämlich bei uns gar nicht verwendet... Aber sowas scheint es nicht zu geben...