SUBFILE Programmierung

[MR-BN]

Hallo Forum,

ich hoffe, dass meine Frage nicht zu lächerlich klingt, aber im Moment habe ich keine richtig gute Idee, wie das Problem zu lösen ist:

Wir haben eine systemgesteuerte Subfile, in der sich ein Auswahlfeld befindet. Der User stellt den Cursor z.B. in das Aufwahlfeld des 8. Subfile-Satzes. Danach blättert der User auf die 2. SFL-Seite. Der Cursor behält dabei die Position, die er auf der ersten Seite hatte. Das heißt, er steht sofort im 8. Subfile-Satz der 2. Seite. Das ist erstmal nicht so dramatisch. Es wird aber ziemlich blöd, wenn es auf der 2. SFL-Seite nur 6 Sätze gibt. Dann steht der Cursor nämlich im "leeren Raum".

Weiß jemand auf die Schnelle, wie man dem Cursor beibringt, auf das erste Eingabefeld der SFL zu springen? Das Problem im Programm ist, dass das Blättern vollständig vom System übernommen wird. Wenn man die Blättertaste drückt, kommt man gar nicht ins EXFMT zurück. Ich kann den Cursor deshalb nicht per Bezugszahl an die passende Stelle positionieren.

Vielen Dank im Voraus,

[Fuerchau]

Das geht leider nur, wenn du das Blättern eben nicht vom System steuern lässt sondern komplett selber durchführst.

[dschroeder]

Vielen Dank für die Antwort. Ich hatte so etwas befürchtet. Wir haben fast alle Subfiles programmgesteuert programmiert. Nur wenige sind systemgesteuert. Dabei ist uns dieses Problem bisher nie aufgefallen. Wie experimentieren aber im Moment mit einer grafischen Oberfläche, bei der alle Anwendungen im Browser dargestellt werden. im Browser sieht man den Cursor leider nicht sehr gut bzw. gar nicht, wenn sich der Cursor nicht in einem Eingabefeld befindet.

Vielen Dank,
Dieter

[RobertMack]

Hmmm... eigentlich stellt sich der Cursor nicht von selbst in einen "leeren Raum". Prüfe mal, ob im SFLCTL das Schlüsselwort CSRLOC(Fld1 Fld2) angegeben ist und ggf. woher die Felder ihren Wert erhalten.

[dschroeder]

CSRLOC ist nicht angegeben. Wir haben allerdings SFLCSRRRN angegeben. Außerdem ist SFLRCDNBR(*TOP) gesetzt.

[Fuerchau]

@Robert
Wenn das System die SFL steuert, bleibt der Cursor bem Blättern auf dem Bildschirm stehen, ggf. auch im leeren Raum.

Man kann dies tatsächlich nur selber steuern, wenn man eben Rollup/Rolldown selber auswertet und die aktuelle Seite sowie die Anzahl Sätze berücksichtigt.
Sicherlich ist das unschön, insbesonders, wenn man mal die SFLPAG verändert hat und das Programm ändern muss.
In der INFDS erfährt man auch irgendwo, welcher Satz gerade der 1. angezeigte ist um das Blättern korrekt zu steuern.

Zu SFLCSRRRN ist noch zu sagen, dass man auch Blättern kann, wenn der Cursor z.B. im SFLCTL steht. In diesem Fall wird nämlich 0 (Null) gemeldet und man ist auf die INFDS angewiesen.

SFLRCDNBR(*TOP) würde ich da eher nicht nehmen, sondern SFLRCDNBR(*CURSOR). Dadurch wird immer auf die Seite positioniert und der zu positionierende Satz nicht an den Anfang der Seite gestellt.

Übrigens hat man das selbe Problem auch mit SFLDROP/SFLFOLD, wenn man das nicht programmgesteuert auswertet und ggf. auch wieder korrekt setzt.

[mk]

Hallo MR-BN,

da ihr ja auch PHP Erfahrung habt, würde ich die
benötigten Funktionalitäten einfach neu entwickeln.
Es macht eigentlich keinen Sinn mehr die 5250
Dialogprogramme ins Web zu bringen.

Gruß
Michael

[dschroeder]

"Einfach neu entwickeln" ist leicht gesagt. Wir haben einige tausend Programme auf der iSeries. Außerdem finde ich RPG als Programmiersprache gar nicht schlecht. Es ist für kaufmännische Anwendungen ziemlich effektiv. Wir entwickeln RPG mit der Eclipse-basierten Umgebung RDP. Wenn wir die Ausgabe jetzt noch grafisch hinbekommen, haben wir mit Greenscreen nichts mehr zu tun. Unser Ziel ist es, die alten Programme mit 5250-Bidschirmausgabe quasi unverändert in den Browser zu bekommen und neue Programme für die grafische Browserdarstellung zu entwicklen. Wir hätten dann eine sehr sanfte Migration, da wir die alten 5250-Programme weiter verwenden können.

Es würde mich sehr interessieren, wie die Meinung zu dem Vorgehen ist, bzw. welche Nachteile, das ganze hat.

Gruß,
Dieter

[mk]

Hi,

ob man nun die RPG Programme mit einer Eclipse basierten
Entwicklung schreibt, oder mit SEU.
Es bleibt immer noch RPG.

Ich gebe Dir vollkommen Recht das RPG für die
kaufmännische Verarbeitung sehr gut geeignet
ist. Wenn aber Modernieisierung ansteht,
dann bitte mit Serviceprogrammen.

Habt ihr denn wirklich einige 1000 Dialogprogramme ?
Gerade bei dieser Anzahl erscheint eine Neuentwicklung
sinnvoller zu sein.

gruß
Michael

[dschroeder]

Hi,
ich denke schon, dass wir ca. 2000 Dialogprogramme haben. Neu schreiben heißt mehrjähriger Aufwand. Das ist ja nicht nur teuer sondern beinhaltet auch, dass man sich wieder alle Kinderkrankheiten der neuentwickelten Software einhandelt. Im Moment passt unsere Software ziemlich gut zum Geschäftsbetrieb. Die Oberfläche ist unser eigentliches (Akzeptanz)-Problem.