EURO-REV: SDK 
Der Bereich „Techbase“ unserer Webseite wird nicht mehr gepflegt. Techbase bezieht sich auf die Produktreihe CN Faktura EURO. Diese DOS-basierte Produktreihe ist - genau wie die Speed-Faktura-Reihe - eingestellt. Seit nun schon über 10 Jahren bieten wir die Windows- und SQL-basierte Lösung „EULANDA“ an. Daten aus der Euro können zum großen Teil übernommen werden. Wenden Sie sich bitte an unseren Vertrieb oder einen Fachhandelspartner in Ihrer Nähe.

Home Produkte Download Support Betriebshandbuch Schulungen Mitteilung Newsletter Impressum

Anwender-Forum

Fernwartungssystem laden (nach Aufforderung)

SDK zur EUROnet

Zurück | Ebene zurück

TECHBASE enthält Information zur DOS-Linie EUROnet, die Windows-Linie finden Sie unter Inside.

 

  • Konzept und Funktionsweise
    der EURO Filter-DLLs

    Ansatz bei der Neuentwicklung der Import-Filter war zum einen die Kompatibilität zwischen EURO und CNFilter, also zwischen DOS-Protected-Mode und Windows (16bit), zum anderen Einfachheit in Aufbau und Konfiguration sowie Flexibilität. Die Kompatibilitätsforderung bringt es mit sich, dass beim Programmieren darauf geachtet werden musste - und auch in Zukunft geachtet werden muss, falls Filterfunktionen überschrieben werden sollen - dass der kleinste gemeinsame Nenner zwischen Windows- und Protected-Mode-Umgebung eingehalten wird. Wenn man nicht genau weiß, was man tut, erreicht man das am Besten dadurch, dass man den Filter unter BP7 übersetzen lässt: geht das, ist er in der Regel kompatibel, geht's nicht, muss man ihn entsprechend ändern. Einen anderen ziemlich sicheren Hinweis, dass alles ok ist, erhält man durch Überprüfung der in der kompilierten Filter-DLL aufgeführten Windows-Module: hier sollten nur drei aufgeführt sein, nämlich KERNEL, USER und KEYBOARD. Ein untrügliches Zeichen dafür, dass man verbotene Windows-Funktionen mit eingebunden hat, ist das Auftauchen des Moduls TOOLHELP an dieser Stelle. Dies passiert leicht, wenn man aus Versehen Routinen der Unit SYSUTILS.PAS verwendet.
    Werden jedenfalls im Filter Windows-Funktionen - und sei es auch nur indirekt - verwendet, die in der BP7-WINAPI nicht enthalten sind, stürzt der Import von der EURO aus unweigerlich ab.

    Der grobe Ablauf einer Import-Sitzung mit einer beliebigen Filter-DLL geht wie folgt vor sich:

    Die Kommunikation zwischen aufrufendem Programm, also entweder der EURO oder CNFilter, und der Filter-DLL wird über wenige Export-Funktionen realisiert, die für alle Filter gleich sind. Diese sind DLL-seitig auf Methoden des jeweiligen Filter-Objekts gemappt, die die eigentliche Arbeit ausführen. Auch die Verbindung zum Universalfilter wird bis auf eine zusätzliche über genau dieselben Funktionen gewährleistet. Diese Schnittstellenprozeduren dürfen auf keinen Fall geändert werden, ohne gleichzeitig die Import-Units in der EURO und das CNFilter-Programm entsprechend anzupassen, was eigentlich überflüssig und auch nicht zu empfehlen ist, da ein solches Vorgehen einer Neuentwicklung gleichkäme. Das gilt vor allem für die Übergabe-Parameter. Weder EURO noch CNFilter können wissen, wie die Funktionen in der DLL implementiert sind, sie verlassen sich also blind darauf, dass diese genau dem Aufruf entsprechen.
    Auf EURO-Seite sind alle Export-Funktionen  in der Unit DLFIMP.PAS (zu finden in CNLIB) in dem Objekt TFilterInterface als Methoden gekapselt und über etwas handlichere Funktionen zur eigentlichen Verwendung herausgeführt. Die bessere Handhabbarkeit bezieht sich vor allem darauf, dass PChar's an dieser Stelle in Pascal-Strings, und die Rückgabe-LongInt's in Boolean's überführt werden und umgekehrt.

    Hier die Funktionen im Einzelnen mit jeweils einer kurzen Beschreibung, sowie der Implementierung im Hier die Funktionen im Einzelnen mit jeweils einer kurzen Beschreibung, sowie der Implementierung im Filter und evtl. abweichender Entsprechung in der Euro:

    Hier die Funktionen im Einzelnen mit jeweils einer kurzen Beschreibung, sowie der Implementierung im Filter und evtl. abweichender Entsprechung in der Euro:


    • AssignFilter

      Filter: function AssignFilter ( INIPath : PChar; BufPtr : pPointer; TmpPtr : pTmpDat ) : tFilterHandle;
      Euro: function AssignFilter ( DLLPath : String; INIPath : String; BufPtr : pPointer; TmpPtr : pTmpDat; var Status : Integer; var Msg : String ) : tFilterHandle;

      Mit AssignFilter wird die Filter-DLL geöffnet, und die Filterfunktionen werden initialisiert.
      Übergeben werden die Pfade zur DLL und zur INI-Datei, eine Zeiger-Variable, die einen vom Filter initialisierten Zeiger auf den Datensatzpuffer übernimmt, sowie einen Zeiger auf einen Bereich für temporäre Daten. Dieser wurde für den Datanorm-Filter eingeführt, um nicht nur Daten aus dem Filter lesen zu können, sondern auch Zwischendaten aus der EURO zurückgeben zu können.
      Als Ergebnis liefert diese Funktion ein Handle auf den initialisierten Filter, das in folgenden Funktionsaufrufen immer mit übergeben werden muss. Dieses Handle ist eigentlich ein LongInt, das filterintern durch Typenkonvertierung des Pointers auf das Filterobjekt erzeugt wird. Wird Null zurückgegeben, ist dementsprechend die Filterinitialisierung fehlgeschlagen.
      Über Status und Msg erhält man im Fehlerfalle einen Fehlercode und eine Fehlermeldung.

    • ReleaseFilter

      procedure ReleaseFilter ( FilterHandle : tFilterHandle );

      Mit ReleaseFilter wird am Ende des Imports das Filterobjekt wieder freigegeben. Wurde die DLL nur von diesem einen Prozess verwendet, was im Protected-Mode immer der Fall ist, wird auch diese wieder aus dem Speicher entfernt.


    • CheckSerialNo

      function CheckSerialNo ( FilterHandle : tFilterHandle; EuroSN : PChar; FilterSN : PChar ) : Integer;

      Hier wird zum einen die jeweilige FilterSN überprüft, zum anderen aber auch ihre Gültigkeit bei Verwendung mit dem ausgewählten Mandanten (EuroSN) abgecheckt: Mehrere Mandanten bedeutet also mehrere Seriennummern, die alle im Filter-INI eingetragen sein müssen.
      Ist der S/N-Check erfolgreich, wird Null zurückgegeben.


    • GetInfo

      Filter: function GetInfo ( FilterHandle : tFilterHandle; Name : PChar; Info : PChar ) : Integer;
      Euro: function GetFilterInfo ( FHandle : tFilterHandle; Name : String; var Info : String ) : Boolean;

      Liest die allgemeinen Filterinformationen aus: Name, Version, Datum, Import oder Export, Datenformat, Maske für die Importdateien, usw. (siehe Tabelle). Mit dem Parameter Name wird der Bezeichner der abzurufenden Information übergeben, Info liefert das Ergebnis. Die vorbesetzten Infos kommen alle aus der DLL, auch wenn sie teilweise in der Filter-INI-Datei auftauchen. Die INI-Einträge werden bei der Filter-Initialisierung aber immer mit den Originalen aus der DLL überschrieben.
      In der EURO werden wegen der Kompatibilität zum alten Filter-Konzept die INI-Einträge teilweise direkt zugelesen. Da dies geschieht, bevor die DLL initialisiert wird, ist die EURO auf korrekte Infos aus der Filter-INI angewiesen, sonst ist ein Aufruf aus der EURO nicht möglich, bzw. der Filter wird in der EURO gar nicht erst zur Auswahl angeboten!


    • PutInfo

      Filter: Filter: function PutInfo ( FilterHandle : tFilterHandle; Name : PChar; Info : PChar ) : Integer;
      Euro: function PutFilterInfo ( FHandle : tFilterHandle; Name : String; Info : String ) : Boolean;

      Hiermit lassen sich Info-Einträge während der Filter-Laufzeit verändern. Ein Beispiel ist das Setzen des Datenpfades (siehe Tabelle), der immer endgültig vom aufrufenden Programm bestimmt wird. Zu beachten: Diese Funktion nimmt keine dauerhaften Änderungen vor, sondern wirkt immer nur zur Laufzeit! So bleibt z.B. der Inhalt der INI-Datei hiervon unberührt.


    • ShakeHands

      function ShakeHands ( FilterHandle : tFilterHandle; Handshake : tHandshake ) : tHandshake;

      Diese Funktion stellt die Protokollschnittstelle zwischen Hauptprogramm und Filter-DLL dar. Hiermit wird der komplette Ablauf eines einzelnen Imports gesteuert. Kommandos bzw. Anforderungen können über diese Funktion sowohl vom Programm an den Filter als auch umgekehrt übermittelt werden. Initiator ist aber immer das Hauptprogramm, das eine Aktion anfordert und eine Reaktion vom Filter erhält, die nicht nur eine Bestätigung sein kann, sondern selbst wieder eine Aktionsanforderung. ShakeHands wird in einer Schleife so oft abgearbeitet, bis entweder die einzulesenden Daten zu Ende sind, ein Benutzerabbruch erfolgt oder ein schwerer Fehler aufgetreten ist.
      In der Tabelle sind die wichtigsten Handshake-Codes mit einer kurzen Beschreibung aufgeführt. Die Codes sind im Sourcecode als numerische Konstanten definiert, die über symbolische Namen ("fh...") angesprochen werden können.


    • GetFieldInfo

      Filter: function GetFieldInfo ( FilterHandle : tFilterHandle; Name : PChar; Typ : PChar ) : Integer;
      Euro: function GetFieldInfo ( FHandle : tFilterHandle; var Name : String; var Typ : Char ) : Boolean;

      Anders als im oben beschriebenen GetInfo wird hier nicht etwa mit Name eine Feldinformation abgerufen, sondern diese Funktion wird solange mit leeren Parametern Name und Typ aufgerufen, bis das Ergebnis Null bzw. false ist. Beides sind also Rückgabeparameter. Auf diese Weise werden alle im Filter definierten Feldnamen und -typen während der Initialisierung ausgelesen und stehen dann im aufrufenden Programm zur Verwendung mit GetField bzw. PutField zur Verfügung.


    • GetField

      Filter: function GetField ( FilterHandle : tFilterHandle; Name : PChar; Data : PChar ) : Integer;
      Euro: function GetFilterField ( FHandle : tFilterHandle; Name : String; var Data : String ) : Boolean;

      Mit GetField werden nacheinander die Inhalte der jeweils  mit Name bezeichneten Felder abgefragt, nachdem ein kompletter Datensatz im Speicher steht. Die Werte werden in Data zurückgegeben und zwar immer als String. Über den mit GetFieldInfo ausgelesenen Typ weiß man, welchen Datentyp dieser String eigentlich repräsentiert.


    • PutField

      Filter: function PutField ( FilterHandle : tFilterHandle; Name : PChar; Data : PChar ) : Integer;
      Euro: function PutFilterField ( FHandle : tFilterHandle; Name : String; Data : String ) : Boolean;

      Diese Funktion ist das Gegenstück zu GetField. Hiermit sollen Datensätze für den Export präpariert werden. Da bis jetzt keine Exportfunktion realisiert ist, wird sie im Augenblick nur filterintern genutzt.


    • GetError

      Filter: function GetError ( FilterHandle : tFilterHandle; ErrMsg : PChar ) : Integer;
      Euro: function GetFilterError ( FHandle : tFilterHandle; var Msg : String ) : Integer;

      GetError wird benutzt, um nach Fehlfunktionen vom Filter generierte Fehlercodes bzw. -Meldungen auszulesen.

    Zum  besseren Verständnis folgt eine kurze Einführung in die prinzipielle Funktionsweise, die für alle Filter gleich ist. Wird diese geändert, bedeutet das eigentlich eine Neuentwicklung, und man kann sich den Aufwand sparen, unter großen Mühen die vorhandenen Filter anzupassen. Es geht dann mit Sicherheit schneller, das Konzept neu aufzubauen und sämtliche Filter nach den neuen Richtlinien neu zu programmieren.
    Einen einzelnen Import-Vorgang kann man grob in vier Phasen einteilen:

    1. Initialisierung
    2. Einlesen (auch mehrerer Dateien)
    3. Nachbearbeitung
    4. Freigabe

    Der komplette Ablauf befindet sich in der Unit DLF.PAS im Verzeichnis P:\LIB\CNLIB: Die Hauptroutine ExecDLLFilter wird aus der EURO-Unit EXECS.PAS immer dann statt dem älteren CNExec (dieses führt die EXE-Filter aus) aufgerufen, wenn die INI-Datei des Filters die Zeile DLL=Ja enthält. ExecDLLFilter wiederum ruft entsprechend den vier genannten Phasen die Funktionen InitDLF (Initialisierung), DLFImport (Einlesen und Nachbearbeitung) und CloseDLF (Freigabe) auf, alle ebenfalls in DLF.PAS zu finden.


    procedure ExecDLLFilter ( DLLPath : String; INIPath : String );
    begin

        if InitDLF(DLFPara,DLLPath,INIPath) then
        begin
            DLFImport(DLFPara);
            if ErrorAbort(DLFPara) then;
            CloseDLF(DLFPara);
        end else
            if DLFPara<>nil then
            begin
                if ErrorAbort(DLFPara) then;
                CloseDLF(DLFPara);
            end;

    end;

     

    Hier nun die vier Phasen im Detail:

    • Initialisierung

      Erster Schritt ist das Laden der gewünschten Filter-DLL. Hierzu ist es unbedingt erforderlich, dass das Programm (EURO oder CNFilter) Zugriff auf eine gültige INI-Datei zu diesem Filter hat und diese im Verzeichnis \CN\Filter\INI vorfindet. Sonst wird der entsprechende Filter in der jeweiligen Auswahl garnicht erst angeboten. Der Name der INI-Datei muss dem Namen der Filter-DLL entsprechen. Wichtig ist außerdem, dass die Zeile "DLL=Ja" enthalten ist. Diese ist das einzige Unterscheidungsmerkmal gegenüber den alten EXE-Filtern, und entscheidet darüber, ob nach einer EXE- oder DLL-Datei gesucht wird. Diese wird dann anschließend über einen Aufruf der Prozedur AssignFilter geladen und das Filterobjekt wird initialisiert, wobei auch sämtliche benötigten Datenstrukturen angelegt werden, so vor allem der Daten-Puffer, der so dimensioniert ist, dass er mindestens einen Datensatz aufnehmen kann. Bei Erfolg erhält das aufrufende Programm ein gültiges FilterHandle (>0) für die Folgeaufrufe zurück.
      Im nächsten Schritt werden sämtliche Informationen (siehe Tabelle) ausgelesen, die über GetInfo ermittelt werden können und es wird überprüft, ob eine Lizenz für die Verwendung mit dem aktuellen Mandanten vorliegt. Dies geschieht indem in der INI-Datei nach dem Abschnitt "Caller" gesucht wird. Dort muss für jeden Mandanten ein Lizenznummernpärchen aufgeführt sein: links die EURO-S/N des Mandanten, rechts vom Gleichheitszeichen die zugehörige Filter-S/N. Beide Seriennummern müssen ohne Bindestriche und in Großschreibung vorliegen. Wird kein passendes Nummernpärchen gefunden, wird der Benutzer zur Eingabe der S/N aufgefordert, die bei erfolgreicher Überprüfung in der INI-Datei abgespeichert wird. Dieser gesamte Vorgang wird von der Funktion CheckSerialNo ausgeführt, einschließlich Abfrage und Abspeichern.
      Nach erfolgreicher Lizenzüberprüfung wird mit wiederholtem Aufruf von GetFieldInfo ermittelt, welche Datenfelder vom Filter überhaupt bedient werden. Feldname und Feldtyp der ausgelesenen Felder werden im Hauptprogramm zur späteren Verwendung beim eigentlichen Import in einem Array gespeichert. In diesem Zuge wird auch festgestellt, ob sich unter den Feldern der Hauptschlüssel der zugehörigen EURO-Datenbank befindet, also beim Artikelstamm die Artikelnummer - andernfalls wird der Import gar nicht erst gestartet.
      Schließlich wird nach den einzulesenden Daten gesucht. In der EURO, wie früher schon üblich, auf den Disketten-Laufwerken, in der CD-Root und im EURO-Filterverzeichnis. Im Windows-Programm CNFilter hat man dagegen die Wahl, Daten aus jedem beliebigen Verzeichnis (auch gemischt) einzulesen. Ein weiterer wesentlicher Unterschied zwischen dem DOS- und dem Windows-Aufruf ergibt sich dadurch, dass man in CNFilter bei mehreren Dateien die Reihenfolge der Abarbeitung festlegen kann, während in der EURO in der Sequenz importiert wird, die auch ein Directory-Aufruf anzeigen würde. Dies ist natürlich wichtig für Importformate, bei denen eine bestimmte Reihenfolge eingehalten werden muss: z.B. Rabatt-Datei bei Datanorm.
      Die Bereitstellung der einzulesenden Dateien ist bis hierhin eine Funktionalität des aufrufenden Programms, die Filter-DLL hat mit dem Auffinden der Daten nichts zu tun, sondern erwartet von EURO oder CNFilter die Übergabe eines gültigen Pfades auf die einzulesenden Dateien. Diese Übergabe des Datenpfades erfolgt erst in der nächsten Phase des Imports, dem Einlesen, und zwar für jede einzelne Import-Datei getrennt. Das heißt, falls mehrere Dateien hintereinander importiert werden sollen, muss das aufrufende Programm sich diese merken und sie eine nach der anderen dem Filter zur Verfügung stellen.


    • Einlesen

      Jeder Durchlauf des Abschnittes Einlesen entspricht dem Import einer einzelnen, kompletten Datei. In einem ersten Schritt überprüft das aufrufende Programm, ob die Zieldatenbank (im Augenblick immer _ARTIKEL.DAT) und die Import-Datei zu öffnen sind, öffnet den Artikelstamm und übergibt an die Filter-DLL den Pfad der einzulesenden Daten. Hierzu wird die Funktion PutInfo verwendet, die mit den Parametern Name="FILEPATH" und Info= aufgerufen wird. Anschließend werden über GetInfo die Anzahl der Datensätze und der im Fortschrittsfenster anzuzeigende Titel ermittelt. Falls kein Titel vorliegt, wird dort der Dateiname der Import-Datei angezeigt.
      In der Folge wird der eigentliche Import durchgeführt, gesteuert ausschließlich mit der DLL-Funktion ShakeHands, über die der Austausch der protokollarischen Daten (siehe Tabelle) erfolgt. Der Standardablauf ist so, daß das Hauptprogramm nach der erfolgreichen Initialisierung mit fhInitData mit fhRequestData solange Datensätze vom Filter anfordert, bis das Dateiende erreicht ist. Auf fhRequestData reagiert die Filter-DLL in der Regel mit einem der Codes, die anzeigen, dass ein kompletter Datensatz zur Übernahme bereitsteht (fhOK, fhRefresh, ...). In diesem Fall wird das Hauptprogramm nacheinander mit GetField die einzelnen Felddaten abfragen und die entsprechenden Felder im Artikelstammsatz besetzen. Dies geschieht allerdings nur für die Felder, die während der Initialisierung mit GetFieldInfo ermittelt worden sind, also nur diejenigen, die im Filter überhaupt definiert sind.


    • Nachbearbeitung

      In erster Linie, um die Anforderungen des Datanorm-Filters erfüllen zu können, wurde die Möglichkeit der Nachbearbeitung geschaffen. Konkret bedeutet das, der Filter-DLL wird ermöglicht, noch nach dem Ende aller einzulesenden Dateien weitere Daten zu liefern. Es handelt sich hierbei im Falle von Datanorm um die Lang- und Dimensionstexte. Da während des eigentlichen Imports hierfür nur einzelne Bausteine geliefert werden, müssen diese zwischengespeichert werden. Erst nachdem alle regulären Daten eingelesen sind, werden diese wieder abgerufen, korrekt zusammengesetzt und in einem zusätzlichen Durchgang dem Hauptprogramm zum Import angeboten. Die Zwischenspeicherung und den Abruf übernimmt dabei das Hauptprogramm in einer Btrieve-Datenbank, da ein indizierter Zugriff erforderlich ist, um die Bausteine gezielt abrufen zu können.
      Um unabhängig von der Felderübergabe eine Möglichkeit zum Datenaustausch zwischen Programm und DLL zu schaffen, wurde eine Struktur tTmpDat geschaffen, die im Hauptprogramm angelegt und im Filter initialisiert wird:

      tTmpDat = Record
          RecLen : Word;
          KeyLen : Word;
          Rec : Pointer;
      end;

      Die Struktur ist primitiv, d.h. sie kann mit beliebigen Daten gefüllt werden. Wichtig ist nur, dass mit RecLen die Länge der tatsächlich übergebenen Daten und mit KeyLen die Länge des Schlüssels ausgetauscht wird, der am Anfang des Datenbereiches stehen muß, auf den Rec zeigt. Rec wird von der Filter-DLL allokiert oder so gesetzt, daß er auf eine gültige Datenstruktur zeigt. Mit den Codes fhPutTempData und fhGetTempData kann die DLL in der Routine ShakeHands auf diese Weise beliebige Daten an das Hauptprogramm zur Zwischenspeicherung übergeben und auch wieder zurückfordern. Das Hauptprogramm muß nicht wissen, um welche Art von Daten es sich handelt. Es legt einfach den ganzen von Rec bestimmten Datenbereich unter dem übergebenen Schlüssel in einer temporären Btrieve-Datenbank ab.

    • Freigabe

      In dieser letzten, sehr kurzen Phase werden nacheinander die Filter-DLL mit ReleaseFilter wieder freigegeben, sämtliche verwendeten Dateien geschlossen und schließlich alle temporären Datenstrukturen wieder abgebaut.
      Diese Vorgänge bedürfen keiner näheren Erläuterung. Danach wird zum jeweiligen Menü des Hauptprogramms (EURO oder CNFilter) zurückgekehrt.

     

  • Filterkonstruktion
  • durch einfache Felddefinitionen

    Die einfachste Möglichkeit, um einen neuen Filter zu definieren, besteht darin, den Sourcecode eines vorhandenen Filter zu verwenden und dort die Datei- und Felddefinitionen anzupassen. Soweit man über den Aufbau der einzulesenden Daten genau informiert ist, es sich um eine einzeilige Import-Datenstruktur handelt und vor allem keine Felder zu berechnen sind, führt diese Methode für den Eingeweihten sogar schneller zum Erfolg, als den Universalfilter zu verwenden.

  • durch Ableiten von Filtermethoden

