Window Anzeige Problem

[Fuerchau]

Dies scheint mir eher ein Problem von CA zu sein. Da ich beim Rahmen immer mit Leerzeichen, Farbe weiß und Attribut Reverse arbeite, bekomme ich zwar nicht so schöne Rahmen, aber es funktioniert immer !

[MrBonZai]

@Fuerchau
könntest Du da mal den Source-Code posten für die Window-Darstellung?

Ich habe mein Programm gerade auf der Konsole getestet... gleiches Problem... liegt also nicht am CA.

[Fuerchau]

Ich glaub ich seh jetzt dein Problem.
In deinem Fenster gibst du *NOMSGLN an, du überlagerst aber dann die Nachrichtenzeile (24) aber mit deinem Fenster !!

Entweder mach das Fenster mit Nachrichtenzeile, oder verschiebe es nach oben, so dass die Nachrichtenzeile sichtbar bleibt.

Das Schlüsselwort USRRSTDSP sowie die Umwandlung mit RSTDSP(*NO) sind erforderlich.

Ansonsten sieht meine DSPF genauso aus wie deine.

[holly]

Hallo,
ich habe in meinem DUMMY-Record (assume) auch nochmal das OVERLAY drin, weiss aber nicht, ob das ein Unterschied macht.
Gruß Holger

[Fuerchau]

Das Overlay im Dummy hat keine Auswirkung, da dieses Format ja nicht verwendet wird.

ASSUME soll ja nur nur drinstehen, damit der Bildschirm nicht gelöscht wird !

[Fuerchau]

Ich habs jetzt nochmal ausprobiert und kann das Problem nachvollziehen.
Es liegt tatsächlich ein Problem in der Bildschirmsteuerung vor, wenn das Window das einzige Format dieser Programmebene ist !

Da ich bei Fenstern jedoch immer noch ein Record-Format ausgebe (Fehlerzeile + F-Tasten), kommt bei mir der Fehler natürlich nicht.

Verlege z.B. die F-Tasten in ein eigenes RECORD-Format, dass du vor die Ausgabe des Fensters legst.
Allerdings gibt es auch hier teilweise seltsames Verhalten, wenn man hier OVERLAY verwendet. Anstelle dessen muss man CLRL(nn) verwenden. In diesem Falle werden genau so viele Zeilen gelöscht, wie der Parameter "nn" angibt.
Dann wird auch das Fenster korrekt angezeigt.

RSTDSP(*NO) und USRRSTDSP sind auf jeden Fall trotzdem erforderlich !

Mein Fussformat:

A          R FUEBETBO                                          
A*%%TS  SD  20000531  113908  RHTESTN     REL-V4R2M0  5769-PW1 
A                                      CLRL(02)                
A                                 24  3'F1:'                   
A                                      COLOR(WHT)              
A            FLD001        15   O 24  7MSGID(DSP 0047 VOUSER)  
A  31        DSFETX        78   O 23  3COLOR(WHT)              
A                                      DSPATR(RI)

Das Fenster sieht genauso aus wie deins.

[MrBonZai]

@Fuerchau
das ist ja genial... jetzt funktioniert es...
besten Dank für die ganze Zeit, die Du investiert hast.

jetzt habe ich allerdings noch ein kleines Problem...
Ich versuche es mal zu beschreiben:

"Pgm1-SFL" ruft "Pgm2-WINDOW" auf.
über eine Funktinstaste kann ich in "Pgm2" ein weiteres Programm ("Pgm3") aufrufen, das im Vollbildmodus aufgerufen wird.
Verlasse ich nun Pgm3 wird mein Window aus "Pgm2" wieder hergestellt... allerdings mit dem Hintergrund aus Pgm3
Das wäre natürlich falsch, da es ja eine Aufrufhirarchie darstellt und normal sollte er, wenn ich mich in Pgm2 befinde, den Hintergrund aus Pgm1 anzeigen...

Eigentlich bräuchte ich ja hier nun RSTDSP(*YES) in Pgm2... allerdings wäre ich dann bei meinem bekannten Problem angelangt...

