-
Dann hast du mich missverstanden.
Ich meine nicht das Ergebnis der API's, da ist eigentlich die Sortierung unerheblich, da du ja die relative Pufferposition deiner Variablen bekommst.
Ich verstehe immer noch nicht, wie dein Programm an die Speicheradresse der Variablen des aufrufenden Programmes kommt, dass von diesem ja wohl aufgerufen werden soll !
-
Harakiri-Methode .
Meine Programm to System Felder sind in der Maske 1P definiert und in der Referenzdatei 1A.
Ich übergebe meinem Api die Startadresse und das Displayfile usw.
Jetzt schaue ich welche Felder meinen kriterien 1P &ATRxxxxx entsprechen.
z.b. 50 Stück kommt als Ergebnis raus..
zum Schluß kommt eine Schleife (anzahl 1p &ATRxxxx Felder)
For I = 0 To anzahlfelder - 1
Eval p_varia = p_Strvaria + I
Eval Avar = Atrvarval
EndFor
Ich teste jetzt schon die ganze Zeit und immer wieder das gleiche Ergebnis. Er sortiert die Felder nach der Reihe im Speicher..
egal ob 10 , 100, 500.. Felder
ich meine das es dass Speicherkonzept der IBM so vorsieht zumindest solche Variable so zu speichern.
Die 100% Lösung ist das nicht. Aber zumindest mal überhaupt eine.
Gibt es irgendwo unterlagen wie die IBM seine Sachen im Speicher verwaltet und wo was , wie angelegt wird??
-
Ok, dann eine Frage noch:
Wie definierst du die ATR-Felder in der RPG-Quelle ?
Wenn du in einer Quelle eine Dateivariable nicht referierst (auch nicht in einer DS), wird für diese Variable kein Speicherplatz reserviert (daher auch im Debugger nicht verfügbar).
Verwendest du die Attribute in einer DS, ist es allemal leichter allein per Definition und "MOVE *ALLX'20' ..." oder sogar per " I I X'20' MYATR" den Init vorzunehmen als komplizierte und wenig performante API's zu verwenden.
Wie sieht's aus, wenn du mehrere Formate in einer DSPF hast ?
Rufst du dein PGM je Satzformat auf ?
Wie ist dann die Reihenfolge deiner Variablendeklaration ?
-
wie definieren in der RPG Quelle ??
in meiner rpg QUELLE gar nicht ??
mehrere Satzformate kein Problem. Rufe mein Api einmal auf und gut is.
Api bekommt nur bibliothek und maske mit.
Felder stehen auch bei mehreren Formaten in Reihenfolge.
Das soll ja auch der Sinn sein wenn ich eine Maske mit 10 formaten und x Feldern hab das ich nicht mehr im Rpg initialisieren muß..
Sondern Api aufruf und gut ist es. Egal wieviel Formate und Felder.
-
Na gut, dann willst du mir deine Geheimnisse nicht verraten 
Bisher verstehe ich dich so:
RPG-Programm A
FMyDspf ....
:
:
c call 'DeinAPI'
c parm 'DSPNAME'
:
c EXFMTMYFMT
und schwups, sind alle meine ATR-Felder des Programmes A initialisiert ?
-
 Zitat von Fuerchau