function CheckSerialNo(CallerSN,FilterSN:PChar):Boolean; virtual;
function GetInfo(Name,Info:PChar):Boolean; virtual;
procedure PutInfo(Name,Info:PChar); virtual;
function ShakeHands(Handshake:tHandshake):tHandshake; virtual;
function GetFieldInfo(Name:PChar;Typ:Char):Boolean; virtual;
function GetField(Name,Data:PChar):Boolean; virtual;
function PutField(Name,Data:PChar):Boolean; virtual;
function GetFilterError(Msg:PChar):Integer; virtual;
procedure SetFilterError(Err:Integer;Msg:PChar); virtual;
procedure ClearFilterError; virtual;
function InitProfile:Boolean; virtual;
function InitData:Boolean; virtual;
procedure ClearData; virtual;
function ReadData:tHandshake; virtual;
function PrepareData(HS:tHandshake):tHandshake; virtual;
procedure Protocol(ProtoLevel:Word;ProtoHead:PChar;ProtoMsg:PChar); virtual;

 

Tabelle der Infocodes

Hier die möglichen Werte für die Funktionen GetInfo und PutInfo. Über die Pascal-Konstante ("inf...") kann der Parameter Name im Sourcecode angesprochen werden. Alle Definitionen befinden sich in der Unit DLFTYPES.PAS im Verzeichnis T:\Lib\DOSWin. Die in der Spalte R/W eingetragenen Werte sagen aus, welche Informationen ausschließlich aus der DLL gelesen (R) und welche auch vom aufrufenden Programm aus gesetzt werden können (W).

