Toolmaker Produkt-Dokumentation
RPGWX-Prozeduren
Inhaltsübersicht
Suche:
|
RPGWX-Prozeduren im Überblick
Das komplette HTML-Dokument sowie der Datenaustausch zwischen RPG und HTML wird durch den Aufruf von RPG IV - Prozeduren gesteuert, die von RPGWX zur Verfügung gestellt werden. Mit Hilfe der RPGWX-Prozeduren werden die Informationen aus Ihrem RPG-Programm gesammelt und im Anschluss auf der i in HTML Seiten konvertiert und in dem Browser der Benutzerin oder des Benutzers ausgegeben.
Es stehen zahlreiche Prozeduren zur Verfügung:
- Erstellung eines Browserfensters (Zwei Arten: WRK oder CHG)
- Übergabe und Entgegenname von Daten an/vom Browserfenster
- Layout des Browserfensters (bedingte Ausgabe, Registerkarten, usw.)
- Übergabe von Parametern zwischen den Programmen
Dieses Kapitel gibt einen Überblick über die verfügbaren Prozeduren.
RPGWX-Anwendungen arbeiten "stateless". Das heisst, dass die Programme grundsätzlich beendet werden, sobald der Befehl (=Prozeduraufruf) zur Ausgabe eines Browserfensters ausgeführt wird. (Bei WRK-Programmen heisst die Prozedur Wx_WrtWrkTbl
, bei CHG-Programmen ist es Wx_WrtChgTbl bzw. WX_GetChgInput
). RPGWX sorgt dafür, dass ein Programm wieder an der Stelle nach der Ausgabe aufsetzt und die erfassten Daten in die RPG-Variablen zurückgibt, so dass für die Entwickler keine Änderungen gegenüber traditionellen Programmen sichtlich sind. Aber: das Programm wird nicht nur beendet und neu gestartet, es ist auch nicht gewährleistet, dass es im selben Job läuft, wie zuvor. Wenn ein weiteres Programm gerufen wird, dann ist auch nicht gewährleistet, dass dieses wiederum im selben Job läuft, wie das rufende Programm.
Deshalb
- können Parameter nicht direkt im CALL, sondern nur über die URL übergeben werden. Zusätzliche Informationen können mit Hilfe der Funktionen (
Wx_SetParmXXX / Wx_GetParmXXX
) zwischen den Aufrufen gesichert und im Folge-Programm aufgerufen werden. - kann die Bibliothek QTEMP, sowie die *LDA (Local Data Area) nicht zum Zwischenspeichern von Informationen verwendet werden
- Bei Detail-Verarbeitungs-Programmen (CHG-Programme) kann der Datensatz nicht zu Beginn des Programms gesperrt werden, da das Programm bei Ausführung der Funktion
Wx_GetChgInput
beendet und nach erfolgter Eingabe erneut aufgerufen wird. Damit verliert er nach demWx_GetChgInput
alle Sperren. Deshalb muss der zuändernde Datensatz erst unmittelbar vor dem Update eingelesen und gesperrt werden. An dieser Stelle ist es auch ratsam, Vergleiche durchzuführen, ob der Datensatz zwischenzeitlich (also solange er im Browser zur Bearbeitung stand) von einer anderen Benutzer oder einem anderen Benutzer geändert wurde.
Es gibt RPGWX-Prozeduren für
- WRK-Programme (Detaillierte Beschreibungen der Prozeduren für WRK-Programme finden Sie hier)
- CHG-Programme (Detaillierte Beschreibungen der Prozeduren für CHG-Programme finden Sie hier)
- beide Arten von Programmen (Detaillierte Beschreibungen hier)
Diese Seite enthält eine Übersicht über die verfügbaren Prozeduren, Regeln und allgemeine Hinweise zur Aufbereitung und anderem, die überall gelten.
Obligatorische und Optionale Parameter
- Obligatorische Parameter müssen natürlich immer übergeben werden
- Optionale Parameter sollten nicht übergeben werden, wenn sie nicht verwendet werden
Prozeduren für Work-Tables
Zur Erstellung und Verarbeitung von Work-Tables (List-Anzeigen) stehen die folgenden Prozeduren zur Verfügung:
Tabelle 1: RPGWX-Prozeduren für Work-Tables
Prozeduren für Change Tables
Zur Erstellung und Verarbeitung von Work-Tables (List-Anzeigen) stehen die folgenden Prozeduren zur Verfügung:
Tabelle 2: RPGWX-Prozeduren für Change Tables
Parameter in RPGWX-Prozeduren
Für jede Prozedur werden die Parameter genannt, die bei ihrem Aufruf möglich sind.
- Anzahl der Parameter: Die Anzahl der Parameter in den RPGWX-Prozeduren wurde auf ein Minimum beschränkt
- Input/Output-Parameter: Bei den einzelnen Parametern handelt es sich fast ausschließlich um Input Only-Parameter, die mit Schlüssel-Wort CONST definiert wurden.
- Optionale Parameter:Parameter, deren Übergabe nicht unbedingt erforderlich ist, wurden am Ende der Parameter-Liste als optionale Parameter definiert. Nicht übergebene optionale Parameter werden zur Laufzeit durch Default-Werte ersetzt.
Aufbereitungsoptionen in RPGWX-Prozeduren
Viele RPGWX-Prozeduren haben einen optionalen Parameter, mit dem die Aufbereitung des Feldes gesteuert werden kann.
Abhängig von der Feldart gibt es versicheidene Aufbereitungsoptionen:
- HTML-Dokumente
- Filter Felder
- Spalten in WRK-Tables
- Kontext-Menü-Punkte
- Buttons
- Detail-Anzeigen
- Header-Felder
Die Möglichkeiten zur Aufbereitung werden auf der Seite Aufbereitungsoptionen in RPGWX-Prozeduren beschrieben.
Standard-Bearbeitungs-Modi
Wird in Work-Programmen kein Kontext-Menü-Punkt und keine Buttons definiert, wird automatisch ein Kontext-Menü und ein Button mit den folgenden Standard-Optionen oder Modi hinzugefügt.
Die folgenden Standard Modi gesetzt werden:
- *ADD - Button → Erfassen (eines neuen Datensatzes)
- *CHANGE - Kontext-Menü → Ändern (des Datensatzes)
- *COPY - Kontext-Menü → Kopieren (des Datensatzes)
- *DELETE - Kontext-Menü → Löschen (des Datensatzes)
- *PROPERTY - Kontext-Menü → Anzeigen (des Datensatzes)
Die Standard-Optionen werden an das Folge-Programm übergeben und können über RPGWX-Prozeduren geprüft und ermittelt werden.
In den Folge-Programmen können die Standard-Modi, sowie alle anderen Modi, die in Kontext-Menüs oder über Buttons gesetzt werden mit RPGWX-Prozeduren geprüft und ermittelt werden.
In Change-Programmen werden automatisch Buttons mit den folgenden Standard-Optionen hinzugefügt:
- *SAVE - Sichern
- *APPLY - Übernehmen
- *REFRESH - Aktualisieren
Diese Standard-Modi können ebenfalls über RPGWX-Funktionen geprüft und ermittelt werden. Die Prüfung sollte jedoch erst nach Aufruf der RPGWX-Funktion Wx_GetChgInput() (ähnlich OpCode EXTFMT) erfolgen.
Bedingtes Anzeigen von Ein-/Ausgabe-Feldern
Für Filter-Felder und Ein-/Ausgabe-Felder in Change Tables können Bedingungen vordefiniert werden, unter denen die Felder angezeigt oder ausgeblendet werden.
Zur Definition der Bedingungen werden mehrere Möglichkeiten zur Verfügung gestellt:
Optionaler Parameter in RPGWX-Prozeduren
Alle Prozeduren, durch die Filter- oder Ein-/Ausgabe-Felder definiert werden können, haben einen optionalen Parameter, in dem die Bedingung unter der das Feld angezeigt werden soll, hinterlegt werden kann.
Condition Group
Die Condition Group besteht aus 3 Prozeduren:
- Wx_FltIf() für Filter-Felder und Wx_ChgIf() für Ein-/Ausgabe-Felder stellen den Beginn der Condition Group dar.
Über diese Prozeduren werden die Bedingungen festgelegt, unter denen die im Anschluss definierten Filter- oder Ein-/Ausgabe-Felder angezeigt werden sollen.
- Über die Prozeduren Wx_FltElse() für Filter-Felder und Wx_ChgElse() für Ein-/Ausgabe-Felder können die Else-Bedingungen definiert werden.
Der Aufruf der Else-Prozeduren ist nicht zwingend erforderlich.
Werden diese Else-Prozeduren ohne Parameter/Bedingung aufgerufen, werden alle im Anschluss definierten Filter- oder Ein-/Ausgabe-Felder nur dann angezeigt, wenn die in der If-Anweisung definierten Bedingungen nicht zutreffen.
Bei diesen Else-Prozeduren kann ebenfalls eine Bedingung hinterlegt werden und somit eine ElseIF-Anweisung generiert werden.
- Wx_FltEndIf() für Filter-Felder und Wx_ChgEndIf() für Ein-/Ausgabe-Felder beenden die Condition Group.
Der Aufruf der EndIf-Prozeduren ist zwingend erforderlich, um die Condition-Group zu beenden.
Zu jedem Aufruf einer RPGWX-IF-Funktion muss eine entsprechende RPGWX-EndIf aufgerufen werden.
Stimmt die Anzahl der IF- und ENDIF-Aufrufe nicht überein, tritt zur Laufzeit ein Fehler auf.
Condition Groups können verschachtelt werden, d.h. eine If-Anweisung innerhalb einer If- oder Else-Anweisung ist zulässig. Die Verschachtelung, sowie die Anzahl der IF- und ENDIF-Anweisungen werden zur Laufzeit geprüft.
Bedingungen
- Die Bedingungen können wahlweise in RPG, CL oder JavaScript-Schreibweise angegeben werden. Der angegebene Code wird in JavaScript konvertiert und zur Laufzeit ausgeführt.
- Nur Datei-Felder, die bereits in zuvor als Filter-Felder definiert wurden dürfen in den Bedingungen verwendet werden.
- Vergleichsoperatoren, wie =, >, <> etc. (RPG-Schreibweise) können ebenso angegeben werden, wie *EQ, *GT, *NE etc. (CL-Schreibweise) oder ==, >, != (JavaScript-Schreibweise)
- Logische Operatoren wie AND, OR, NOT (RPG) bzw. *AND, *OR, *NOT (CL) bzw. &&, ||, ! (JavaScript) können verwendet werden.
- Klammersetzung ist erlaubt
Beispiel für bedingte Filter-Felder
Wx_FltFld('BestNr': 'FLD0025': 'LikeLeft': 'uppercase'); Wx_FltIf('Firma = 10'); //1. If Wx_FltFld('LiefBed': 'FLD0029': '=': 'uppercase'); Wx_FltIf('LiefBed *EQ ''AW'''); //2. If Wx_FltFld('KundeNr': 'KundeNr': '=': 'uppercase'); Wx_FltEndIf(); //2. EndIf Wx_FltElse('Firma = 15'); //1. ElseIf Wx_FltFld('AuftrArt': 'FLD0027': '=': 'uppercase'); Wx_FltIf('%Subst(AuftrArt: 1: 1) = ''I'''); //2. If Wx_FltFld('Status': 'FLD0026': '=': 'ValuesList(''ERF'',''OPN'',''TEL'',''END'')': ''); Wx_FltElse('AuftrArt = ''EX'' *or AuftrArt = ''EA'' //2. ElseIf Wx_FltFld('LiefTerm': 'LieferTermin'); Wx_FltEndIf(); //2. EndIf Wx_FltEndIf(); //1. EndIf
Ergebnis bei Firma 10:
Ergebnis für Firma 15:
Bedienerhilfe
Für Ein-/Ausgabe-Felder können individuelle Bedienerhilfe-Texte definiert werden.
Default: Der Hilfe-Text der Feldüberschrift wird als Bedienerhilfe ausgegeben.
Die Bedienerhilfe kann zum einen über einen optionalen Parameter in allen Definitions-Funktionen für Change-Tables (z.B. Wx_ChgFld() oder Wx_ManChgFldChar()) angegeben werden.
Alternativ kann die Bedienerhilfe die Funktion Wx_ChgHelp() für einzelne Felder eingebunden werden.
Dabei kann wahlweise direkt ein Text oder eine Text-ID übergeben werden. Wird eine Text-ID übergeben wird per Default der Hilfetext dieser Text-ID ermittelt und als Hilfe-Text ausgegeben.
Default: Wurde weder ein Message-Text noch eine Text-ID angegeben, so wird, sofern eine Feldbeschreibung als Text-ID angegeben wurde der Hilfe-Text als Bedienerhilfe ausgegeben. Dieser Prozess erfolgt automatisch, ohne Angabe eines Schlüssel-Wortes.
Soll diese Automatik unterbunden werden, bzw. kein Hilfe-Text erwünscht sein, so kann in dem optionalen Parameter für die Bedienerhilfe der Sonderwert *NONE übergegeben werden. Das Hinzufügen der Bedienerhilfe kann ebenfalls durch den Aufruf der Funktion Wx_ChgNoHelp() entweder für ein einzelnes Feld oder alle Felder unterbunden werden.
Sofern für ein Ein/Ausgabe-Feld eine Bedienerhilfe vorliegt, wird die Ausgabe des Fragezeichen-Icons gekennzeichnet. Bei der Mouse Over-Aktion wird der Hilfe-Text angezeigt.
Abbildung 11: Bedienerhilfe in Change Programmen
Wx_ChgHelp – Bedienerhilfe hinzufügen
Mit Hilfe der Funktion Wx_ChgHelp können in Change-Programmen Hilfe-Texte zugewiesen werden.
Prototyp
***************************************************************************
P* Procedure name: Wx_ChgHelp
P* Purpose: Add individual help to a change field
P* If a Text-ID is passed the respective help text will
P* be used as help text
P* If a Message-Text is passed this text will be used as Hel
P* Returns:
P* Parameters: ParField => Field
P* Parameters: ParMsg => Help text or text id
P* Parameters: ParMsgTxt => Variable Message Texte
P* (Optional if a text id is specified)
***************************************************************************
D Wx_ChgHelp...
D PR OpDesc
D ParField Like(FldRef.NameSQL) Const
D Options(*Trim)
D ParMsg Like(FldRefCGI.Help) Const
D ParMsgTxt Like(FldRef.MsgText) Const
D Options(*NoPass: *Trim)
Source Code 24204: Prototype - Procedure Wx_ChgHelp - Bedienerhilfe hinzufügen
Parameter
- ParField - Eindeutige Kennung des Arbeitsfelds/Variable
- ParMsg - Bedienerhilfe oder Text-ID der Bedienerhilfe
Bedienerhilfe wird aus Level 2 Message-Text der Text-ID ermittelt
- ParMsgTxt - Variable Message-Textes
Sofern eine Text-ID übergeben wurde, können zusätzlich Variable Message-Texte (die die Platzhalter in dem Message-Text ersetzen angegeben werden)
Beispiele für den Aufruf
Wx_ChgHelp('ARTNR': 'ABC1234');
Wx_ChgHelp('ARTNR': 'ABC1234': MyFld1 + ' ' + MyFld2);
Wx_ChgHelp('KUNDENR': 'Dies ist ein Hilfetext für die Kunden-Nr. ');
Source Code 25205: Aufruf Prozedur Wx_ChgHelp() - Bedienerhilfe hinzufügen
Wx_ChgNoHelp – Bedienerhilfe unterbinden
Mit der Funktion Wx_ChgNoHelp() kann die automatische Ermittlung der Bedienerhilfe für einzelne Felder oder alle Felder unterbunden werden.
Prototyp
*************************************************************************
P* Procedure name: Wx_ChgNoHelp
P* Purpose: Prevents from adding automatic help texts
P* Returns:
P* Parameters: ParField => Field (Optional)
P* Not Passed or Special Value *ALL
P* No Help Text for any field
*************************************************************************
D Wx_ChgNoHelp...
D PR OpDesc
D ParField Like(FldRef.NameSQL) Const
D Options(*NoPass: *Trim)
Source Code 26206: Prototype Procedure Wx_ChgNoHelp - Automatische Ermittlung der Bedienerhilfe unterbinden
Parameter
- ParFieldEindeutige Kennung des Arbeitsfelds/Variable
(Optional)
Nicht übergeben oder Sonderwert *NONE Bedienerhilfe wird für alle Felder unterbunden
Beispiele für den Aufruf
Wx_ChgNoHelp('ARTNR');
Wx_ChgNoHelp();
Source Code 27207: Aufruf Procedure Wx_ChgNoHelp - Automatische Ermittlung der Bedienerhilfe unterbindenReihenfolge der Prozedur-Aufrufe
- Prüfen Verarbeitungs-Modi
Für Change Tables, um die im vorgelagerten Programm (z.B. Work Table) ausgelösten Aktionen (Kontext-Menü-Auswahl) zu ermitteln.
In Work Tables kann über Kontext-Menü-Auswahlen der Aufruf von Folge-Programmen gesteuert werden. Wurde für einen Kontext-Menü-Punkt ein Programm angegeben wird dieses direkt aufgerufen. Wurde nur eine eindeutige Kennung übergeben, kann diese im Folge-Programm über den Modus (bzw. über entsprechende RPGWX-Funktionen) geprüft und entsprechende Aktionen (z.B. Aufruf eines weiteren CGI-Programms) eingeleitet werden.
- Ermitteln von Schlüssel-Werten
Für Folge-Programme (Work- und Change-Programme), die aus List-Anzeigen/Work Tables aufgerufen werden.
Der eindeutige Schlüssel (oder die relative Satz-Nr.) wird bei Kontext-Menü-Auswahl bei Work-Programmen an das Folge-Programm übergeben. Diese Informationen sind erforderlich um z.B. den zu ändernden oder zu löschenden Datensatz einzulesen.
Der Aufruf ist nur erforderlich, wenn diese eindeutigen Schlüssel-Werte übergeben und im Folge-Programm verarbeitet werden.
- Ermitteln von Parameter-Werten
In Work- und Change Tables können bis zu 5 Parameter-Werte an das Folge-Programm übergeben werden.
Der Aufruf ist nur erforderlich, wenn die Parameter-Werte im Folge-Programm benötigt und verarbeitet werden.
- Öffnen/Zuordnen des HTML-Dokuments
Für Change und Work-Programme werden verschiedene Prozeduren vorgesehen. Basierend auf dem Prozedur-Aufruf werden die entsprechenden folgenden Schritte gesteuert.
- Definition von Header Informationen
Header-Informationen sind allgemein gültige Ausgabe-Informationen (z.B. Auftrags-Nr., Liefertermin bei Auftrags-Positionen). Header-Informationen können sowohl für Work- als auch Change Tables angegeben werden.
- Definition der verwendeten physischen Dateien, SQL Tabellen oder Views.
Sofern Header Informationen erforderlich sind, müssen die für die Header-Informationen erforderlichen Dateien/SQL Tabellen/Views vor den Header-Informationen definiert werden.
Sowohl bei Work- als auch bei Change Tables können mehrere Tabellen definiert werden. Während bei den Change Tables die Dateien/Tabellen/Views einzeln definiert werden können, muss bei Worktables die Verknüpfung zwischen den einzelnen Dateien/Tabellen/Views angegeben werden.
Um Probleme bei der Verknüpfung zu vermeiden wird empfohlen SQL Views zu definieren in denen die physischen Dateien/Tabellen bereits miteinander verknüpft wurden in die ggf. Where-Bedingungen integriert wurden (ähnlich Select/Omit-Anweisungen in DDS) um die Anzahl der Datensätze vorab zu selektieren.
- Definition der Filter-Felder (nur bei Work Tables)
Filter-Felder werden vor der eigentlichen List-Anzeige ausgegeben und ermöglichen eine selektive Auswahl der Daten.
Die Filter-Felder müssen in den zuvor definierten Dateien/Tabellen/Views enthalten sein.
Zur Selektion der Daten werden unterschiedliche Vergleichsoperatoren bereitgestellt.
Die Filter-Felder werden in der Reihenfolge in der sie definiert sind ausgegeben. Die Definition von Filter-Feldern ist in Work Tables nicht zwingend erforderlich.
- Definition der anzuzeigenden Spalten (bei Work Tables).
In Worktables wird zunächst die Spalte mit dem eindeutigen Schlüssel (für die Detail-Anzeige) definiert. Sofern sich der eindeutige Schlüssel aus mehreren Spalten/Feldern zusammensetzt oder sofern die Tabelle/Datei keinen eindeutigen Schlüssel hat, kann die Relative Satz-Nr. verwendet werden.
Die anzuzeigenden Spalten müssen in den zuvor definierten Dateien/Tabellen/Views hinterlegt sein. Der Programmierer kann diverse Aufbereitungsoptionen für die einzelnen Spalten definieren.
Die Spalten werden in der Reihenfolge in der sie definiert sind ausgegeben.
Mit Hilfe von Javascript-Funktionen können zur Laufzeit die Spalten am Bildschirm anders angeordnet werden.
- Definition der anzuzeigenden/bearbeitenden Felder (in Change Tables)
Die Felder, die in den Change Tables angezeigt bzw. bearbeitet werden können aus den zuvor definierten Dateien/Tabellen/Views kommen. Es ist jedoch auch möglich Arbeits- oder Hilfsfelder „frei" (ohne Datei-Bezug) zu definieren und zu verwalten.
Die Felder werden in der Reihenfolge in der sie definiert sind ausgegeben.
- Definition der Kontext-Menüs bei Work Tables
Für Work Tables können Kontext-Menüs definiert werden, d.h. es werden Programme oder Aktionen hinterlegt, die beim Klicken auf die entsprechende Auswahl ausgeführt werden.
Der RPGWX-Programmierer braucht lediglich das Kontext-Menü zu definieren, die Steuerung erfolgt durch Javascript-Funktionen, die zur Laufzeit ausgeführt werden.
Kontext-Menü-Auswahlen beziehen sich i.d.R. auf die ausgewählte Zeile/Datensatz. Für allgemeine Aktionen, können Buttons definiert werden.
- Definition von Buttons bei Work Tables und Change Tables
Für Work- und Change Tables können Buttons definiert werden, d.h. es werden Programme oder Aktionen vorgegeben, die beim Klicken auf den Button ausgeführt werden.
- Setzen von Parameter-Werten für das Folge-Programm
In Work- und Change Tables können bis zu 5 Parameter-Werte an das Folge-Programm übergeben werden.
Die Parameter-Werte sollten versorgt und übergeben werden, unmittelbar bevor das HTML-Dokument ausgegeben werden.
- Ausgabe des HTML-Dokuments bei Work Tables und Change Tables
Nachdem alle Felder definiert wurden, wird das Dokument ausgegeben.
Für Work-Programme endet die Verarbeitung mit der Ausgabe des HTML-Dokuments.
Für Change Tables endet das Programm (aufgrund der Stateless-Programmierung) ebenfalls an dieser Stelle. RPGWX steuert jedoch den Ablauf so, dass beim nächsten Zyklus das Programm an dieser Stelle fortgeführt wird.
- Eingabe-Prüfung und ggf. Ausgabe von Fehlermeldungen bei Change Tables
Die erfassten Daten werden an das RPGWX-Programm zurückgegeben.
Der RPGWX-Programmierer kann die üblichen Prüfungen codieren und ausführen.
Im Fehlerfall wird eine RPGWX-Funktion aufgerufen, die die Fehlermeldung ausgibt.
Sofern keine Fehler festgestellt wurden. Kann der RPGWX-Programmierer seine üblichen Datei-Verarbeitungen kodieren und ausführen.
Das Change Programm endet an dieser Stelle. Die Steuerung des Rücksprungs erfolgt automatisch durch RPGWX.
- Rücksprung auf das vorgelagerte Programm
Nach erfolgreicher Verarbeitung eines Change Tables, d.h. nach dem der zu bearbeitende Datensatz ordnungsgemäß fortgeschrieben wurde, muss auf das vorgelagerte Programm zurückgesprungen werden.
- Bedingte Anzeigen
Bedingte abhängige Anzeigen können über entsprechende Prozedur-Aufrufe, die JavaScript-Code erzeugen gesteuert werden. Der Aufruf der IF-Prozeduren muss 4.7vor (IF) und nach (ENDIF) dem Aufruf der unter bestimmten Bedingungen anzuzeigenden Felder erfolgen.
- Tabellen in Change Tables
Innerhalb von Change Tables können die Ein-/Ausgabe-Felder in Tabellen hinterlegt werden. Die Tabellen-Definition bzw. der Aufruf der entsprechenden RPGWX-Prozeduren erfolgt unmittelbar vor dem ersten (Ein/Ausgabe-)Feld innerhalb der Tabelle.
Physische Dateien, SQL Tabellen oder Views
Die physischen Dateien, SQL Tabellen oder SQL Views, in denen die zu verarbeitenden Daten hinterlegt sind müssen durch den Aufruf von RPGWX-Funktionen definiert werden.
Die Definition der Dateien/Tabellen/Views muss erfolgen bevor das erste Feld (Filter-Feld oder Spalte in Worktables oder Ein- oder Ausgabe-Feld in Change Tables) definiert wird.
Für Header-, Filter, Work Tables und Change Tables erfolgt die Definition der physischen Dateien/Tabellen/Views über unterschiedliche Funktionen. Bei der Definition muss die vorgeschriebene Verarbeitungsreihenfolge eingehalten werden, d.h. werden Filter definiert, muss die Funktion für Filter-Dateien/Tabellen/Views aufgerufen werden.
Werden in einem RPGWX-Programm unterschiedliche Darstellungsarten verwendet, z.B. Filter und List-Anzeige/Worktables, so müssen die Dateien/Tabellen/Views nur einmalig, für die Filter definiert werden. Für die List-Anzeige werden die registrierten Filter-Dateien/Tabellen/Views herangezogen.
Anmerkung: Physische Dateien/Tabellen/Views müssen innerhalb eines RPGWX-Programms nur einmalig, bevor das erste (Header-/Filter- oder Work-)Feld definiert wird angegeben werden.
DDS beschriebene logische Dateien
DDS beschriebene logische Dateien können angegeben und verarbeitet werden.
Aus Performance-Gründen ist die Verwendung von DDS beschriebenen logischen Dateien jedoch nicht zu empfehlen.
Directweb und RPGWX verwenden ausschließlich SQL. Der Query-Optimizer muss jede Abfrage, in der DDS beschriebene logische Dateien verwendet werden neu schreiben, basierend auf den zugrunde liegenden physischen Dateien/Tabellen.
Die Analyse der DDS beschriebenen logischen Dateien, sowie das anschließende Rewriting kann nur durch die alte/klassische Query Engine (CQE) erfolgen. Alle SQL-Statements in denen DDS beschriebene logische Dateien angegeben werden, müssen an die CQE zurückgegeben werden, was zwischen 10 und 15% Performance kosten kann. Die Vorteile der modularen und wesentlich flexibleren neuen Query Engine (SQE = SQL Query Engine) können nicht genutzt werden.
Anmerkung: Anstatt DDS beschriebene logische Dateien anzugeben, sollten entweder die zugrunde liegenden physischen Dateien/Tabellen oder (neu erstellte) SQL Views verwendet werden.
Dateien direkt verknüpfen oder SQL Views?
Mit RPGWX können mehrere Dateien/Tabellen/Views in dem gleichen List-Anzeige (Work Table) oder Detail-Verarbeitung (Change Table) definiert werden.
In Detail-Verarbeitungen/Change-Tables können die Dateien/Tabellen/Views einzeln und unabhängig voneinander definiert werden.
Für Listausgaben ist es jedoch erforderlich diese Dateien/Tabellen/Views miteinander zu verknüpfen. Die Art der Verknüpfung (z.B. Inner Join, Left/Right Outer Join, Exception Join, Full Join) sowie die Verknüpfung über Schlüssel-Felder muss vom Programmierer vorgegeben werden, da alle Abfragen und Verknüpfungen on the fly gebildet werden müssen.
Anmerkung: Um den individuellen RPGWX-Source Code so einfach wie möglich zu reduzieren, wird empfohlen SQL-Views anzulegen, in denen die gewünschten Dateien/Tabellen bereits miteinander verknüpft sind, und in denen ggf. sogar durch entsprechende Where-Bedingungen Daten von vornherein eliminiert werden.
SQL Views sind ungeschlüsselte logische Dateien. Da SQL Views immer ungeschlüsselt sind, können beliebig viele SQL Views angelegt werden ohne Auswirkungen auf die Performance befürchten zu müssen.
Datei- und Feld-Namen
Für alle Dateien, Tabellen und Views sowie für alle Felder und Spalten kann wahlweise der kurze (bis zu 10 Zeichen) System-Name oder der lange (bis 128 Zeichen) SQL Name angegeben werden.
Die Schreibweise kann in jeder beliebigen Kombination aus Groß- und Klein-Buchstaben erfolgen. Die Datei/Tabellen/View-Namen, sowie die Spalten/Feld-Namen werden von RPGWX in Groß-Buchstaben konvertiert.
Datenstrukturen und Ein-/Ausgabe-Felder
Datenaustausch zwischen HTML- und dem individuellen RPGWX-Programm findet vor allem in den Change Tables/Detail-Programmen statt. Der Datenaustausch erfolgt über die aufgerufenen RPGWX-Prozeduren.
Der Programmierer ist für das Einlesen und Fortschreiben seiner Daten selbst verantwortlich, d.h. der Programmierer
- liest den Datensatz ein (native I/O oder embedded SQL)
- übergibt die Daten über RPGWX-Funktionen an das Web-Programm
- erhält die erfassten/geänderten Daten über die RPGWX-Funktionen zurück
- prüft diese erfassten Daten
- gibt ggf. eine Fehlermeldung über RPGWX-Prozeduren aus
- schreibt den geprüften Datensatz fort
Um einen Datenaustausch von Daten mit jedem Datentypen in jeder zulässigen Länge zu ermöglichen, müssen Pointer auf die Daten an die RPGWX-Prozeduren übergeben werden.
RPGWX ermittelnt den Datentypen und die Länge der übergebenen Daten und konvertiert diese in ein alphanumerisches Web-Format. Die erfassten Daten werden von RPGWX in das Ausgangsformat zurückübersetzt.
Der RPG-Compiler konvertiert gezonte numerische Felder, die Dateien, die in den F-Bestimmungen definiert sind, sowie stand-alone gezont-numerische Variablen in gepackte numerische Felder. Werden gezonte numerische Felder jedoch in Datenstrukturen definiert, werden sie vom Compiler nicht konvertiert.
Anmerkung: Um Probleme beim Datenaustausch zu vermeiden, müssen alle Felder oder Variablen, über die Daten mit RPGWX ausgetauscht werden in Datenstrukturen hinterlegt werden.
Mehrsprachigkeit
Beim Aufruf von RPGWX-Prozeduren werden auch die anzuzeigenden Texte übergeben.
Die Prozeduren sind so gesteuert, dass wahlweise eine Text oder eine Text-ID übergeben werden kann. Die Message-File, aus der der Text ermittelt werden soll, wird abhängig von den Angaben beim Einrichten der Anwendung (6.1 Anwendung) bestimmt.
Work-Programm
Für Work-Programme stehen die folgenden RPGWX-Prozeduren zur Verfügung
Tabelle 3 : RPGWX-Prozeduren für Work-Programme
Für ein Work-Programm sind nicht immer alle RPGWX-Prozeduren erforderlich.
Der Aufruf der RPGWX-Prozeduren sollte jedoch (weitgehend) in der Reihenfolge, in der die Prozeduren aufgelistet sind erfolgen.
Die blau eingefärbten Prozeduren können sowohl in Work- als auch in Change-Tables aufgerufen werden. Die übrigen Prozeduren können nur in Verbindung mit Work-Tables verwendet werden.
In einem Work-Programm müssen die folgenden Schritte abgedeckt sein:
- HTML-Dokument öffnen (Prozedur Wx_OpnHTMLWrk())
- Dateien/Tabellen/Views definieren (Prozeduren Wx_FltFile() oder Wx_WrkFile())
- Spalte mit eindeutigem Schlüssel definieren (Prozedur Wx_WrkKey())
- Spalten für List-Anzeige definieren (Prozedur Wx_WrkFld())
- HTML-Dokument an Browser schicken (Prozedur Wx_WrtWrkTbl())
Template für Work-Programm
Ein Template für ein Work-Programm mit Copy-Strecke und den erforderlichen Prozedur-Aufrufen in der erforderlichen Reihenfolge befindet sich in:
- Bibliothek WOPIX
- Quellen-Datei QCPYLESRC
- Member EXWRKTEMP
Dieses Template kann kopiert und für die individuellen Work-Programme modifiziert werden.
Editierbare Worktables
Mit editierbaren Worktables ist es möglich, einzelne Spalten in der Listanzeige zum Ändern freizugeben.
Einzelne Spalten können durch Angabe des Schlüssel-Wortes Output bei Aufruf der Prozedur Wx_WrkFld() zur Änderung gesperrt werden. Editierbare und gesperrte Spalten werden farblich unterschiedlich dargestellt.
Die folgenden Funktionen werden zum programmieren editierbarer Worktables benötigt:
- Wx_WrkBtnEdtList() - Eine Listanzeige zum editieren freigeben. Dabei wird ein neue Button "Speichern" eingefügt.
- Wx_isModeEdtList() - Bei der Verarbeitung abfragen, ob die Listanzeige editierbar ist und ob Daten eingegeben/geändert wurden
- Wx_GetEdtListXML() - Die eingegebenen/geänderten Daten in eine Variable holen (die danach mit der RPG-Anweisung XML-INTO in eine XML-Struktur umgewandelt wird). Das XML-Dokument kann maximal 16350 Zeichen fassen.
Zur Behandlung von Eingabefehlern in der editierbaren Liste stehen diese beiden Funktionen zur Verfügung:
- Wx_WrkFldErr() - Fehler in einem Feld der editierbaren Worktable
Wx_MultWrkFldErr() – Fehler in einem oder mehreren Feldern der editierbaren Worktable
XML-Dokument für editierbare Worktables - Aufbau
Das XML-Dokument in dem die geänderten Werte ausgegeben werden hat den folgenden Aufbau:
- Root-Element
<rows>
in Kleinbuchstaben - Zeilen-Element
<row>
in Kleinbuchstaben
Spalten-Elemente (innerhalb von <row> ... </row>)
Unterhalb des Zeilen-Elements <row>
befinden sich die Spalten-Elemente
- Das erste Spalten-Element
- das erste Element in jeder Zeile (row) der XML-Tabelle ist die <ID>
- Bei der ID es sich um den eindeutigen Schlüssel in der List-Anzeige.
- wurde der Schlüssel, so wie er für die List-Anzeige definiert wurde.
- wurde der Schlüssel
Wx_WrkKeyRRN()
definiert, dann enthält die Id die relative Satz-Nr. der Tabelle. - wurde der Schlüssel mit
Wx_WrkKeyFld()
definiert, dann enthält die Spalte entweder einen einzelnen Schlüssel-Wert (z.B. Id) oder bei mehrfachem Aufruf der FunktionWx_WrkKeyFld
() einen zusammengesetzten Schlüssel.
- Bei den weiteren Spalten-Elemente handelt es sich um die Spalten, die mit der Funktion
Wx_WrkFld()
beim Erstellen der List-Anzeigen definiert wurden.- sofern die Datensätze automatisch upgedated werden sollen, müssen die Spalten-Namen den Feld/Spalten-Namen in der Tabelle entsprechen.
Die Spalten-Element-Namen werden in Groß-Buchstaben ausgeben.
<?xml version="1.0"?>
<rows>
<row>
<ID>111</ID>
<SPALTE1>Zeile 1 / Spalte 1</SPALTE1>
<SPALTE2>Zeile 1 / Spalte 2</SPALTE2>
... weitere Spalten
</row>
<row>
<ID>112</ID>
<SPALTE1>Zeile 2 / Spalte 1</SPALTE1>
<SPALTE2>Zeile 2 / Spalte 2</SPALTE21>
... weitere Spalten </row>
... weitere Zeilen
</rows>
Das folgende Schaubild zeigt ein XML-Dokument, das nach der Änderung in der Worktable ausgegeben wurde. Außerdem wird der RPG-Code mit dem die Spalten in der Worktable definiert wurden angezeigt.
Verarbeitung der eingegeben/geänderten Daten in einer editierbaren Worktable
Zur Verarbeitung der eingegebenen oder geänderten Sätze in der editierbaren Worktable müssen diese Daten mit der Funktion Wx_GetEdtListXML() und dem RPG-Befehl XML-INTO in eine Datenstruktur eingelesen werden. Diese Datenstruktur kann dann in einer for.. Schleife verarbeitet werden.
Für die Verarbeitung der Datenstruktur gibt es grob zwei Möglichkeiten:
- Variante A) - die Daten müssen mit XML-INTO in eine Datenstruktur gelesen werden, die dem Aufbau der XML-Daten entspricht. Die weitere Verarbeitung wird vom Programmierer auskodiert.
- Variante B) - weil viele der Programmschritte immer dieselben sind, steht das Programm WXUPDXML zur Verfügung. Es erstellt eine SQL-Anweisung für den UPDATE/INSERT der Daten. Diese Variante ist einfacher in der Handhabung aber natürlich etwas eingeschränkt gegenüber der "freien" Programmierung.
- Bei dieser Methode ist zu beachten, dass der Schlüssel die relative Satz-Nr. in der Tabelle/physischen Datei sein muss.
- Ein Update von Views ist nur möglich, wenn die View den eindeutigen Schlüssel der Tabelle/physischen Datei beinhaltet und die View auch updatebar (also z.B. nicht gejoint ist oder keinen Group By enthält).
- Die mit
Wx_WrkFld()
definierten Spalten-Namen müssen den Spalten-Namen in der physischen Datei entsprechen und nur existerende Spalten können auch (automatisch) upgedated werden.
- Der Programmierer muss sich bewusst sein, dass mit der Variante b) Updates/Inserts direkt in seine Tabellen/Dateien gemacht werden!
A) "RPG-Code zur Verarbeitung der geänderten Sätze über eine XML-Tabelle
Zum Empfangen der XML-Daten muss eine Datenstruktur angelegt werden, die der Struktur der XML-Daten (s.o.) entspricht, d.h. die Datenstruktur, um die in dem vorherigen Beispiel angezeigten XML-Daten empfangen zu können muss die Datenstruktur wie folgt aussehen.
Die Id, sowie die Spalten/Elemente müssen zunächst in einer Referenz-Datenstruktur hinterlegt werden. Die Spalten/Element und Datenstruktur-Unterfeld-Namen müssen identisch sein.
Da Spalten/Element-Namen und Datenstruktur- bzw. Datenstruktur-Unterfeld-Namen für die Verarbeitung des XML-Dokuments identisch sein müssen, muss die empfangende Datenstruktur rows heißen.
Diese Datenstruktur benötigt ein für jede Zeile ein Datenstruktur-Unterfeld mit dem Namen row und dem Aufbau Referenz-Datenstruktur. Die Definition des Unterfeldes row erfolgt mit Hilfe des Schlüssel-Wortes LIKEDS und maximale Anzahl der empfangenden Datensätze wird über das Schlüssel-Wort DIM festgelegt.
Die XML-Daten werden zunächst mit der Funktion WX_GetEdtListXML() in einer alphanumerischen Variablen empfangen. Mit dem RPG-OpCode XML-INTO werden die Daten in der alphanumerischen Variablen aufgelöst und in die zuvor definierte XML-Datenstruktur übernommen.
Da die Element-Namen z.T. in Groß-Buchstaben und z.T. in kleinen Buchstaben ausgegeben werden, muss die Option case=any in der Funktion %XML angegeben werden.
Da außerdem nicht immer die maximale Anzahl an Datensätzen empfangen wird und die Datenstruktur außerdem noch andere Datenstruktur-Unterfelder enthalten könnte, müssen die Optionen allowmissing=yes und allowextra=yes ebenfalls angegeben werden.
B) Verarbeitung der geänderten Sätze mit dem Programm WXUPDXML
Das Programm WXUPDXML erstellt einen SQL-Befehl, mit dem die eingegebenen/geänderten Daten direkt in die Tabelle/Datei schreibt, die in den ersten beiden Parametern angegeben ist.
Es verwendet die Relative Record Number (RRN) zum identifzieren der zu ändernden Sätze.
Deshalb muss das erste Feld in der Datenstruktur (das "ID"-Feld) zwingend die RRN der Datei sein.
Es ist nicht möglich, ein anderes eindeutiges Feld, wie z.B. die Kundennummer oder einen zusammengesetzen Schlüssel als ID-Feld zu verwenden.
WXUPDXML kann nicht verwendet werden, wenn
- Wenn die Daten vor dem UPDATE oder INSERT geprüft werden sollen
- Wenn die Worktable auf einer nicht updatebaren View basiert
- Wenn die Worktable auf einer updatebaren View basiert, die jedoch nicht die relative Satz-Nr. der Basis-Tabelle enthält
Die eingegebenen Daten werden keiner weiteren Prüfung unterzogen
Es ist zu bachten, dass das Program WXUPDXML die Daten ohne weitere Prüfung in die Datenbank schreibt. Sofern sich auf den Spalten entsprechende Prüf-Constraints befinden oder referentielle Integritäten definiert sind, werden diese geprüft und ggf. der Datensatz nicht fortgeschrieben.
Fehlerbehandlung in editerbaren Worktables
Die erfassten Daten werden über ein XML-Dokument (bzw. XML-INTO) in die RPGWX-Programme zurückgebracht.
In diesen Programmen können die erfassten Werte geprüft und sofern alles korrekt ist fortgeschrieben werden.
Im Fehlerfall können für die Fehlerhaften Eingaben Fehlermeldungen ausgegeben werden. Zu diesm Zweck kann eine der beiden folgenden Funktionen verwendet werden:
- Wx_WrkFldErr() - Fehler in einem Feld der editierbaren Worktable
Wx_MultWrkFldErr() – Fehler in einem oder mehreren Feldern der editierbaren Worktable
Die fehlerhaften Felder werden mit einem Icon markiert und farblich anders dargestellt.
Der Fehler-Text wird durch eine Mouse-Over-Aktion über dem fehlerhaften Feld in Form eines Tooltips sichtbargemacht.
Direkter Aufruf von CGI-Programmen
CGI-Programme können nicht über die RPG-OpCodes CALL oder CALLP aufgerufen werden. Um den Aufruf von CGI-Programmen aus anderen CGI-Programmen zu erleichtern wurden Prozeduren eingeführt, die den OpCodes nachempfunden wurden.
Der direkte Aufruf von CGI-Programmen ist z.B. in Change-Programmen erforderlich, sofern der Modus eine eindeutige Kennung ist, jedoch keinem Programm-Namen entspricht.
Ebenso könnte sein, dass unter einer bestimmten Bedingung (Auftrags-Kopf wurde zwar ausgewählt, jedoch zwischenzeitlich vom Kollegen gelöscht) ein anderes CGI-Programm (z.B. Erfassung Auftrags-Daten) ausgeführt werden soll.
Der direkte Aufruf von CGI-Programmen erfolgt über Prozedur Wx_CallPGM().
Achtung: Da aus einem CGI-Programm ein anderes CGI-Programm aufgerufen wird, und ein CGI-Programm nach der Ausgabe an den Browser beendet wird, wird auch das rufende Programm beendet.
Wx_CallPGM() – Direkter Aufruf CGI-Programm
Die Prozedur Wx_CallPGM() generiert die URL, die für den Aufruf erforderlich ist und initiiert den Aufruf.
An die Prozedur Wx_CallPGM wird der Name des aufzurufenden Programms übergeben. Weiterhin können bis zu 5 Parameter-Werte übergeben werden.
Prototype
***************************************************************************
P* Procedure name: Wx_CallPGM
P* Purpose: Call Next CGI Program with Single Parameters
P* Returns: URL
P* Parameters: ParPGM => Program
P* Parameters: ParParm1 => Parameter 1 (Optional)
P* Parameters: ParParm2 => Parameter 2 (Optional)
P* Parameters: ParParm3 => Parameter 3 (Optional)
P* Parameters: ParParm4 => Parameter 4 (Optional)
P* Parameters: ParParm5 => Parameter 5 (Optional)
***************************************************************************
D Wx_CallPGM...
D PR OpDesc
D ParPGM Like(FldRef.PGM) Const
D ParParm1 Like(FldRef.TextVAR) Const
D Options(*NoPass)
D ParParm2 Like(FldRef.TextVAR) Const
D Options(*NoPass)
D ParParm3 Like(FldRef.TextVAR) Const
D Options(*NoPass)
D ParParm4 Like(FldRef.TextVAR) Const
D Options(*NoPass)
D ParParm5 Like(FldRef.TextVAR) Const
D Options(*NoPass)
D ParMode Like(FldRef.ModeChar) Const
D Options(*NoPass)
Source Code 238204: Prototype Prozedur Wx_CallPGM - Direkter Aufruf CGI Programm
Parameter
- ParPGMName des aufzurufenden Programms
Bibliothek kann nicht angegeben werden.
- ParParam1- ParParam5 Alphanumerischer Parameter-Wert
Optionaler Parameter
Es können bis zu 5 alphanumerische Parameter-Werte übergeben werden. Diese Parameter-Werte können in dem Folge-Programm verwendet werden.
Anstatt die gewünschten Parameter-Werte über die Funktion Wx_CallPGM() zu setzen, ist es auch möglich die Werte über durch Aufruf einer der Funktionen Wx_SetParmXXXX zu setzen (vergl. 3.13 Ermitteln und Setzen von Parameter-Werten)
Beispiele für den Aufruf
If GblKGID = *Zeros;
Wx_CallPGM('KXWRKNGR');
ElseIf Wx_isMode('TEILN');
Wx_CallPGM('KXWRKKOTN': %Char(GblKGID));
ElseIf Wx_isMode('UMSATZ');
Wx_CallPGM('KXUMSATZ': %Char(GblJAHR), GblDs.KundeNr, Wx_GetParmChar(3));
EndIf;
Source Code 239205: Aufruf Prozedur - Wx_CallPGM - Direkter Aufruf CGI Programm
Sonstige Funktionen
In RPGWX sind auch einige allgemein gültige und einsetzbare Prozeduren/Funktionen enthalten.
Wx_SplitStringArr() – String in Feldgruppe splitten
Über die Funktion Wx_SplitStringArr kann ein Textstring, in dem die einzelnen Werte durch ein beliebiges Trennzeichen getrennt sind in eine Feldgruppe ausgegeben werden.
Aktuell kann ein Text in bis zu 256 Elemente mit einer Länge von maximal 256 Zeichen aufgeteilt werden.
Längere Element-Texte werden ohne Warnung abgeschnitten.
Enthält der String mehr als 256 Elemente wird eine entsprechende Escape Message ausgegeben, d.h. die Prozedur bricht ab. Der Fehler kann über eine Monitor-Group abgefangen werden.
Prototype
***************************************************************************
// Procedure name: WX_SplitStringArr
// Purpose: Split String into Array Elements depending on the
// passed separator
// Texts longer than the Element length will be truncated
// without any warning
// --> An escape message is sent if more elements are available
// Returns: Array with the split texts
// Parameter: ParString => String
// Parameter: ParSep => Separator
// Parameter: ParEmpty => Empty Fields = Return an empty Element
// *ON = Empty Element
*--------------------------------------------------------------------------
* Attention: Maximum 256 Elements with 256 Characters
***************************************************************************
D Wx_SplitStringArr...
D PR Like(FldRef.TextVar) OpDesc
D Dim(RefElemText)
D ParString Like(FldRefLA.VarLen) Const
D ParSep Like(FldRef.Sep) Const
D POutNbrElem 10U 0 Options(*NoPass)
D ParEmpty N Options(*NoPass) Const
Source Code 310276: Prototype - Funktion Wx_SplitStringArr - Text in Feldgruppe aufsplitten
Parameter
- Rückgabe-Wert Feldgruppe mit dem aufgesplitteten Text
Bis zu 256 Elemente mit einer Länge von maximal 256 Zeichen
- ParStringText-String, der aufgesplittet werden soll
- ParSepTrennzeichen
Abhängig von dem angegeben Trennzeichen wird der String aufgesplittet.
Jedes beliebige Zeichen kann angegeben werden.
- POutNbrElements Ausgabe-Parameter Anzahl Elemente
Optionaler Parameter
Muss als Unsigned Integer-Variable (10U 0) definiert werden
- ParEmptyAusgabe von leeren Elementen
Optionaler Parameter
Sofern mehrere Trennzeichen unmittelbar aufeinander folgen, kann über diesen Parameter gesteuert werden, ob leere Elemente ausgegeben werden sollen.
Sofern der Parameter nicht angegeben wurde oder mit *OFF übergeben wurde, werden keine leeren Elemente ausgegeben, d.h. die Ausgabe-Feldgruppe enthält nur gefüllte Elemente (und leere Elemente am Ende)
Leere Elemente können z.B. hilfreich sein, wenn *.csv-Dateien in Spalten aufgeteilt werden müssen.
Beispiele für den Aufruf
D GblText S 1024A Varying
D GblArrChar S Like(FldRef.TextVar) Dim(RefElemText)
D GblElem S 10U 0
D ConstSep C Const('|')
*------------------------------------------------------------------------------
/Free
GblArrChar = Wx_SplitStringArr(GblText: ';');
GblArrChar = Wx_SplitStringArr(GblText: ConstSep: GblElem);
GblArrChar = Wx_SplitSTringArr(GblText: ';': GblElem: *ON);
For GblIndex = 1 To GblElem;
//Verarbeitung
EndFor;
/End-Free
Source Code 311277: Aufruf - Funktion Wx_SplitStringArr() - Text in Feldgruppe aufsplitten
Wx_SplitStringArrUC2() – Unicode-Test in Feldgruppe splitten
Über die Funktion Wx_SplitStringArrUC2 kann ein Textstring in Double-Byte-Unicode (RPG Datentyp C), in dem die einzelnen Werte durch ein beliebiges Double-Byte-Unicode-Trennzeichen getrennt sind in eine Feldgruppe ausgegeben werden.
Aktuell kann ein Text in bis zu 256 Elemente mit einer Länge von maximal 256 Double-Byte-Unicode-Zeichen aufgeteilt werden.
Längere Element-Texte werden ohne Warnung abgeschnitten.
Enthält der String mehr als 256 Elemente wird eine entsprechende Escape Message ausgegeben, d.h. die Prozedur bricht ab. Der Fehler kann über eine Monitor-Group abgefangen werden.
Prototype
***************************************************************************
// Procedure name: WX_SplitStringArrUC2
// Purpose: Split Unicode String into Unicode Array Elements depending
// on the passed separator
// Texts longer than the Element length will be truncated
// --> An escape message is sent if more elements are available
// Returns: Array with the split texts
// Parameter: ParString => String
// Parameter: ParSep => Separator
// Parameter: ParEmpty => Empty Fields = Return an empty Element
// *ON = Empty Element
*--------------------------------------------------------------------------
* Attention: Maximum 256 Elements with 256 Characters
***************************************************************************
D Wx_SplitStringArrUC2...
D PR Like(FldRef.UCVar) OpDesc
D Dim(RefElemText)
D ParString Like(FldRefLU.VarLen) Const
D ParSep Like(FldRef.SepUC) Const
D POutNbrElem 10U 0 Options(*NoPass)
D ParEmpty N Options(*NoPass) Const
Source Code 312278: Prototype - Funktion Wx_SplitStringArrUC2 – Unicode-Text in Feldgruppe aufsplitten
Parameter
- Rückgabe-Wert Feldgruppe mit dem aufgesplitteten Text
Bis zu 256 Elemente mit einer Länge von maximal 256 Zeichen
- ParString Unicode-Text-String, der aufgesplittet werden soll
- ParSep Unicode-Trennzeichen
Abhängig von dem angegeben Trennzeichen wird der String aufgesplittet.
Jedes beliebige Zeichen kann angegeben werden.
- POutNbrElements Ausgabe-Parameter Anzahl Elemente
Optionaler Parameter
Muss als Unsigned Integer-Variable (10U 0) definiert werden
- ParEmptyAusgabe von leeren Elementen
Optionaler Parameter
Sofern mehrere Trennzeichen unmittelbar aufeinander folgen, kann über diesen Parameter gesteuert werden, ob leere Elemente ausgegeben werden sollen.
Sofern der Parameter nicht angegeben wurde oder mit *OFF übergeben wurde, werden keine leeren Elemente ausgegeben, d.h. die Ausgabe-Feldgruppe enthält nur gefüllte Elemente (und leere Elemente am Ende)
Beispiele für den Aufruf
D GblText S 4096C Varying
D GblArrChar S Like(FldRef.UCVar) Dim(RefElemText)
D GblElem S 10U 0
D ConstSep C Const(%UCS2('|'))
*-----------------------------------------------------------------------------
/Free
GblArrChar = Wx_SplitStringArrUC2(GblText: ';');
GblArrChar = Wx_SplitStringArrUC2(GblText: ConstSep: GblElem);
GblArrChar = Wx_SplitSTringArrUC2(GblText: ';': GblElem: *ON);
For GblIndex = 1 To GblElem;
//Verarbeitung
EndFor;
/End-Free
Source Code 313279: Aufruf - Funktion Wx_SplitStringArrUC2() – Unicode-Text in Feldgruppe aufsplitten
Referenztabellen
Gültige Datentypen in RPGWX
Der Datentyp kann in DDS/RPG oder SQL-Schreibweise angegeben werden.
Char / A | alphanumerisch mit fixer Länge | Single Byte Charcter Set (SBCS) |
VarChar / A + Option Varying | alphanumerisch mit variabler Länge | Single Byte Character Set (SBCS) |
Graphic / C | Unicode mit fixer Länge | Double Byte Character Set (DBCS) CCSID 13488 |
VarGraphic / C + Option Varying | Unicode mit variabler Länge | Double Byte Character Set (DBCS) CCSID 13488 |
Decimal / P | gepackt numerisch | |
Numeric /S | gezont numerisch | |
SmallInt / Integer / Bigint / I | ganzzahlig/Integer | |
Float / Double / F | Fließkomma | |
Date / D | Datum | |
Time / T | Zeit | |
Timestamp | Zeitmarke |