Alle Programme (Pgm1+2+3) werden mit *INRT beendet.

gruss Alex

[Fuerchau]

Dies ist leider nur durch einen kleinen Trick durchführbar:

Pgm-1 ruft Pgm-2 auf.
Bei F-Taste mit Funktionscode zurück nach Pgm-1, dass nun Pgm-3 aufruft.
Bei Rückkehr von Pgm-3, Write des Bildschirmes aus Pgm-1 und wieder Aufruf von Pgm-2 mit Ausgabe des Window.

Bei "Windows" ist es nun mal so, dass immer der aktuelle Inhalt überschrieben wird, woher soll das Programm auch wissen, was da vorher stand ?


Ansonsten gibts da ein paar Api's, siehe unter
http://publib.boulder.ibm.com/iserie.../QsnSavScr.htm
http://publib.boulder.ibm.com/iserie.../QsnRstScr.htm

Möglicherweise funktioniert es auch, wenn du die DSPF des Windows mit RSTDSP(*YES) umwandelst und Pgm-2 grundsätzlich mit "eval *INLR = *on" verläßt.
Dies beendet das Programm, die Displayfile wird geschlossen !
Beim nächsten Open und EXFMT in Pgm-2 wird natürlich der Screen gesichert und nach Rückkehr aus PGM-3 wiederhergestellt.

PS:

*INRT ist ausschließlich bei Zyklus-Programmierung (IP=Input Primary usw.) nötig, wenn man VOR *INLR zurückkehrt.

*INLR bedeutet:
wenn Aus => Dateien und Variablen bleiben im letzten Status, bei erneutem Aufruf kein Open und *INZSR
Wenn An => Programm wird deaktiviert, alle Dateien geschlossen, bei erneutem Aufruf wie 1. Aufruf mit *INZSR

[Thimi]

Hallo MrBonZai,

auf jeden Fall mit RSTDSP(*YES) umwandeln, dann tritt dies nicht mehr auf. Mit *INLR anstelle *INRT das(die) PGMS verlassen.
Gruss
thierry

[Thimi]

Hallo MrBonZai,

warum willst Du unbedingt *INRT einsetzen??? Falls Du das Programm geöffnet haben möchtest, dann wäre RETURN angesagt.

Gruss
thierry

[MrBonZai]

Original geschrieben von Thimi
Hallo MrBonZai,
warum willst Du unbedingt *INRT einsetzen??? Falls Du das Programm geöffnet haben möchtest, dann wäre RETURN angesagt.

was ist denn bitte der Unterschied zwischen *INRT & RETURN?

ich will die Ladezeiten der Programme so gering wie möglich halten... sprich alle Dateien,... sollen geöffnet bleiben... daher der *INRT...


@Fuerchau
Du bist echt ein Guru... dank Dir ganz herzlich...

[Fuerchau]

*INRT habe ich nie verwendet, da ich keine Zyklusprogrammierung benötige (wozu gibts da Query o.ä.) und für die Mandantenfähigkeit sowie Dialogprogrammierung sehr aufwändig ist.

RETURN bzw. RETRN:

Mit diesem Befehl wird ein RPG-Programm vorzeitig beendet. Er kann an jeder beliebigen Stelle (auch zwischen BEGSR/ENDSR) verwendet werden (Entspricht z.B. exit() in C/C++).
An dieser Stelle entscheidet *INLR über den weiteren Status (s.o.).

Vor der ersten BEGSR existiert ein impliziter Return:
Verwende ich "InputPrimary" und ist *INLR aus wird ein Datensatz gelesen und mit der 1. Anweisung wieder begonnen ansonsten das Programm deaktiviert und beendet.

Verwende ich KEIN "InputPrimary" wird im übrigen genauso verfahren !!!!
=> unverständliche Wiederholungen, da *INLR entscheidet !

*INRT unterbricht die Verarbeitung von "InputPrimary" (vor der 1. BEGSR) und da *INLR aus bleibt (wird ja nicht verwendet) entspricht dies einem kodierten RETURN mit *INLR = *OFF !!