home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Chip Hitware 3
/
Chip_Hitware_Vol_03.iso
/
chiphit3
/
dfu
/
wxbtx
/
winapi.new
< prev
next >
Wrap
Text File
|
1995-06-12
|
45KB
|
1,018 lines
WXBtx (ab Version 2.10) Erweiterungen/Änderungen zur WINAPI Spezifikation:
Die Originalspezifikation ist bei der Deutschen Telekom AG unter
der Seitennummer *10440170# als Telesoftware zu laden.
1.)
Die "Text:" WM_DDE_REQUEST und WM_DDE_ADVISE Message läßt einen
weiteren Parameter zu. Dieser bedeutet dann die Anzahl der Bild-
schirmzeilen (Höhe). Zeilen sind dabei durch CR/LF getrennt
(gemäß dem Clipboard Standard) und können auch (entgegen der
Spezifikation) bis zu 80 Zeichen lang sein, wenn eine 80-Zeichen
Seite dargestellt wird und eine entsprechende Anforderung vorliegt.
Enthält die WM_DDE_REQUEST oder WM_DDE_ADVISE Message das Clipboard-
Format CF_OEMTEXT, wird der entsprechende Ausschnitt des Btx-Fensters
im OEM-Zeichensatz aufbereitet. Dieser enthält unter anderem
auch Näherungen für Linien- und Blockgrafik, griechische Symbole
usw. CF_OEMTEXT liefert also mehr Information als CF_TEXT mit
einem anschließendem AnsiToOem-Aufruf!
Sind nur drei Parameter angegeben, wird nur eine Zeile ausgegeben,
die auch, entsprechend der Spezifikation, kein CR/LF am Ende enthält.
Abwärtskompatibilität ist also auf jeden Fall gegeben.
2.)
Zur Erleichterung der Auswertung von "AdeCount" bzw. "ErAdeCount"
gibt es zwei Kommandos "AdeDelta" bzw. "ErAdeDelta". Sie liefern
jedem Client unabhängig die Anzahl der eingegangenen ADEs bzw.
ERADEs seit der letzten Abfrage, also bei WM_DDE_ADVISE im Normal-
fall 1 (außer evtl. beim ersten Auftreten eines ADVISE).
3.)
Die Kodierung der Darstellungsattribute gem. Anhang A wurde auf der
Position 0 um die möglichen Werte 4,5 und 6 erweitert.
Diese Werte stehen für Zeichen aus dem PC-Zeichensatz (OEM) im Falle
der Darstellung einer ANSI:VT100 Seite.
Dabei werden die Zeichen 0x00 bis 0x5F auf Zeichensatz 4 abgebildet;
0x60 bis 0xBF auf Zeichensatz 5 und 0xC0 bis 0xFF auf Zeichensatz 6.
Der Zeichencode an Position 1 (von 2/0 bis 7/15) gibt dabei dann den
Offset in die jeweilige Tabelle an - Zeichensatz 4 und Zeichen 2/1
entspricht also dem PC-Zeichen 0x01 (smiley) und nicht etwa 0x21!
Für die Datex-J VT100 Darstellung wäre das nicht nötig, da dort nur
ein 7 Bit Zeichensatz zwischen 0x20 und 0x7F definiert ist,
jedoch unterstützt WXBtx die ANSI-Darstellung mit dem PC-Zeichensatz
um auch mit Mailboxen einen Datenaustausch zu ermöglichen.
Die Zeichencodes 6, 6/0 bis 7/15 sind nicht verwendet (da 0xC0 bis
0xFF nur 64 Werte sind, was 2/0 bis 5/15 entspricht).
4.)
Die "Colours" WM_DDE_REQUEST oder WM_DDE_ADVISE Message ist nicht
genau spezifiziert, was die Anzahl der Farben in der Palette angeht.
WXBtx bereitet nur die 16 definierbaren Farben auf, da die ersten 16
von vornherein durch die CEPT-Spezifikation festgelegt sind.
WXBtx versteht zusätzlich zum definierten Clipboard-Format CF_PALETTE
auch CF_TEXT. Dann werden die 16 Farben als ein String mit 48 hexa-
dezimalen Digits ausgegeben. Für jede Farbe 3 Digits jeweils für
Rot, Grün und Blau. So bedeutet z.B. "000" Schwarz, "FF0" Hellgelb
und "777" ein mittleres Grau.
5.) /* noch nicht implementiert */
Die "Drcs:<which>" WM_DDE_REQUEST oder WM_DDE_ADVISE Message ist
gänzlich unspezifiziert hinsichtlich der Bedeutung von <which>.
Derzeit ist sie noch nicht implementiert.
6.) /* WM_DDE_EXECUTE [Format(x,y,z)] noch nicht implementiert */
Ein neuer Befehl "Format" WM_DDE_REQUEST oder WM_DDE_ADVISE informiert
den Client über das Bildschirmformat. Er liefert drei Werte: Spalten,
Zeilen, Modus: Spalten kann dabei 40 oder 80 sein, Zeilen 20 oder
24 (80,20 ist nicht definiert) und Modus kann entweder "CEPT1", "ANSI"
oder "VT100" gemäß der Spezifikation bei "Facilities" sein.
Der Unterschied zwischen "ANSI" und "VT100" bezieht sich auf die
Interpretation der Zeichencodes 5/11, 5/12, 5/13 und 7/11, 7/12, 7/13
sowie 7/14. Telekom verwendet diese Zeichen als deutsche Umlaute
(Ä,Ö,Ü,ä,ö,ü,ß), in üblichen Mailboxen wird jedoch ein 8-Bit Zeichen-
satz gemäß dem IBM-Standard verwendet. Dort liegen die deutschen
Umlaute auf Zeichencodes der oberen 128 Zeichen und auf den angegebenen
Positionen liegen die US-ASCII Zeichen ([,\,],{,|,},~).
"[Format(x,y,m)]" steht auch als WM_DDE_EXECUTE zur Verfügung.
Dabei wird der Dekoder in den entsprechenden Modus versetzt.
Achtung!!!
Die Umschaltung zwischen CEPT1 und ANSI, VT100 ist nur bei
bestehender Datex-J Verbindung von Dauer und geschieht dann
über die Systemseite *707#. Leider scheint es unmöglich, eine
VT100 Anwahl bei ISDN durchzuführen, zumindest ist es mir bislang
nicht gelungen.
Ein Umschaltversuch auf 80,20 wird mit einem Fehler WM_DDE_ACK
quittiert und auch 40,20 ist nur bis zum nächsten von Seitenaufbau
von Dauer, falls dieser eine "Format Default" Sequenz enthält.
7.)
Ergänzend zu "Error" WM_DDE_REQUEST/WM_DDE_ADVISE existiert ein
Element "Info", welches bei erfolgreichen Operationen (insbesondere
bei WM_DDE_EXECUTE Kommandos) zusätzliche Informationen liefert.
8.)
Der Befehl "Connection" WM_DDE_REQUEST/WM_DDE_ADVISE liefert außer
"disconnected" und "connected" noch die Zustände:
"dialing" während einer Anwahl
"login" nach erfolgreicher Anwahl, während Warten auf Login
"busy" bei Dekoder-Aktivität (Makros etc.)
"closing" während einer Abwahl
Die Bedeutung von "connected" nach der WINAPI-Dokumentation ent-
spricht also einem `vollständig verbunden` inclusive Login.
9.) /* noch nicht implementiert */
WXBtx versteht eine ganze Reihe WM_DDE_POKES zu den entsprechenden
WM_DDE_REQUEST/WM_DDE_ADVISE Messages, mit entsprechenden Werten
und Auswirkungen im Dekoder. Im einzelnen lassen sich "poken":
"Mem:<z>,<s>,<size>"
setzt die entsprechenden Zeichenpositionen auf die angegebenen
Werte für Font, Zeichencode, Diakrit, Farben und Attribute.
"Drcs:<which>"
definiert DRCS entsprechend der Definition für die WM_DDE_REQUEST/
WM_DDE_ADVISE Messages.
"Colours"
setzt die Palette.
"Dclut"
setzt die 4 Indizes für 4-Farb-DCRS.
"FullRow"
setzt die Zeilen-Hintergrundfarben und die Bildschirmhintergundfarbe.
10.)
Außer den definierten Strings "RcvData:..." für WM_DDE_ADVISE
stehen zusätzlich die Strings "RcvIsdn:..." zur Verfügung.
Bei diesen ist die Bedeutung des Bytes rdFlags näher an der
Dokumentation zu BTX-ISDN-Headern und damit abweichend von den
in der WINAPI-Dokumentation verwendeten Bitmasken wie folgt:
#define RDF_RAW 0 /* raw data */
#define RDF_SCRN 1 /* screen data */
#define RDF_TFID 2 /* terminal facility identifier */
#define RDF_TDIO 4 /* transparent data */
#define RDF_BULK 8 /* bulk data */
#define RDF_MORE 16 /* more data (combined with RDF_TDIO/RDF_BULK) */
Das BTX-ISDN-Header Format verwendet 2 Bytes, "Type" und "Control",
wobei "Control" aber praktisch nur zur Unterscheidung zwischen "more"
und "last" Datenblöcken bei transparenten Daten und Bulk Daten dient.
Dieses eine Bit (Bit 0 von "Control") ist hier in RDF_MORE abgebildet.
Die Werte RDF_TFID und RDF_BULK treten dabei nur bei tatsächlichen
ISDN-Verbindungen auf! Bei Layer-2 (Modem-Verbindung) kommen die
TFIs ebenfalls als RDF_SCRN und Reverse-Bulk-Daten als RDF_TDIO,
da sie durch den Dekoder im Layer-2 nicht zu unterscheiden sind.
Die RDF_TDIO Blocks sind aber dennoch mit RDF_MORE kombiniert,
falls der jeweilige Datenblock im Layer-2 mit DLE/ETB empfangen wurde,
was genau der Bedeutung des "more" in den BTX-ISDN-Headern entspricht.
Transparente Layer-2 Daten enden "endgültig" mit DLE/ETX.
Die "RcvIsdn:..." Messages sind also durchaus auch bei Modem-
Verbindung möglich, es unterscheidet sich nur der Inhalt der
RDF_RAW Daten bei ISDN- und Modem-Verbindungen!
Nebenbemerkung:
Soweit mir bekannt ist, findet bei den neuen "schnellen" Zugängen
kein Protokoll nach "Layer-2" mehr statt, außer im Falle der
Übertragung von transparenten Daten. Das ist u.U. bei der Auswertung
von RDF_RAW zu beachten, indem ein korrekter Layer-2 Dekoder auch
einen ungeblockten "Screen" Datenstrom akzeptiert. Das Handling
dieser Schicht wird ohnehin im Dekoder vorgenommen, sodaß nur
gültige Layer-2 Datenblöcke in den RDF_RAW Datenstrom eingehen.
Fehlerhafte Blockprüfsummen etc. werden vom Dekoder direkt
abgelehnt und gehen erst garnicht an den Client!
11.)
Zur Vereinfachung und schnelleren Abarbeitung von Sendedaten gibt
es außer dem in WINAPI definierten Konstrukt aus WM_DDE_POKE "SendBuf"
mit anschließendem WM_DDE_EXECUTE "[Send(len)]", "[SendTrans(len)]"
oder "[SendBulk(len)]" ein neues WM_DDE_POKE "SndIsdn".
Dieses erwartet im Datenbereich pData->Value[] eine Struktur ganz
entsprechend den "RcvIsdn:..." WM_DDE_REQUEST/WM_DDE_ADVISE Messages,
also im ersten WORD die Länge des Datenblockes, danach in einem
BYTE den Datenblock-Typ gefolgt von den eigentlichen Daten.
Die C-Struktur sieht so aus:
/* Sendedaten in WM_DDE_POKE Message */
/* (struct SndData *)pData.Value */
struct SndData {
WORD sdDataLen;
BYTE sdFlags;
BYTE sdBuffer[];
};
Die Daten werden direkt bei WM_DDE_POKE gesendet und der zugehörige
HGLOBAL wird (wenn der Client es über pData.fRelease anzeigt)
auch sofort wieder freigegeben.
Das sdFlags BYTE entspricht dabei dem rdFlags BYTE in den "RcvIsdn:..."
Messages, hat also folgende Bedeutungen:
#define SDF_RAW 0 /* raw data */
#define SDF_SCRN 1 /* screen data */
#define SDF_TFID 2 /* terminal facility identifier */
#define SDF_TDIO 4 /* transparent data */
#define SDF_BULK 8 /* bulk data */
#define SDF_MORE 16 /* more data (combined with SDF_TDIO/SDF_BULK) */
Wichtig!!!
Ein "last" (bzw. "not more") SDF_TDIO oder SDF_BULK Datenblock,
der nicht in die vorgegebenen maximalen Blocklängen von 256 Byte
bei Layer-2 bzw. 126 Byte bei ISDN paßt, wird im Dekoder in
(evtl. mehrere) Datenblöcke der jeweiligen Maximalgröße zerteilt
und nur der letzte Block wird als wirklich als "last" gesendet.
Es genügt also durchaus, z.B. einen 1500 Byte großen, transparenten
Datenblock *OHNE* SDF_MORE in den Btx-Server zu "poken", da
dieser ohnehin abhängig vom Verbindungstyp die Daten stückeln muß.
Nebenbemerkung:
Wo die fehlenden 2 Bytes zwischen B3-Datablock-Size = 130 Byte,
und 2 Byte BTX-ISDN-Header + 126 Byte Daten = 128 Byte bleiben,
ist mir selbst bisher nicht klar geworden...
Doch letztens sagte eines dieser "valuable statements" bei
der Verabschiedung aus meiner lokalen Mailbox:
"Never test for an error that you don't know to handle!"
In diesem Sinne...
12.)
Zur Vereinfachung der Send- und Emfpangsfunktionen existieren
mehrere WM_DDE_EXECUTE Befehle für transparente Daten und
(Reverse-)Bulk. Diese erwarten einen Dateinamen als Argument
und senden/empfangen die jeweiligen Datei aus/in die angegebene
Datei. Die Befehle lauten:
[GetTransp(filename.ext)] - Start Transparente Daten empfangen
[EndTransp] - Ende transparente Daten empfangen
[PutTransp(filename.ext)] - Transparente Daten senden
[GetBulk(filename.ext)] - Start Reverse-Bulk Daten empfangen
[EndBulk] - Ende Reverse-Bulk Daten empfangen
[PutBulk(filename.ext)] - Bulk Daten senden
Die Dateinamen können Laufwerk und/oder Pfadnamen enthalten.
Der Pfadname ".\" wird dabei auf das Installationsverzeichnis
von WXBtx bezogen. Liegt WXBTX.EXE also z.B. in "C:\WXBTX",
dann würde eine Datei ".\LOG\TEST.CC0" als Ergebnis den kompletten
Pfadnamen "C:\WXBTX\LOG\TEST.CC0" liefern.
Zu beachten ist, daß z.B. transparente Daten üblicherweise eine
Begrenzung der Feldlänge von 1500 Byte aufweisen und daß Bulk-
Requests ein Handshake der Zeile-24 Meldungen erfordern.
Ist eine Datei mit transparenten Daten größer als 1500 Byte,
wird sie zu jeweils 1500 Byte geblockt. Dies funktioniert aber
nicht z.B. mit der Mitteilungsseite *820#, wohl aber evtl. in
einem externen Rechner mit entsprechender Software.
Bulkdaten werden zu 4096 Byte geblockt, obwohl ein einzelner
Bulkrequest inklusive dem "BDHQSEI" Element (einer kompletten
Btx-Seite mit Seitenkopf) kaum 2048 Byte überschreiten wird.
Ein erfolgversprechendes Bulk-up muß ohnehin jeden Bulk-Request
mit der Zeile-24 Meldung verifizieren und geeignete Maßnahmen
ergreifen.
Die Unterscheidung zwischen transparenten Daten und Bulk-Daten
wird physikalisch erst mit ISDN eingeführt. Bei einer Layer-2
(Modem) Verbindung liefern die beiden Funktionsgruppen sowohl bei
`normalen' transparenten Daten als auch bei (Reverse-)Bulk-
Daten Ergebnisse. Anwendungsprogramme sollten dennoch die ihrer
Funtkion entsprechenden Befehle verwenden, da es sonst bei
Anwendern mit ISDN-Anschluß zu Komplikationen kommt.
Solange transparente Daten oder Bulk-Daten empfangen werden,
ignoriert der CEPT-Dekoder in WXBtx die einlaufenden Daten in
diesem Format.
Die Empfangsdateien werden im shared-write-mode geöffnet,
können also (wenn nötig) vom Anwendungsprogramm auch gleichzeitig
shared-read geöffnet und mitgelesen werden. Bei [EndTransp]
oder [EndBulk] wird die jeweilige Datei geschlossen.
12.)
Die umfangreichsten Erweiterungen der WINAPI betreffen die
Unterstützung der Btx-Seitenverwaltung im zu InfoTool(tm)
kompatiblen Format von BTL-Dateien. Diese Dateien enthalten
eine Liste von Btx-Seiten mit den zugehörigen Seitenkopf-Daten
und den jeweiligen Zuständen (neu, geändert, zu löschen, etc.).
Durch DDE-Kommandos kann eine solche Datei durch WXBtx
neu angelegt oder eine bestehende Datei geöffnet werden.
Es können bestehende Seiten geändert, neue Seiten angelegt
und die einzelnen Elemente jeder Seite manipuliert werden.
Dabei werden bereits durch WXBtx die Elemente entsprechend
den Regeln im Seitenkopf verwaltet und an der korrekten
Position in den Seitendaten eingetragen!
Es ist also (vergleichsweise) simpel, z.B. Dekoderdefinitionen,
Seitenaufbaucode, Auswahlmöglichkeiten, transparente Daten,
usw. auszulesen, zu löschen und neu zu setzen.
Hier nun die Liste der zur BTL-Datei-Verwaltung gehörenden
DDE-Kommandos und ihrer Argumente:
[LibOpen(file)] WM_DDE_EXECUTE
- Öffnet eine BTL-Datei oder eine VTL-Datei mit der dazu-
gehörenden VT1-Indexdatei und liest die Seitenliste in
den Server-Arbeitsspeicher der Client Verbindung.
Die erste Seite (Leitseite) der Datei wird vorselektiert
(selPAG), aber noch nicht geladen.
So ist es möglich eine Seite zwischen zwei BTL- und/oder
VTL-Dateien zu kopieren.
[LibCreate(file.ext,"impressum",seite)] WM_DDE_EXECUTE
- Erzeugt eine neue BTL-Datei oder eine VTL-Datei mit ihrer
VT1-Indexdatei mit dem angegebenen Impressum <impressum>
und der angegebenen Leitseite <seite>.
Die Dateierweiterung ".ext" entscheidet, ob eine BTL-Datei
oder eine VTL/VT1-Datei erzeugt wird und muß angegeben sein!
Eine BTL-Datei wird auf maximal 1015 Seiten ausgelegt
(Format InfoCept03 mit 16K Header), eine VTL-Datei kann
bei WXBtx maximal 65534 Seiten enthalten (134 MByte!).
Das InfoCept04 Format (Header bis 64K mit max. 4094 Seiten)
wird nur bei "LibOpen" aus Kompatibilitätsgründen unterstützt.
Verwenden Sie für große Bibliotheken das VTL-Dateiformat.
[LibClose] WM_DDE_EXECUTE
- Falls die Seitenliste geändert wurde (delPAG, insPAG)
wird sie in die BTL- oder VT1-Datei zurückgeschrieben.
Anschließend wird die Datei geschlossen.
[LibSelPag(xx/yyyyyyyyyyyyyyyyz)] WM_DDE_EXECUTE
- Wählt eine Seite aus der Bibliothek und lädt sie gleichzeitig
in den Server Seitenkopf-Arbeitsspeicher.
Diese Funktionalität ist auch getrennt mit LIB:selPAG(seite)
und LIB:getSEL über WM_DDE_REQUEST möglich.
[LibDelPag(xx/yyyyyyyyyyyyyyyyz)] WM_DDE_EXECUTE
- Löscht eine Seite in der Bibliothek.
Diese Funktionalität ist auch mit LIB:delPAG(seite) über
WM_DDE_REQUEST möglich, wobei bei Erfolg die Seitennumer
zurückgemeldet wird.
[LibInsPag(xx/yyyyyyyyyyyyyyyyz)] WM_DDE_EXECUTE
- Fügt eine Seite in der Bibliothek ein und schreibt den
Inhalt des aktuellen Seitenkopf-Arbeitsspeichers in die
Bibliothek (nach Eintrag der Seitennummer in SKOSEITE).
Diese Funktionalität ist auch mit LIB:insPAG(seite) über
WM_DDE_REQUEST möglich, wobei bei Erfolg die Seitennumer
zurückgemeldet wird.
LIB:getFILE WM_DDE_REQUEST
- liefert den vollständigen Pfadnamen der geöffneten
Bibliothek (BTL-Datei oder VTL-Datei).
LIB:getLST(liste) WM_DDE_REQUEST
- liefert eine Liste, und zwar für:
- LIB:getLST(PAG)
Liste aller Seiten der Bibliothek, der Indizes und der Status-
flags aus der Seitenliste der BTL-Datei oder VTL/VT1-Datei
Format: CF_TEXT iiiippppnnnnffffxx/yyyyyyyyyyyyyyyyz
i = BTL Datei-Index der Seite (4 stellig hex)
p = BTL Datei-Index der vorhergehenden Seite (4 stellig hex)
p = BTL Datei-Index der folgenden Seite (4 stellig hex)
f = Flags der Seite (4 stellig hex)
x = BKZ - ist in den Dateiheadern zunächst immer 00!
y = Seitennummer
z = Blattkennzeichen (a-z)
Seitennummer und Blattkennzeichen sind linksbünding.
Die Strings sind durch ein 0-Byte terminiert. Zwei
aufeinanderfolgende 0-Bytes kennzeichnen das Ende der Liste.
Die BTL Index-Felder haben für Client-Anwendungen nur
Info-Charakter, da WXBtx sie intern verwaltet.
- LIB:getLST(AWM)
Liste der Auswahlmöglichkeiten der gewählten Seite
Format 1: CF_TEXT w:xx/yyyyyyyyyyyyyyyyz
w = Wahl #,0 und 1 bis 9
oder #,0 und 10 bis 99
x = BKZ 2-stellig
y = Seitennummer max. 16-stellig
z = Blattkennzeichen (a-z)
Format 2: CF_TEXT w:yyyyyyyyyyyyyyyya
w = Wahl #,0 und 1 bis 9
oder #,0 und 10 bis 99
y = Seitennummer
a = Nur a-Blätter ohne BKZ in der ganzen Liste
Format 3: CF_TEXT w:xx/yyyyyyyyyyyyyyyyz
w = Wahl #, 2, 19
x = BKZ 2-stellig
y = Seitennummer max. 16-stellig
z = Blattkennzeichen (a-z)
Eine Seite mit Wahlen liefert bei LIB:getSKO(AWMDA) das
Flag 1. Ob 1-stellige oder 2-stellige Wahlen zu erwarten sind,
kann über LIB:getSKO(WM2ST) in Erfahrung gebracht werden.
Ist dieses Flag 1 (TRUE), sind 2-stellige Auswahlen im
Seitenkopf definiert. Das erste Format gilt für Wahlen
mit BKZ und Blattkennzeichen (LIB:getSKO(QSAM2) = 1),
das zweite Format für einfache Wahlen ohne BKZ und Blatt-
kennzeichen, also für LIB:getSKO(QSAM2) = 0.
Bei den Seitentypen SKOMSEIN, SKODSEIT und SKOGWSEI, also
bei Mitteilungs-, Dialog- und Übergabeseiten wird das dritte
Format zurückgeliefert.
- LIB:getLST(BBS)
Liste der Billboardseiten-Einträge einer Seite
Format: CF_TEXT ttttt:xx/yyyyyyyyyyyyyyyyz
t = Wartezeit in Sekunden
x = BKZ
y = Seitennummer
z = Blattkennzeichen (a-z)
Eine Billboardseite liefert bei LIB:getSKO(BBSEI) das
Flag 1. Die Anzahl der zu erwartenden Billboardseiten-
Einträge kann über LIB:getSKO(BBANZ) in Erfahrung ge-
bracht werden. Seiten vom Typ Billboardseite enthalten
ein transparentes Datenfeld mit einer speziellen Struktur,
die über diese Funktion in eine Liste von Seiten mit
zugehörigen Timeouts konvertiert wird.
- LIB:getLST(FBE)
Liste der Feldbeschreibungselemente einer Seite
Format: CF_TEXT nnnxxxyyyllllffbbtttiiiii[....]
n 0 3 = Nummer des Feldes dezimal
x 3 3 = Spalte des Feldanfangs dezimal
y 6 3 = Zeile des Feldanfangs dezimal
l 9 4 = Länge des Feldes dezimal
f 13 2 = Flags des Feldes hex
b 15 2 = Binärkennzeichen des Feldes
t 17 3 = Typ des Feldes dezimal (numerischer Feldtyp)
i 20 ? = Inhalt (Vorbelegung) des Feldes - llll Zeichen
bei binären Daten 2 * llll Zeichen "Hexdump"
Ob eine Seite Felder enthält, kann über LIB:getSKO(FBEDA)
in Erfahrung gebracht werden. Die Nummer nnn ist immer
fortlaufend von 0 bis LIB:getSKO(FBANZ) - 1, wird aber zur
Zuordnung eventuell vorhandener Prompting-Texte benötigt.
Das erste Eingabefeldes kann über LIB:getSKO(FBFD1) in
Erfahrung gebracht werden. Die Bedeutung der Flags ff und bb
ist der Dokumentation zum Bulk-Up zu entnehmen.
Bei einem binären Feld wird nicht der Feldinhalt direkt, sondern
der Inhalt eines vorhandenen TDA Bereiches als "Hexdump"
geliefert, ist also bei einer korrekten Seite 2 * llll Zeichen
lang. Stimmt die Länge von iii... nicht mit der Angabe in
llll überein, dann ist die Felddefinition fehlerhaft oder der
TDA-Bereich fehlt in der Seite.
LIB:putLST(liste) WM_DDE_POKE
- analysiert eine Liste im Datenbereich DDEPOKE->Value,
erzeugt in der aktuellen Seite die entsprechende Daten
und setzt die evtl. dazugehörenden Flags.
Für die Werte von <liste> gilt:
- LIB:putLST(PAG)
Setzt die BTL-Header Flags für eine Liste von Seiten.
DDEPOKE->Value enthält die Liste der zu ändernden Seiten
Format: CF_TEXT ffffxx/yyyyyyyyyyyyyyyyz
f = Flags der Seite (4 stellig hex)
x = BKZ
y = Seitennummer
z = Blattkennzeichen (a-z)
Seitennummer und Blattkennzeichen sind linksbünding.
Die Strings sind durch ein 0-Byte terminiert. Zwei
aufeinanderfolgende 0-Bytes kennzeichnen das Ende der Liste.
- LIB:putLST(AWM)
Setzt die Auswahlmöglichkeiten der aktuellen Seite.
Der Bereich DDEPOKE->Value enthält dabei folgendes
Format 1: CF_TEXT w:xx/yyyyyyyyyyyyyyyyz
w = Wahl #,0 und 1 bis 9
oder #,0 und 10 bis 99
x = BKZ 2-stellig
y = Seitennummer max. 16-stellig
z = Blattkennzeichen (a-z)
Format 2: CF_TEXT w:yyyyyyyyyyyyyyyya
w = Wahl #,0 und 1 bis 9
oder #,0 und 10 bis 99
y = Seitennummer max. 16-stellig
a = Nur a-Blätter ohne BKZ in der ganzen Liste
Format 3: CF_TEXT: w:xx/yyyyyyyyyyyyyyyyz
w = Wahl #, 2, 19
x = BKZ 2-stellig
y = Seitennummer max. 16-stellig
z = Blattkennzeichen (a-z)
Ganz entsprechend LIB:getLST(AWM) wird aus der Liste der
Wahlen ein AWM Datenbereich gebildet und in den Seitenkopf
und die Seite eingetragen. Die zugehörigen Flags SKOAWMDA,
SKOWM2ST und SKOQSAM2 werden abhängig vom Inhalt der
Liste bei Infoseiten wie folgt gesetzt:
AWMDA - bei nicht leerer Liste immer gesetzt
WM2ST - bei Wahlen mit w > 9
QSAM2 - bei Wahlen mit BKZ und/oder Blatt ungleich a
Bei Mitteilungs-, Dialog- und Übergabeseiten gilt Format 3.
- BBS
DDEPOKE->Value enthält eine Liste der Billboardseiten-
Einträge und zugehörigen Timeouts für diese Seite im
Format: CF_TEXT ttttt:xx/yyyyyyyyyyyyyyyyz
t = Wartezeit in Sekunden (dezimal)
x = BKZ 2-stellig
y = Seitennummer max. 16-stellig
z = Blattkennzeichen (a-z)
Die Seite wird als Billboardseite definiert (SKOBBSEI)
und es wird ein transparenter Datenbereich mit den
Billboardseiten-Einträgen angelegt. Die Anzahl der
Einträge wird in SKOBBANZ vermerkt.
LIB:getSEL WM_DDE_REQUEST
- liest die aktuell gewählte Seite von Platte in den
Server Seitenkopf-Arbeitsspeicher der Client Verbindung.
- liefert die Seitennummer im
Format: CF_TEXT xx/yyyyyyyyyyyyyyyyz
x = BKZ
y = Seitennummer
z = Blattkennzeiche (a-z)
BKZ, Seitennummer und Blattkennzeichen sind linksbünding.
LIB:putSEL WM_DDE_REQUEST
- schreibt die aktuell gewählte Seite aus dem Server
Seitenkopf-Arbeitsspeicher der Client Verbindung auf Platte.
- liefert die Seitennummer wie bei LIB:getSEL
LIB:decSEL WM_DDE_REQUEST
- dekodiert die aktuell gewählte Seite aus dem Server
Seitenkopf-Arbeitsspeicher der Client Verbindung.
Dabei wird zunächst eine eventuell angegebene Mutterseite
(SKOMTSEI) der Seite mit ihren zugehörigen Dekoderdefinitionen
ausgegeben, falls SKOCSEIT der aktuellen Seite TRUE ist.
Danach werden die in SKOSDRQ1 bis SKOSDRQ3 angegebenen
Dekoderdefinitionen geladen und dekodiert.
Anschließend werden die Dekoderdefinitionen der Seite selbst
und zuletzt deren Aufbaucode dekodiert bzw. angezeigt.
- liefert die Seitennummer wie bei LIB:getSEL
LIB:clrSEL WM_DDE_REQUEST
- löscht den Inhalt aller Elemente der akuellen Seite im
Server Seitenkopf-Arbeitsspeicher der Client Verbindung.
Die Seite wird als Infoseite mit 40x24 Zeichen vorbelegt
und enthält zunächst nur den eigentlichen Seitenkopf;
es muß also zumindest ein LIB:insHQ1 und LIB:insHQ4 folgen,
damit die Seite die minimalen Daten für Bulk-Up enthält.
- liefert den kompletten Seiteninhalt wie bei LIB:getRAW,
der aber in diesem Fall keine Seitenelemente, sondern
nur den SKO... - Anteil der Seite enthält (206 Bytes).
LIB:selPAG(xx/yyyyyyyyyyyyyyyyz) WM_DDE_REQUEST
- selektiert eine Btx-Seite aus der Bibliothek (Seitenliste)
fehlt xx/, wird BKZ 00 angenommen (bundesweit);
y kann maximal 16-stellig sein;
fehlt z, wird Blatt a angenommen.
- liefert die vollständige Seitennummer wie bei LIB:getSEL
LIB:delPAG(xx/yyyyyyyyyyyyyyyyz) WM_DDE_REQUEST
- löscht eine Btx-Seite aus der Bibliothek (Seitenliste)
fehlt xx/, wird BKZ 00 angenommen (bundesweit);
y kann maximal 16-stellig sein;
fehlt z, wird Blatt a angenommen.
- liefert die vollständige Seitennummer wie bei LIB:getSEL
LIB:insPAG(xx/yyyyyyyyyyyyyyyyz) WM_DDE_REQUEST
- erzeugt eine Btx-Seite in der Bibliothek (Seitenliste)
fehlt xx/, wird BKZ 00 angenommen (bundesweit);
y kann maximal 16-stellig sein;
fehlt z, wird Blatt a angenommen.
- liefert die vollständige Seitennummer wie bei LIB:getSEL
LIB:getSKO(element) WM_DDE_REQUEST
- liefert ein Element des Seitenkopfes gemäß Anhang A.
DDEDATA->Value liefert einen String mit dem Wert für
das Element im in Anhang A angegebenen Format.
LIB:putSKO(element) WM_DDE_POKE
- setzt ein Element des Seitenkopfes gemäß Anhang A.
DDEPOKE->Value enthält einen String mit dem Wert für
das Element im in Anhang A angegebenen Format.
LIB:getRAW WM_DDE_REQUEST
- liefert den kompletten Seiteninhalt aus dem Server
Seitenkopf-Arbeitsspeicher an die Client-Applikation.
DDEDATA->pValue enthält eine Struktur
struct tagRAW {
WORD size;
BYTE data[];
} RAW;
size enthält die Länge des folgenden Datenbereiches.
Das Format von data ist in der Spezifikation des FTZ zum
Bulk-Up beschrieben und wird hier als bekannt vorausgesetzt.
LIB:putRAW WM_DDE_POKE
- schreibt einen kompletten Seiteninhalt in den Server
Arbeitsspeicher. Die Puffergröße beträgt maximal 2048 Byte.
Der Seitenkopf muß unbedingt gültige Werte für die verschiedenen
Pointer in den Datenbereich der Seite enthalten!
RAW->size muß nicht korrekt sein, da die Länge der Seite im
Feld SKOLANGE des Seitenkopfes korrekt angegeben ist.
LIB:getAWM WM_DDE_REQUEST
- liefert die Auswahlmöglichkeiten der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delAWM WM_DDE_REQUEST
- löscht Auswahlmöglichkeiten der aktuelle Seite
- ändert SKOAMPTR, SKOAMLEN, SKOAWMDA, SKOWM2ST, SKOQSAM2 und SKOLANGE
- liefert den vorherigen Inhalt von AWM wie bei LIB:getAWM
LIB:insAWM WM_DDE_POKE
- löscht einen evtl. vorhandenen AWM Bereich
- schreibt die Auswahlmöglichkeiten in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
den Auswahlmöglichkeiten in RAW->data
- ändert SKOAMPTR, SKOAMLEN, SKOAWMDA und SKOLANGE
LIB:getHQ1 WM_DDE_REQUEST
- liefert den Text des Zeile-1 Datenbereichs der aktuellen Seite
Dieser Text ist 40 Zeichen lang und wird beim Bulkup durch das
Impressum des Anbieters der Seite und die Vergütung ersetzt.
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delHQ1 WM_DDE_REQUEST
- löscht den Zeile-1 Datenbereich in der aktuellen Seite
- ändert SKOHQPT1, SKOHQLE1 und SKOLANGE
- liefert den vorherigen Inhalt von HQ1 wie bei LIB:getHQ1
LIB:insHQ1 WM_DDE_POKE
- löscht einen evtl. vorhandenen HQ1 Bereich
- schreibt den Text des Zeile-1 Datenbereichs der aktuellen Seite.
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit dem
Impressum, die Vergütung (x,xx DM) wird aus dem Seitenkopf ergänzt.
- ändert SKOHQPT1, SKOHQLE1 und SKOLANGE
LIB:getHQ4 WM_DDE_REQUEST
- liefert den Text des Zeile-24 Datenbereichs der aktuellen Seite.
Dies ist die 19 stellige, rechtsbündige Seiten- und Blattnummer.
Diese wird beim Bulkup durch die Seiten- mit Blattnummer aus dem
Seitenkopf der Seite ersetzt.
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delHQ4 WM_DDE_REQUEST
- löscht den Zeile-24 Datenbereich in der aktuellen Seite
- ändert SKOHQPT4, SKOHQLE4 und SKOLANGE
- liefert den vorherigen Inhalt von HQ4 wie bei LIB:getHQ4
LIB:insHQ4 WM_DDE_POKE
- löscht einen evtl. vorhandenen HQ4 Bereich
- schreibt den Text des Zeile-24 Datenbereichs der aktuellen Seite;
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
max. 17 Zeichen mit Seiten- und Blattnummer.
- ändert SKOHQPT4, SKOHQLE4 und SKOLANGE
LIB:getDRC WM_DDE_REQUEST
- liefert die Dekoderdefinitionen der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delDRC WM_DDE_REQUEST
- löscht Dekoderdefinitionen der aktuelle Seite
- ändert SKODRPTR, SKODRLEN, SKODRCSV und SKOLANGE
- liefert den vorherigen Inhalt von DRC wie bei LIB:getDRC
LIB:insDRC WM_DDE_POKE
- löscht einen evtl. vorhandenen DRC Bereich
- schreibt die Dekoderdefinitionen in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
den Dekoderdefinition in RAW->data
- ändert SKODRPTR, SKODRLEN, SKODRCSV und SKOLANGE
LIB:getACO WM_DDE_REQUEST
- liefert den Aufbaucode der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delACO WM_DDE_REQUEST
- löscht den Aufbaucode der aktuelle Seite
- ändert SKOACPTR, SKOACLEN, SKOACODV, SKODACDV und SKOLANGE
- liefert den vorherigen Inhalt von ACO wie bei LIB:getACO
LIB:insACO WM_DDE_POKE
- löscht einen evtl. vorhandenen ACO Bereich
- schreibt den Aufbaucode in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
dem Aufbaucode in RAW->data
- ändert SKOACPTR, SKOACLEN, SKOACODV und SKOLANGE
LIB:getASP WM_DDE_REQUEST
- liefert die Abrufsperre der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delASP WM_DDE_REQUEST
- löscht die Abrufsperre der aktuelle Seite
- ändert SKOASPTR, SKOASLEN, SKOASPEV, SKOASTLN und SKOLANGE
- liefert den vorherigen Inhalt von ASP wie bei LIB:getASP
LIB:insASP WM_DDE_POKE
- löscht einen evtl. vorhandenen ASP Bereich
- schreibt die Abrufsperre in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
der Abrufsperre in RAW->data
- ändert SKOASPTR, SKOASLEN, SKOASPEV und SKOLANGE
LIB:getFBE WM_DDE_REQUEST
- liefert die Feldbeschreibungselemente der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delFBE WM_DDE_REQUEST
- löscht die Feldbeschreibungselemente der aktuelle Seite
- ändert SKOFBPTR, SKOFBLEN, SKOFBEDA und SKOLANGE
- liefert den vorherigen Inhalt von FBE wie bei LIB:getFBE
LIB:insFBE WM_DDE_POKE
- löscht einen evtl. vorhandenen FBE Bereich
- schreibt die Feldbeschreibungselemente in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
den Feldbeschreibungselementen in RAW->data
- ändert SKOFBPTR, SKOFBLEN, SKOFBEDA und SKOLANGE
LIB:getPMT WM_DDE_REQUEST
- liefert die Prompting-Texte der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delPMT WM_DDE_REQUEST
- löscht die Prompting-Texte der aktuelle Seite
- ändert SKOPMPTR, SKOPMLEN, SKOPMTDA und SKOLANGE
- liefert den vorherigen Inhalt von PMT wie bei LIB:getPMT
LIB:insPMT WM_DDE_POKE
- löscht einen evtl. vorhandenen PMT Bereich
- schreibt die Prompting-Texte in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
den Prompting-Texten in RAW->data
- ändert SKOPMPTR, SKOPMLEN, SKOPMTDA und SKOLANGE
LIB:getSVE WM_DDE_REQUEST
- liefert die Schlagwortverzeichnis-Einträge der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
LIB:delSVE WM_DDE_REQUEST
- löscht die Schlagwortverzeichnis-Einträge der aktuelle Seite
- ändert SKOBVPTR, SKOBVLEN, SKOSVANG, SKOSVEIN und SKOLANGE
- liefert den vorherigen Inhalt von SVE wie bei LIB:getSVE
LIB:insSVE WM_DDE_POKE
- löscht einen evtl. vorhandenen SVE Bereich
- schreibt die Schlagwortverzeichnis-Einträge in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
den Schlagwortverzeichniseinträgen in RAW->data
- ändert SKOBVPTR, SKOBVLEN, SKOSVANG, SKOSVEIN und SKOLANGE
LIB:getTDA WM_DDE_REQUEST
- liefert den transparenten Datenbereich der aktuellen Seite
DDEDATA->pValue enthält eine Struktur wie bei LIB:getRAW.
Ob es sich bei transparenten Daten um Ein-/Ausgabefelder
oder z.B. eine Billboardseiten-Liste handelt, ist anhand
der Flags der Seite feststellbar.
LIB:delTDA WM_DDE_REQUEST
- löscht den transparenten Datenbereich der aktuelle Seite
- ändert SKOTDPTR, SKOTDLEN, SKOTRANS und SKOLANGE
- liefert den vorherigen Inhalt von TDA wie bei LIB:getTDA
- eventuell zugehörige Feldbeschreibungen werden nicht gelöscht!
LIB:insTDA WM_DDE_POKE
- löscht einen evtl. vorhandenen TDA Bereich
- schreibt den transparenten Datenbereich in die aktuelle Seite
DDEPOKE->pValue enthält eine Struktur wie bei LIB:GetRAW mit
den tranparenten Daten in RAW->data
- ändert SKOTDPTR, SKOTDLEN, SKOTRANS und SKOLANGE
- eventuell nötige Feldbeschreibungen werden nicht gesetzt!
Sie können über LIB:insFBE oder LIB:putLST(FBE) generiert
werden.
Anhang A
Elemente des Seitenkopfes und ihre Formatierung
Name - Elementname bei LIB:getSKO(Name) oder LIB:putSKO(Name)
Format - Formatierung des des Strings
FL - maximale Stellenzahl des Strings, nullterminiert
TYP - page= Seite mit BKZ, Seitennummer und Blatt, linksbündig
drq= DRQ-Seite, linksbündig
dat= Datum und Uhrzeit
tln= Teilnehmernummer-Mitbenutzer
dez= dezimal
bin= Kopie des Feldes
bool= boolean (0 FALSE oder 1 TRUE)
Element - Elementstruktur im Seitenkopf
Kommentar - Kurzbeschreibung laut FTZ Bulk-Update Papier
Name Format FL Typ Element Kommentar
------------------------------------------------------------------------
SEITE xx/yyyyyyyyyyyyyyyyz 20 page 10 BYTE Seitennummer der Seite
CONCO nnn 3 dez 1 BYTE später
ALIGO nnn 3 dez 1 BYTE später
HEADR nnnnnnnnnnn 11 dez 1 DWORD intern
LANGE nnnnn 5 dez 1 WORD Länge der Seite inkl. Kopf
ANZBZ nnn 3 dez 1 BYTE Anzahl Zeilen (20/24)
ANZSP nnn 3 dez 1 BYTE Anzahl Spalten (40/80)
BKZV1 nnn 3 dez 1 BYTE später
BALLL nnn 3 dez 1 BYTE später
PREPR nnnnn 5 dez 1 WORD Preprozess
POSTP nnnnn 5 dez 1 WORD Postprozess
FLAG1 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
IZSPE b 1 bool BIT7 Zugriff gesperrt
BZSPE b 1 bool BIT6 intern
PERSO b 1 bool BIT5 Persönliche Daten
QUIBS b 1 bool BIT4 intern
SMACD b 1 bool BIT3 Seite mit Autorisierungscode
BERSE b 1 bool BIT2 intern
ENQIN b 1 bool BIT1 intern
ABRST b 1 bool BIT0 Abrufstatistik
FLAG2 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
WM2ST b 1 bool BIT7 2-stellige Wahlmöglichkeit
SDRVR b 1 bool BIT6 intern
VBLAT b 1 bool BIT5 Verkettetes Blatt folgt
CSEIT b 1 bool BIT4 Kombinierte Seite
ESEIT b 1 bool BIT3 Eintrittsseite
SUNTB b 1 bool BIT2 Seitenaufbau nicht unterbrechbar
LBLAT b 1 bool BIT1 Letztes Blatt der Seite
DRCSV b 1 bool BIT0 Decoderdefinition vorhanden
FLAG3 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
ACODV b 1 bool BIT7 Aufbaucode vorhanden
DACDV b 1 bool BIT6 Decoderdefinition im Aufbaucode
FBEDA b 1 bool BIT5 Feldbeschreibungen vorhanden
AWMDA b 1 bool BIT4 Auswahlmöglichkeiten vorhanden
PMTDA b 1 bool BIT3 Promptingtexte vorhanden
TRANS b 1 bool BIT2 transparente Daten vorhanden
SVANG b 1 bool BIT1 Schlagwortbereich vorhanden
SVEIN b 1 bool BIT0 Schlagwortverzeichnis einarbeiten
FLAG4 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
HLOES b 1 bool BIT7 intern
ZMDSE b 1 bool BIT6 intern
NMWST b 1 bool BIT5 intern
HMWST b 1 bool BIT4 intern
VMWST b 1 bool BIT3 100% vom MwSt-Satz
RQCHE b 1 bool BIT2 intern
ZEILN b 1 bool BIT1 intern
WERBG b 1 bool BIT0 Seite enthält Werbung
FLAG5 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
COTIN b 1 bool BIT7 intern
BIBIZ b 1 bool BIT6 intern
WRAPA b 1 bool BIT5 später (Wraparound !?)
FSBGH b 1 bool BIT4 Hintergrund halten
MZGES b 1 bool BIT3 intern
MABUL b 1 bool BIT2 intern
MASBV b 1 bool BIT1 intern
QSAM2 b 1 bool BIT0 Auswahl enthält BKZ und Blatt
FLAG6 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
KSTV b 1 bool BIT7 intern
MAONL b 1 bool BIT6 intern
KSTA b 1 bool BIT5 intern
ONOPT b 1 bool BIT4 intern
ASPEV b 1 bool BIT3 Abrufsperre vorhanden
ASTLN b 1 bool BIT2 Teilnehmerliste für Abrufsperre
U219 b 1 bool BIT1 intern
OEFT b 1 bool BIT0 intern
FLAG7 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
FLG77 b 1 bool BIT7 später
FLG76 b 1 bool BIT6 später
FLG75 b 1 bool BIT5 später
FLG74 b 1 bool BIT4 später
FLG73 b 1 bool BIT3 später
FLG72 b 1 bool BIT2 später
FLG71 b 1 bool BIT1 später
ASCII b 1 bool BIT0 VT100 / ASCII - Seite
VGKLE nnn 3 dez 1 BYTE Nutzungszeitabh. Vergütungsklasse
FLAG8 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
ISEIT b 1 bool BIT7 Informationsseite
DSEIT b 1 bool BIT6 Dialogseite
MSEIN b 1 bool BIT5 Mitteilungsseite, Eingabe
GWSEI b 1 bool BIT4 Gatewayseite (Übergabeseite)
SSEIT b 1 bool BIT3 intern (Systemseite !?)
FSSER b 1 bool BIT2 Format-Service Seite
BBSEI b 1 bool BIT1 Billboard-Seite
DUMMY b 1 bool BIT0 intern
FLAG9 nnn 3 dez 1 BYTE folgende 8 Flag-Bits
FERTA b 1 bool BIT7 intern
FFSEI b 1 bool BIT6 intern
ZVSEI b 1 bool BIT5 intern
FFZVS b 1 bool BIT4 intern
ZVSE b 1 bool BIT3 intern
ZVSL b 1 bool BIT2 intern
UZVSE b 1 bool BIT1 intern
MEB b 1 bool BIT0 intern
FLAGA nnn 3 dez 1 BYTE folgende 8 Flag-Bits (TFI)
TFGE1 b 1 bool BIT7 Geometrie Profile 1
TFGE2 b 1 bool BIT6 Geometrie Profile 2
TFPHO b 1 bool BIT5 Photografic
TFTSW b 1 bool BIT4 Telesoftware
TFTPM b 1 bool BIT3 Transparent Mode
TFCHM b 1 bool BIT2 80 Zeichen Mode
TFCHI b 1 bool BIT1 Chipkarte
TFRES b 1 bool BIT0 später
FLAGB nnn 3 dez 1 BYTE folgende 8 Flag-Bits (TFI2)
TFI27 b 1 bool BIT7 später
TFI26 b 1 bool BIT6 später
TFI25 b 1 bool BIT5 später
TFI24 b 1 bool BIT4 später
TFI23 b 1 bool BIT3 später
TFI22 b 1 bool BIT2 später
TFI21 b 1 bool BIT1 später
TFI20 b 1 bool BIT0 später
ABSNR tttttttttttt-mmmm 17 dez 8 BYTE Absender Teilnehmer-Mitbenutzer
ITLNR nnnnnnnnnnnn 12 dez 6 BCDp Absender Teilnehmernummer
IMBSU nnnn 4 dez 2 BCD Absender Mitbenutzernummer
EMPNR tttttttttttt-mmmm 17 dez 8 BYTE Empfänger Teilnehmer-Mitbenutzer
ETLNR nnnnnnnnnnnn 12 dez 6 BCDp Empfänger Teilnehmernummer
EMBSU nnnn 4 dez 2 BCD Empfänger Mitbenutzernummer
ZEINA yy.mm.dd hh:mm:ss 17 dat 6 BCD Datum/Uhrzeit Seitenerstellung
ZEIFU yy.mm.dd hh:mm:ss 17 dat 6 BCD Datum/Uhrzeit intern (Update !?)
ACIGB nnnn 4 dez 2 BCD Autorisierungscode GBG
EBETR nnnnn 5 dez 1 WORD Vergütung der Seite in Pfennigen
SCROL nnn 3 dez 1 BYTE später
ERNUM nnnnnn 6 dez 3 BCD Externer Rechner Nummer
GWNUM nnnnnn 6 dez 6 BYTE Gateway Nummer
SZEST nnn 3 dez 1 BYTE Stellenzahl der Leitseite
LKEY0 nnn 3 dez 1 BYTE Signifikante Stellenzahl der Seite
MTSEI xx/yyyyyyyyyyyyyyyyz 20 fmt 10 BYTE Mutterseite (Kombinierte Seiten)
MTCON nnn 3 dez 1 BYTE später
ZEILA nnn 3 dez 1 BYTE Zeile Fensteranfang (2 - 23)
ZEILE nnn 3 dez 1 BYTE Zeile Fensterende (2 - 23)
SDRQ1 yyyyyyyyyyyyyyyyz 17 fmt 10 BYTE Decoderdefinitionen Seite 1
SDRQ2 yyyyyyyyyyyyyyyyz 17 fmt 10 BYTE Decoderdefinitionen Seite 2
SDRQ3 yyyyyyyyyyyyyyyyz 17 fmt 10 BYTE Decoderdefinitionen Seite 3
LVERZ nnn 3 dez 1 BYTE intern
AMPTR nnnnn 5 dez 1 WORD Pointer Auswahlmöglichkeiten
AMLEN nnnnn 5 dez 1 WORD Länge Auswahlmöglichkeiten
SYSTI nnnnnnnnnnn 11 dez 1 DWORD intern
TYPZ1 nnn 3 dez 1 BYTE intern
FAZE1 nnn 3 dez 1 BYTE V/H-Farbe erste Zeile
FGZE1 nn 2 dez 4 BIT Vordergrundfarbe erste Zeile
BGZE1 nn 2 dez 4 BIT Hintergrundfarbe erste Zeile
HQPT1 nnnnn 5 dez 1 WORD Pointer erste Zeile (Impressum)
HQLE1 nnnnn 5 dez 1 WORD Länge erste Zeile (Impressum)
TYPZ4 nnn 3 dez 1 BYTE intern
FAZE4 nnn 3 dez 1 BYTE V/H-Farbe letzte Zeile
FGZE4 nn 2 dez 4 BIT Vordergrundfarbe letzte Zeile
BGZE4 nn 2 dez 4 BIT Hintergrundfarbe letzte Zeile
HQPT4 nnnnn 5 dez 1 WORD Pointer letzte Zeile (Seitennummer)
HQLE4 nnnnn 5 dez 1 WORD Länge letzte Zeile (Seitennummer)
DRPTR nnnnn 5 dez 1 WORD Decoder Definition Offset
DRLEN nnnnn 5 dez 1 WORD Decoder Definition Länge
SYSTA nnnnnnnnnnn 11 dez 1 DWORD intern
ACPTR nnnnn 5 dez 1 WORD Aufbaucode Offset
ACLEN nnnnn 5 dez 1 WORD Aufbaucode Länge
ASPTR nnnnn 5 dez 1 WORD Abrufsperre Offset
ASLEN nnnnn 5 dez 1 WORD Abrufsperre Länge
FBPTR nnnnn 5 dez 1 WORD TV/Felder Offset
FBLEN nnnnn 5 dez 1 WORD TV/Felder Länge
FBOF1 nnnnn 5 dez 1 WORD Feldbeschreibung 1 Offset
FBANZ nnn 3 dez 1 BYTE Anzahl der Feldbeschreibungen
FBFD1 nnn 3 dez 1 BYTE Erstes Feld für die Eingabe
CHIKA nnnnn 5 dez 1 WORD intern (Chipkarte !?)
CHFLG nnn 3 dez 1 BYTE intern (Chipkarte Flag !?)
CHIND nnn 3 dez 1 BYTE intern (Chipkarte Index !?)
PMPTR nnnnn 5 dez 1 WORD Promptingtexte Offset
PMLEN nnnnn 5 dez 1 WORD Promptingtexte Länge
NAPTR nnnnn 5 dez 1 WORD intern
NALEN nnnnn 5 dez 1 WORD intern
BVPTR nnnnn 5 dez 1 WORD Schlagwortanbindung Offset
BVLEN nnnnn 5 dez 1 WORD Schlagwortanbindung Länge
KSPTR nnnnn 5 dez 1 WORD intern
KSLEN nnnnn 5 dez 1 WORD intern
TDPTR nnnnn 5 dez 1 WORD Transparente Daten Offset
TDLEN nnnnn 5 dez 1 WORD Transparente Daten Länge
BBFCT nnn 3 dez 1 BYTE Anzahl Billboard Wiederholungen
BTDBP nnnnn 5 dez 1 BYTE intern
HQSHE nnnnnnnn 8 bin 8 BYTE intern
Sollten Ihnen Fehler (vor allem in Anhang A) auffallen,
senden Sie bitte eine Nachricht ins *XBTX# Forum oder
im *XTREFF# externen Rechner!
Viel Erfolg und Spaß bei der Programmierung unter WinDoof
und mit der WINAPI von WXBtx wünscht,
Jürgen Buchmüller
Bonn den 04.06.1995