Inhalt Variable Wert zuweisen

[woodstock99]

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

[Fuerchau]

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.

[woodstock99]

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 )))

[Fuerchau]

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

[BenderD]

das geht ja wüst hin und her, was ich bisher verstanden habe:
- es geht um Kommunikation zwischen DSPF und Programm
dafür gilt erst einmal:
=> das geht über einen Buffer, der für In und Out in (mehreren) Formaten beschrieben ist und zwar doppelt, einmal im DSPF und einmal im Programm, das sich die Beschreibung zur Compiletime auch aus dem DSPF holen kann.
=> selber kann man sich die Beschreibung auch aus dem DSPF holen, mit DSPFFD oder mit dem im Thread bereits benannten API, das ist nicht explizit dokumentiert, wird sich aber (zumindest rückwirkend) nicht ändern, sonst müsste man nämlich neu compilieren und mit WebFacing hätte man ins selbige gegriffen (was man aus anderen Gründen eh hat).
=> ob man jetzt den Buffer über Programmvariablen, oder Bit weise über die DSPF Buffer Beschreibung verarbeitet, oder teils teils, das ist letztlich Gechmacksache (ich habe meinen Geschmack benannt, W seinen, andere ihren), am Wahrheitsgehalt des Programms ändert das nix, wenn man es denn richtig macht. Ob ich meinen Geschmack an dieser Stelle ändern würde, weiß ich nicht so genau, da habe ich mich zu wenig mit den DSPFs beschäftigt (z.B.: woran erkenne ich die Attribut Felder? 1 p ist mir zu wenig, Namensgedöns auch...)

So ein paar Sachen sind mir immer noch im Nebel:
- die Sortiererrei und dieses AAAAAAA Feld scheinen mir überflüssig
- die Userspace APIs sind es definitiv, da kann man direkt Pointer im Programm nehmen (mit denen kann man auch rechnen!!!), selbst Substring würde es schon tun, oder ein Array of Character
- diese Biton Bitof Arie würde ich durch named Constants ersetzen (die kann man in der Deklaration Hex belegen)

D*B

der nix gegen Jugend forscht hat

[Fuerchau]

@Dieter
Das Problem in ILE/RPG ist doch dieses, dass die Varablen aus der F-Bestimmung nichts mit dem Dateipuffer, der intern verwaltet wird, zu tun hat.
Jeder Dateibefehl stellt die entsprechend benötigten Variablen in den Puffer oder entnimmt sie daraus.

Die Verwendung der API's steht ja auch ausser Frage, einzig und allein der Zugriff auf die Programmvariablen, die vom Compiler (in RPG irgendwo, in ILERPG anscheinend sortiert) im Speicher definiert werden, steht hier zur Diskussion.

Und da bin ich eben der Meinung, dass man sich hier vom verwendeten Compiler (ILERPG) abhängig macht und beim nächsten Release oder Compiler auf der Nase liegen kann und sich dann wundert warum nix mehr klappt.

Aber du hast Recht, dem Forscherdrang sollte man nicht entgegenwirken.

[woodstock99]

@Fuerchau

Also ich hab diese Technik mal in ein ILE-Rpg eingebunden und in ein SQLRPGLE.
Funktioniert beides.
Hab aber keine Ahnung ob die denselben Compiler benutzen..

