View Full Version : API zur Ermittlung des Parameter DFRWRT in einem Displayfile?
Ok,
kann ich mir dunkel vorstellen.
Kommt aber in den Anwendungen die kenne nie vor.
War auch nie eine Anforderung oder wurde anders gelöst.
@Schatte
Wir haben unsere Anwendung auch selber 'Guifiziert' und eine tolle Java Oberfläche gebaut.
Grün läuft noch und Gui auch. Gui mit entsprechendem Mehrwert für die Anwender, Grün u.a. für Produktionsmitarbeiter, deren Hände nich für eine Maus gemacht wurden.
(Nutze für solche Aktionen die Möglichkeiten einer graphischen Oberfläche um z.B. eine 'Achtung' graphik in die Ecke zu malen)
Viel Erfolg.
Gruß
Robi
Ist ja schön, dass es mal wieder eine grafische Oberfläche für die AS/400 mehr gibt.
Wofür die Leute so immer Zeit haben...:)
Ich weiß ja nicht, wo deine grafische Oberfläche ansetzt.
Tauscht du die Read/Write/Exfmt gegen neue Calls aus oder setzt du auf virtuellen Terminals mit 5250-Datenstrom auf.
In beiden Fällen ist es eigentlich egal zumal es ja auf Satzformatebene auch ein entsprechendes Schlüsselwort gibt (z.B. Statusanzeigen ausgeben).
Beim 5250 steuert das die AS/400 selber, wenn du Calls verwendest muss das Programm eben entscheiden.
Im Programm werden eigene Aufrufe zur Display Steuerung verwendet. Das eigentliche DDS wird in eine eigene XML Datei umgesetzt, die dann an den Client gesendet wird.
holgerscherer
17-11-11, 09:28
Ist ja schön, dass es mal wieder eine grafische Oberfläche für die AS/400 mehr gibt.
Wofür die Leute so immer Zeit haben...:)
Ja, ich könnte auch noch eine Freeware-Version beisteuern. Allerdings hält sich das Interesse beim "normalen" Anwender in Grenzen :)
-h
Ja, ich könnte auch noch eine Freeware-Version beisteuern. Allerdings hält sich das Interesse beim "normalen" Anwender in Grenzen :)
-h
Das Problen ist halt, dass sich an der Ablauflogik - und damit an der Ergonomie der Programme nix ändert, die sehen dann nur anders aus - erinnert mich immer an den Karmann Ghia, sah ein bisschen nach Porsche aus, war aber ein VW Käfer mit Postkutschenfahrwerk.
D*B
holgerscherer
17-11-11, 10:15
Das Problen ist halt, dass sich an der Ablauflogik - und damit an der Ergonomie der Programme nix ändert, die sehen dann nur anders aus - erinnert mich immer an den Karmann Ghia, sah ein bisschen nach Porsche aus, war aber ein VW Käfer mit Postkutschenfahrwerk.
D*B
Da hast Du vollkommen Recht, ich habe aber drei Gruppen herauskristallisieren können:
- nur die Programme aufhübschen, Logik belassen, Bildchen dazu, geht relativ einfach
- wünschen Zusatzfunktionen, alte Logik belassen. Schon schwieriger, je nach Sonderwünschen
- möchten was ganz neues aus ihrer Software machen. Da hilft nur Neuprogrammierung oder Neuanschaffung.
Und interessanterweise ist die erste Gruppe nicht klein, aber: Arbeit solls auch keine machen :)
-h
... allerdings könnte man auch die meist benutzten Programme neu schreiben, mit 20% der Programme würde man da 80% der Tätigkeite erwischen und dann die restlichen 80% als moderne Programme verkleiden, nach dem Motto: im Stadtverkehr ist es auch im Karmann Ghia eng und 53,5 schaft der auch.
D*B
Und interessanterweise ist die erste Gruppe nicht klein, aber: Arbeit solls auch keine machen :)
-h
und nach Möglichkeit nichts kosten..
Das kenn ich irgendwie.
RobertMack
17-11-11, 12:59
... allerdings könnte man auch die meist benutzten Programme neu schreiben, mit 20% der Programme würde man da 80% der Tätigkeite erwischen und dann die restlichen 80% als moderne Programme verkleiden, nach dem Motto: im Stadtverkehr ist es auch im Karmann Ghia eng und 53,5 schaft der auch.
D*B
Chapeau!
Wird Deskilling eines Tages unser bestes Argument sein? Wenn 80% der User im Wald der VALUE- und CMP-Plausibilisierungen verloren gegangen sind und der Letzte das Wissen um ALLE Zusammenhänge in den Ruhestand mitgenommen hat?
;)
Also bis dahin haben sowieso alle SAP :).