SUBFILE Programmierung

[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.

[mk]

Hi,

wenn Du dein 5250 Programm im Browser darstellst,
wirst Du das gleiche Akzeptanz Problem haben.
Heutige Anwender wollen Eventgesteuerte Anwendungen
und kein weiß-grau statt schwarz-grün tippen.

Und das vielbeschworene Aufhübschen der Dialoge
bedeutet viel Zeit , Arbeit und Kosten.
Auch der spätere Wartungsaufwand ist nicht zu unterschätzen.

PS:Ich möchte kein 300 Seiten RPG im Browser bedienen
müssen. Das macht wirklich keinen Spaß.

[dschroeder]

Du hast natürlich recht. Eine reine Darstellung der alten Masken im Browser bringt dem Anwender keinen Mehrwert und uns nicht mehr Akzeptanz. Aber es eröffnet uns die Möglichkeit, neue Programme unter Berücksichtigung der grafischen Möglichkeiten ganz neu zu konzipieren. Das Tool, das wir im Moment testen, bietet anscheinend ziemlich gute grafische Komponenten an. Die Komponenten sind alle Ajax-basiert und geben die notwendigen Events zurück. Es liegt dann in der Verantwortung des RPG-Programmierers, daraus etwas sinnvolles für den Anwender zu machen. Natürlich müssen die RPG-Programme ganz anders aussehen wie die Programme, die man bisher für (recht statische) 5250-Masken geschrieben hat. Ich glaube aber, dass das gehen wird.

[mk]

Hi,

lass mich raten:
Ist die Basis für das GUI Frontend das EXTJS ?

[dschroeder]

EXTJS sagt mir im Moment nicht. Wir testen gerade ProfoundUI.

[camouflage]

Um auf die ursprünglich gestellte Frage zurückzukommen...

Warum gibst Du nicht einfach auf das entsprechende erste Input-Field im Subfile nicht einfach ein "DSPATR(PC)" ein? Dies stellt den Cursor auf das erste Input Feld und sollte die Probleme beim Blättern eliminieren. Einfach mal so als Q&D Lösung.

Nachtrag:
In Profound UI geht das unter "Field Settings" mit dem Property "Set Focus" TRUE oder konditioniert mit Bezugszahlen.

Gruss