Um in Rpg das aufzurufen müsst ich erst mal meine Prozeduren ändern und auflösen, den zulange Variablennamen usw ((. Callp geht ja in RPG auch nicht oder??

Desweiteren muß ich dir recht geben das es eine recht heikle Angelegenheit ist.

Arbeitet hier keiner bei IBM und weiß zufälligerweise wann der nächtes Compiler rauskommt und wie des Ding funktioniert ????



@BenderD:

Sortieren tu ich gar nix.
Dieses aaaaaa 1 P Feld bräuchte man wirklich nicht aber so hat man immer das Feld mit der niedrigsten Startadresse im Speicher.

Und da diese 1P Felder aufsteigend sortiert werden ist das schon ne kleine Hilfe.

Wenn ich dieses Feld nicht definiere müsste ich innerhalb der ganzen Maske nach dem kleinsten Wert eines Feldnamen suchen und den mit an mein Programm-Api übergeben.

Diese bitand und or Geschichten
benützen wir im Serviceprogramm dazu ein Attribut dem Feld hinzuzufügen oder wieder wegzunehmen. Das geht doch nicht anders. Die Attribute haben wir natürlich per Constanten z.b.

Color_BLU C Const(x'3A')
definiert...


Die Userpacesache dient dazu die Felder (bist du ein 1p ATR DSPATR(&ATRxxxxx) )zu identifizieren.
Rechnen tun wir da gar nix..


Alles im allen ist das ein schmaller Grad auf dem wir uns bewegen würden. Diese ganze Geschichte brauchen wir auch nur um die Felder zu
initialisieren ...

Aber es ist zumindest mal eine Lösüng die Funktionieren würde....

[woodstock99]

oder gibt es evtl einen Befehl den man im dspf angeben kann`` defaultwert, inz, keine ahnung. kann man die dspatr variable nicht irgendwie auf einen defaultwert setzten initialisieren ?????????

[Fuerchau]

Innerhalb der DSPF gibt es für P-Felder keinen INZ-Wert (DFTVAL geht nur für Eingabefelder).
Das muss scshon das Programm selber machen.

Allerdings weiß ich nicht, ob du da unbedingt ein CALL-API brauchst und nicht lieber eine Copy-Strecke mit den Konstanten bereitstellst.

Es ist allemal einfacher mit den Namen als mit Calls zu arbeiten, insbesonders bei so simplen Sachen wie Attributen.

Auch das Problem der Init's verstehe ich nicht, da ich doch weiß, dass ich die Attribute vernünftig setzen muss.

Alaso ich gehe da immer folgendermaßen vor:

if Bedingung true;
DspAtr = Attribut_Red;
else;
DspAtr = Attribut_Green;
endif;

Schließlich muss ich ja ggf. das Rot-Attribut beim nächsten Durchlauf eh wieder auf Grün setzen, so dass es fehlerhafte Init's ja eigentlich nicht geben dürfte. Schließlich stellt man das ja schon beim Testen fest, wenn da was ungültig ist.

[woodstock99]

ja das ist ja das problem das ich p felder nicht inzen kann ((.
hätt mir aber gedacht evtl kannst du ja mal einen zaubertrick aus deinem ärmel schütteln . hast ja schon genügend kampferfahrung auf diesem system .


ach wir wollen halt ( weil wir extrem schreibfaul sind ) alles irgenwie über serviceprogramme lösen und das programm so schlank wie möglich zu halten.
ja copystrecke könnten wir uns auch automatisch generieren lassen aber das wollen wir nicht. wir wollen halt mal ein zeichen setzen auch ohne copystrecken,bezugszahlen usw auszukommen.
sind eigentlich auf einem sehr guten weg wie ich finde aber so kleinichkeiten wie das inzen von 1p feldern bricht uns das genick. oder wir setzen doch unser
api-programm ein was aber einer zeitbombe gleichen kann .
eigentlich heisst es ja immer ein junger mensch muß sich was trauen aber die nummer wär schon verdammt heiss .

wir sind halt grad dabei eine funktionsbibliothek zu erstellen die alle nützen können und in der wir soviel funtionen wie möglich reinpacken wollen und den anderen programmieren das leben so leicht wie möglich zu machen...

[woodstock99]

ach ja das probem mit den inits.
wir haben ja überhaupt keine attributte mehr im displayfile definiert. wenn ich jezt das programm calle und nicht initialisiere kommt das ganze durcheinander. keine ahnung warum. verstehe ich ehrlich gesagt auch nicht. geh mal davon aus das irgendein müll in den variablen steht. ich finde das sind lauter kinderkrankheiten der ibm,denn wenn ich ohne zu inzen ri zuweise macht er es ab uns zu und ab zu zu nicht. wenn ich aber das feld inze funktioniert es einwandfrei. find ich auch komisch...

[Fuerchau]

Tja, da hilft nur, doch eine Copystrecke zu generieren, die die ATR-Felder als Single-Felder deklariert. Dann gibts auch keine Probleme.
Da eine Variable nur einmal vorhanden ist und es für DS'n von DSPF-Formaten keinen Grund gibt, kann man die ATR-Felder auch initialisieren:

Copy für Attribut-Values:
d AtrValue_Green const(x'nn')

Generierte Atr-Copy:
d MyAtr1 s 1 inz(AtrValue_Green)
:

Auch HLL/5GL usw. kommen ja nun mal ohne Includes/Copies nicht aus, was spricht also dagegen, neben den Funktionsprototypen eben auch Konstanten festzulegen ?
Und eine Copy-Strecke zu generieren (ggf. in einem automatischen Programmerstellungslauf) dürfte auch nicht das Problem sein.

Wenn es nur um den blöden INZ geht (den man eben meiner Meinung nach nicht braucht), ist das vielleicht ein Weg.

Ausserdem:
Trotz aller Bibliotheken und Funktionen sollte man den performance-Aspekt nicht soganz vernachlässigen.