Pascal-Konstante Name abgefragte Info R/W
infProductCode PRODUCTCODE

PC für Seriennummer

 R
infName NAME Filtername: beliebig lang, darf Blanks enthalten R
infDLLName DLLNAME Name der DLL: DOS, 8 Zeichen R
infVersion VERSION Versionsnummer R
infDate DATE Versionsdatum R
infDirection DIRECTION Datenrichtung: Import/Export R
infDatabase DATABASE EURO-Datenbank: z.Zt. nur Artikel R
infFilemask FILEMASK Dateimaske, z.B. "DAT*.*" RW
infFilePath FILEPATH Dateipfad RW
infDataType DATATYPE Datentyp: Fixed/CSV R
infSeperator SEPERATOR Feldtrenner: z.B. ";" R
infQuote QUOTE Anführungszeichen f. Strings: z.B.: " R
infRecSize RECSIZE größte Satzlänge, incl. R
infElements ELEMENTS Anzahl Datensätze R
infShowTitle SHOWTITLE Titel in der Fortschrittsanzeige R

 

Tabelle der Handshakes

Pascal-Konstante Bedeutung
fhOK Bestätigung, dass die vorherige Anforderung erledigt wurde, z.B. InitData oder RequestData. Dies ist der Standard-Rückgabecode des DLL-Filters und bedeutet nach InitData, dass jetzt Datensätze angefordert werden können, und nach RequestData, dass Daten zur Übernahme zur Verfügung stehen, die nach Maßgabe des Filters ohne Einschränkung übernommen werden können.
fhError Die Anforderung führte zu einem schweren Fehler. Die Fehlerursache kann anschließend mit GetError ausgelesen werden.
fhAbort Die Verarbeitung der aktuellen Import-Datei wird abgebrochen.
fhShowBar Fortschrittsanzeige ohne zusätzliche Aktion weiterzählen.
fhNoBar Überhaupt keine Aktion, auch keine Fortschrittsanzeige. Hier lässt sich, falls nötig, Application.ProcessMessages aufrufen
fhInitData Aufforderung des Hauptprogramms an die Filter-DLL, die Daten zu initialisieren: Datei öffnen und Anzahl der Datensätze ermitteln. Die Satzanzahl kann anschließend mit Hilfe von GetInfo ausgelesen werden und steht dann als Endwert für die Fortschrittsanzeige zur Verfügung.
Dies ist einer der beiden Standard-Handshakes, die vom Hauptprogramm an die Filter-DLL gerichtet werden.
fhEndOfData Das Ende der Import-Datei wurde erreicht.
fhResetData Aufforderung des Hauptprogramms an die Filter-DLL, die Daten zurückzusetzen, d.h. wieder auf den ersten Datensatz zu positionieren.
fhCloseData Aufforderung des Hauptprogramms an die Filter-DLL, die Import-Datei zu schließen.
fhRequestData Aufforderung des Hauptprogramms an die Filter-DLL, den nächsten Datensatz zur Verfügung zu stellen.
Dies ist der zweite Standard-Handshake, der vom Hauptprogramm an die Filter-DLL gerichtet wird.
fhUpdateData Antwort-Code auf RequestData: Daten stehen zur Verfügung und können ohne Einschränkung übernommen werden, d.h. vorhandene Daten werden mit neuen Werten überschrieben und nicht vorhandene Datensätze werden angelegt. In diesem Kontext gleiche Bedeutung wie fhOK.
fhCreateData Antwort-Code auf RequestData: wie fhUpdateData, allerdings werden vorhandene Daten nicht überschrieben (kein Refresh).
fhRefreshData Antwort-Code auf RequestData: wie fhUpdateData, allerdings werden vorher nicht vorhandene Daten auch nicht neu angelegt (kein Create).
fhRemoveData Antwort-Code auf RequestData: In den Daten wird nur der Schlüssel zur Verfügung gestellt. Der zugehörige Datensatz ist aus der EURO zu löschen.
fhGetTempData Anforderung der Filter-DLL an das Hauptprogramm, zuvor abgespeicherte Zwischendaten auszulesen und zur Verfügung zu stellen. Wird z.Zt. nur für Datanorm genutzt.
fhPutTempData Aufforderung der Filter-DLL an das Hauptprogramm, die mit TmpDataPtr übergebenen Daten für spätere Verwendung zwischenzuspeichern. Wird z.Zt. nur für Datanorm genutzt.