Na gut, dann willst du mir deine Geheimnisse nicht verraten
Bisher verstehe ich dich so:
RPG-Programm A
FMyDspf ....
:
:
c call 'DeinAPI'
c parm 'DSPNAME'
:
c EXFMTMYFMT
und schwups, sind alle meine ATR-Felder des Programmes A initialisiert ?
du hast es erfasst.
aber es muss noch ein weiterer Wert übergeben werden. Startadresse Dummy (ATRAAAAAAAA) und ein optionaler Parameter wie die Felder initialisiert werden sollen kann mit angegeben werden.
Also initialisiert heisst für mich auf keine DISPLAY ATTRIBUE gesetzt z.b x:20 nur grün oder je nachdem was dem API-Übergeben wird . Natürlich könnte man auch Farbe setzten und so weiter auch noch gleich ins Api mit reinpacken aber dann is man ja nicht mehr flexibel . Also lieber trennen und dadurch kann ich jetzt z.B meine Bezeichnungsfelder in der Maske gruppieren und mit Callp set_dsp_atr(&Varbeizeifelder:color_blu:dstatr_ul) usw ) alle je nach wunsch bunt,unterstrichen usw machen.
Gut das man den gleichen Variablennamen (&ATRVAR...) in der Maske in mehreren Formaten angeben kann 
Oder man kann gezielt einzelne Felder ansprechen.
Das einzig blöde ist nur das ich das Api-Programm noch erweitern muß, so das ich auch einzelne Formate "nur " initizialisieren kann falls ich das mal brauch.
Bis jetzt macht es gnadenlos alle Felder die 1 P definiert mit ATR beginnen und DSPATR(&ATRXXXXX) sind platt aber das passt ja in 99.999 % der Fälle .
Diesen ganzen Müll könnte man sich näturlich auch sparen aber wenn man Attribute per Programm setzt, müssen die Felder mit irgendwas initialisiert werden sonst kommt bei der Setzung der Attribute Müll raus 
Wir haben jetzt alle Bezugszahlen aus unserem Displayfile verbannt den das Attribut(PC) setzten steuern wir über ein anderes API . Natürlich die für die Subfilesteuerung haben wir noch. Die bekommt man ja auch nicht aus der Maske raus . Aber däfür kann man sie im RPG über Namen ansprechen .
Ich kann dir das auch mal zukommen lassen. Init DSPFELDER.... Dann ist das Geheimniss gelüftet .
Aber selbe Frage nochmal. Gibt es irgendwelche unterlagen wie der Speicher verwaltet wird?? Glaub mal eher nicht oder.
Würde nur für diesen Fall gerne Wissen wie die 1 P Variablen in der Maske verwaltet werden um ein 100 % gutes Gefühl bei der Sache zu haben und nicht nur durch ewiges Testen ein gutes Gefühl zu haben
-
Da scheinst du ja mit deinen Attributen Glück zu haben, allerdings bedingt dies auch, das ein Attribut in der gesamten DSPF nur 1 Mal vorhanden sein darf.
Da ich als RPG-Programmierer eher faul bin, definiere ich ein und das selbe Feld mit seinem Attribut in unterschiedlichen Formaten aber immer gleich.
Im RPG-Programm ist das Feld aber nur 1 einziges Mal vorhanden !
Um also dein Programm benutzen zu dürfen, müsste ich je Format die Attribute eindeutig benennen.
Dies führt in der Folge aber dazu, dass ich auch die Attribute zwischen den Formaten hin und herschieben muss.
Beispiel:
In einer Subfile sind verschiedene Felder mit ihren Farbattributen definiert.
Mit einer Auswahl 5 kann ich die Details anzeigen.
Im Detailbild sind die selben Felder mit ihren Attributen wie in der Subfile benannt und nur noch die zusätzlichen Felder mit Attributen definert.
Dabei ist auch die Reihenfolge etwas anders.
Im Speicher sind aber die Attribute nur ein mal definiert und zwar in der Reihenfolge ihres Auftretens innerhalb der Formate.
Rufe ich nun dein Programm auf, gibts hier ein Problem!
Auszug aus der Generierung:
DCL DD POSAUF PKD (04,0) INIT(P'0')
DCL DD SFFAST CHAR (0001) INIT((0001)' ')
DCL DD SFFAOF CHAR (0001) INIT((0001)' ')
DCL DD SFAFND PKD (07,0) INIT(P'0')
DCL DD SFAFHP PKD (04,0) INIT(P'0')
DCL DD POSKDT PKD (04,0) INIT(P'0')
DCL DD SFFARE CHAR (0001) INIT((0001)' ')
DCL DD SFRENR PKD (07,0) INIT(P'0')
Die SFFA-Felder sind meine Attributfelder.
PS:
Wie ein Compiler seine Variablen deklariert, bleibt dem jeweiligen Compiler überlassen.
Wenn es dann mal einen Super-ILE-Compiler gibt, kann das wieder anders aussehen.
Vielleicht sortiert der alle Namen nach Alphabet.
-
stop... der Zug rollt schon wieder ein. Ehrlich gesagt versth ich dich jetzt nicht ganz.
Da scheinst du ja mit deinen Attributen Glück zu haben, allerdings bedingt dies auch, das ein Attribut in der gesamten DSPF nur 1 Mal vorhanden sein darf.
Versteh ich nicht. Stimmt auch meiner Meinung nach nicht.
Da ich als RPG-Programmierer eher faul bin, definiere ich ein und das selbe Feld mit seinem Attribut in unterschiedlichen Formaten aber immer gleich.
Ich auch . Ich definiere nur noch Variablen und die heissen auch in den unterschiedlichen Formaten gleich 
Im RPG-Programm ist das Feld aber nur 1 einziges Mal vorhanden !
Stimmt . Ist aber auch gut so 
Um also dein Programm benutzen zu dürfen, müsste ich je Format die Attribute eindeutig benennen.
??????
Attribut im Displayfile???
Ich setzte überhaupt keine Attribute mehr im Displayfile.
Das einzige was ich noch definiere sind Variablen vom Typ 1 p
Beispiel 1.
Definiere Variable &ATRFLDTEXTE in den verschieden Formaten.
Weise diese allen Textfeldern in egal welchen Formaten sie sind zu.
Setze im Programm einen CALLP (&ATRFLDTEXTE:Color_BLU:?:?:?)
( ? steht für was du noch willst an Attributen) ab und schon sind meine 47,11 Felder definiert.
Und wenn ich diese Felder ändern will setzte ich nur einen CALLP im Programm ab und dann sind Sie meinetwegen Gelb und in Umkehranzeige. Ich kann sie ändern so oft ich lustig bin.

Und das alles ohne Bezugszahlen.
Beispiel 2
Definiere Kundennummer (EingabeFeld)
Weise meine ATRVAR der Kundennummer zu egal im welchen Format und in welcher Reihenfolge dieses Feld in den verschiedenen Formaten auftritt. Setzte wieder einen CALLP ab und gut ist es. Wenn jetzt z.b der User einen Fehler gemacht hat, Callp und in Umkehranzeige. Dann kommt halt dieses Feld noch in Umkehranzeige.
Ich bin dadurch frei wie ein Vogel und ich weiß jetzt nicht was da auch bei dir nicht funktionieren soll???
Die Attribute werden durch ein Serviceprogramm durch bitand usw definiert,geändert usw 1A = 8Bits die an und aus geschaltet werden
Vielleicht hab ich auch Unterbier und versteh dich einfach heute nicht mehr )))
-
Nun ja, wie du oben an Hand der DCL-Anweisungen der MI-Liste sehen kannst, sind die SFFA-Felder nicht bündig hintereinander deklariert.
Dabei spielt es jetzt keine Rolle, ob du die nun ATR oder wie ich SFFAxx benennst.
Mit Attribut im DSPF meine ich ja Attributfelder.
Wenn ich also dein Programm hier aufrufen würde, würde das Feld SFFARE direkt hinter SFFAOF angenommen und somit das Feld SFAFND zerstören.
Aber da du ja wohl mit ILERPG arbeitest (da gibts keine MI-Listen) ist mein obiger Hinweis der Compilerintegration wohl entscheidend.
Der RPG-Compiler definiert die Felder wohl in einer anderen Reihenfolge als eben der ILERPG-Compiler.
Und das meine ich eben, mit Glück gehabt.
Wer sagt dir denn, dass dies mit dem nächsten XXXRPG-Compiler noch ebenso sein wird ?
Probiers doch einfach mal aus, dass du dein Programm aus einem RPG-Programm statt ILERPG aufrufst.
Du machst dich damit einfach von einem bestimmten Compiler abhängig, und das ist bei API-Programmen gefährlich.
Diese sollten eben auch Compiler unabhängig fuktionieren (wie es die IBM-API's eben tun).
Similar Threads
-
By mk in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 21-12-06, 08:56
-
By Xanas in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 28-08-06, 12:21
-
By cheffe1008 in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 16-05-06, 07:45
-
By steven_r in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 08-05-06, 11:01
-
By JonnyRico in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 25-04-06, 10:16
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks