Das SuperCom DUAL API

F: ActiveX bzw. ActiveX API: Was ist der Unterschied ?
A: ActiveX bezeichnet das SuperCom ActiveX Steuerelement (OLE / COM control). ActiveX API bezeichnet ein spezielles Objekt-Orientiertes API, dass mit dem SuperCom ActiveX Steuerelement (OLE / COM control) eingeführt wurde und aktuell über das SuperCom ActiveX Steuerelement oder die SuperCom .NET Class Library (Klasse TSCom) angeboten wird. Änliche High-Level Klassen sind u.a. auch für C++, Pascal / Delphi und Java verfügbar.

Beispiel

  SCom.PortOpen = True
  SCom.Output = "Hello"

F: Was ist das SuperCom DUAL API ?
A: Das SuperCom DUAL API besteht aus einem ActiveX API und einem DLL API.
ActiveX API: Das ActiveX API besteht aus Eigenschaften, Methoden und Ereignissen, die über ein ActiveX Steuerelement (OLE / COM Control) oder die SuperCom .NET Class Library bereitgestellt werden.
Das ActiveX API wurde über das SuperCom DLL API implementiert.
DLL API: Das DLL API ist die Kombination aus Laufzeit Modul(en) (.DLL oder .so) und Compiler abhängige Import-Modul(en) (.LIB, .BAS, .PAS, .TPU etc.). Das Import-Modul wird im Projekt eingebunden und compilert. Dadurch erhält die Anwendung den Zugriff auf die Funktionen der DLL. Eine DLL ist eine externe Bibliothek mit Funktionen. Diese wird üblicherweise vom Betriebssystem (z.B. Windows, Linux, OS/2) geladen sobald die Anwendung die Funktionen benötigt. Der Einsatz von DLLs macht die Anwendung kleiner, verkürzt die Ladezeit und die DLL kann von mehreren Anwendungen gleichzeitig genutzt werden. Moderne Betriebssyteme bestehen in größen Teilen aus Dynamischen Bibliotheken (z.B. Windows API). Das SuperCom DLL API integriert sich also nahtlos im das Modularitäts-Konzept von Windows, Linux oder OS/2 und ist dabei sehr einfach zu nutzen.

Bei einem DUAL API Paket kann ein API oder auch beide API's genutzt werden.

F: Was ist das SuperCom DLL API ?
A: Das SuperCom DLL API ist die Kombination aus Laufzeit Modul(en) (.DLL) und Compiler abhängige Import-Modul(en) (.LIB, .BAS, .PAS, .TPU, NET Klasse, C++ Klasse, Delphi Klasse, etc.). Das Import-Modul wird im Projekt eingebunden und compilert. Dadurch erhält die Anwendung den Zugriff auf die Funktionen der DLL.

Das DLL API ist funktionsgemäß in zwei Gruppen gegliedert: a) die Low Level Funktionen arbeiten Hardwarenahe und der jeweilige Namen beginnt mit Com... (z.B. ComInit) und b) die High Level Funktionen arbeiten über die Low Level Funktionen, sind nicht an bestimmte Hardware gebunden und der jeweilige Namen beginnt mit RS... (z.B. RS_TXPInTime).

Beispiel

  ComInit(COM_1)
  ComSetState(COM_1, 9600,,,)
  ComWriteEx(COM_1, "Hello", strlen("Hello"))

DLL: Eine DLL ist eine externe Bibliothek mit Funktionen. Diese wird üblicherweise von Windows geladen sobald die Anwendung die Funktionen benötigt. Der Einsatz von DLLs macht die Anwendung kleiner, verkürzt die Ladezeit und die DLL kann von mehreren Anwendungen gleichzeitig genutzt werden. Der größte Teil des Windows Betriebssystems besteht aus DLLs (Windows API). Das DLL Konzept ist der Stützpfeiler des Windows Modularitäts-Konzeptes. Das SuperCom DLL API integriert sich also nahtlos im Windows Modularitäts-Konzept und ist dabei sehr einfach zu nutzen.

F: Was ist das SuperCom ActiveX API ?
A: Das SuperCom ActiveX API besteht aus Eigenschaften und Methoden, die über ein ActiveX Modul oder die SuperCom .NET Class Library bereitgestellt werden. Das ActiveX API erscheint nach Installation automatisch in der Entwicklungsumgebung z.B. Visual Basic, VBA, Visual C++, C++ Builder, C#, VB .net, Delphi, etc.

F: Muss ich mich im voraus für ein API entscheiden ?
A: Anwender eines SuperCom DUAL API Pakets können sich das passende API aussuchen oder auch ActiveX eigenschaften mit Aufrufen von DLL Funktionen kombinieren. Zusätzlich enthält SuperCom flexible Klassen-Bibliotheken (z.B. für C++, C#, Delphi, Java, Pascal, VB net u.a.), welche direkt mit dem DLL API "sprechen". Damit steht eine sehr große Sammlung an Funktionen für die Anwendung zur Verfügung. Es eröffnen sich ungeannte Möglichkeiten. So ist es z.B. möglich während die Datenverbindungen mit den intelligenten ActiveX Eigenschaften verwaltet wird, DLL Funktionen für verschiedene "Low Level" Aufgaben aufzurufen. Selbst die Ereignisverwaltung im ActiveX lässt sich mittels DLL Funktionen ergänzen oder ändern. Das DLL API enthält auch intelligente "High Level" Funktionen, die von Fall zu Fall schneller sind oder mehr Möglichkeiten bieten als die entsprechende ActiveX Eigenschaften oder Methoden.

F: Und was nutze ich in einer NET Entwicklungsumgebung ?
A: Beim Einsatz unter dem Microsoft .NET Framework (z.B. C#, VB Net) stehen sowohl das DLL API als auch das ActiveX API zur Verfügung. Beide API sind kompatibel zu den bekannten und glänzen mit .NET spezifischen Erweiterungen. Über .NET Klassen stehen die bekannten Funktionen zur Verfügung. Das ActiveX API kann dabei auch über die SuperCom .NET Klasse TSCom genutzt werden ohne dabei das SuperCom ActiveX Steuerelement einzubinden.

Das SuperCom ActiveX Steuerelement kann, bei Bedarf, auch weiterhin als ActiveX unter .NET verwendet werden.

Die SuperCom .NET Class Library ist in jedem DLL API und DUAL API komplett in C# Quelltext enthalten und kann mit NET Compilern wie C#, VB Net, C++ usw. benutzt werden. Die SuperCom .NET Class Library ist enthalten in 32-Bit und 64-Bit SuperCom Pakete.

.NET Code Stücke      FAQ      Liste mit .NET Beispiel-Programmen     Andere unterstützte NET Technologien

        using ADONTEC.Comm;  // C# quelltext in SComClass.cs
           :                 // VB Net referenziert die Klassen DLL
           :
        public class MYSCOM : TSCom
        {
            public MYSCOM(int CommId, Form frm)
                : base(CommId, frm) // das Window Handle an TSCom
            {

            }
            protected override void OnComm(OnCommEventArgs e) [OnComm +-]
            {
                int SComEvent = (int)e.EventCode;

                if (SuperCom.BitsSet(SComEvent, SuperCom.EV_RXCHAR))

                if (SuperCom.BitsSet(SComEvent, SuperCom.EV_TXEMPTY))

                if (SuperCom.BitsSet(SComEvent, SuperCom.EV_TRIGGER))

                if (SuperCom.BitsSet(SComEvent, SuperCom.EV_RING))
                   :
                   :
                e.RetCode = 0;
            }
            protected override void OnConnect(OnConnectEventArgs e) [OnConnect +-]
            {
                switch (e.Action) // handle event
                {
                    case SuperCom.acCONNECT_INFO:
                    case SuperCom.acCONNECT_DIALING:
                    case SuperCom.acCONNECT_OK:
                       :
                       :
                }
            }
            protected override void OnFile(OnFileEventArgs e) [OnFile +-]
            {
                switch (e.Action)
                {
                    case SuperCom.acFILENAME:
                    case SuperCom.acFILEDATA:
                    case SuperCom.acSYN:
                    case SuperCom.acRXING:
                    case SuperCom.acTXING:
                    case SuperCom.acRXFIN:
                    case SuperCom.acTXFIN:
                        :
                }
            }
            protected override void OnDataPacket(OnDataPacketEventArgs e) [OnDataPacket +-]
            {
                switch (e.Action)
                {
                    case OnDataPacketEventCode.SCOMM_DATAPACKET_OK:
                    case OnDataPacketEventCode.SCOMM_DATAPACKET_NOK:
                    :
                }
            }

        } //MYSCOM

        SCom = new MYSCOM(Com, frm1);

        // Parameter..
        SCom.ComType = ComType.COMTYPE_RS232; // seriell, TAPI, TCP/IP, ISDN*
        SCom.Settings = "115200,N,8,1";
                // oder
        SCom.BaudRate = 115200;
        SCom.DataBits = 8;
        SCom.StopBits = StopBits.One;
        SCom.Parity = Parity.None;

        SCom.Handshaking = Handshaking.SCOMM_HANDSHAKE_CTS;

        SCom.PortOpen = true; // Bereit für Aktionen...
         :                                                         [Triggers +-]

        // ein paar Trigger um Zeichenketten zu überwachen ?
        SCom.Trigger = SuperCom.StringToByteArray("Username");
        SCom.TriggerAction = TriggerAction.SCOMM_TRIGGER_ADD;
        SCom.Trigger = SuperCom.StringToByteArray("Password");
        SCom.TriggerAction = TriggerAction.SCOMM_TRIGGER_ADD;
                                                                   [Modem | Kabel]
        // Verbindung mittels Modem zu entfernten Rechner aufbauen
        SCom.ConnectAddress="1234 5678 99"; // "www.weburl.com:9000";
        SCom.Connect = true;
        // direkte Kabelverbindung (z.B. NULL Modem Kabel) ...
         -
         -
         :
        // Datei übertragen
        SCom.FileName = "sales.doc";
        SCom.Protocol = Protocol.PROTOCOL_ZMODEM;
        SCom.FileOptions = FO_RESUME; // Optional: unterbrochene Dateiübertragung fortsetzen
        SCom.FileTransmit = true;
         :
  

Im obigen Beispiel hatten wir serielle Kommunikation. Jetzt sollten Dateien zu
einem TCP/IP Server übertragen werden. Wir können dafür eine neue Klasse erzeugen
oder die bestehende weiternutzen.
         :
        SCom.PortOpen = false; // diese beenden...
        SCom.CommPort = ClientCom;  // comm index bei Bedarf ändern..
        SCom.ComType = ComType.COMTYPE_WINSOCK_CLIENT; // serial, TAPI, TCP/IP, ISDN*
        SCom.PortOpen = true; // bereit...
         :
              // Verbindung zum TCP/IP server aufbauen,..
        SCom.ConnectAddress="www.weburl.com:9000";
        SCom.Connect = true;
         :
              // Datei senden
        SCom.FileName = "sales.doc";
        SCom.Protocol = Protocol.PROTOCOL_ZMODEM;
        SCom.FileTransmit = true;
         :
  

F: Ist es möglich die SuperCom Funktionen zusammen mit einem anderen Kommunikations-Toolkit zu nutzen ?
A: Das SuperCom bietet Funktionen um Verbindungen, die mittels anderen Toolkits hergestellt wurden, zu integrieren. Beispielsweise eine Anwendung, die eine TCP Komponente für den Verbindungsaufbau nutzt, möchte das SuperCom ZMODEM Dateiübertragungsprotokoll nutzen. Beispiele sind vorhanden.
Hinweis: Leider enthalten nicht alle Fremd-Komponenten die notwendige Information. Deshalb empfehlen wir den Kontakt zu unserem technischen Support um die Problemstellung zu erörtern.

F: Habe ich Einfluss auf die Ereignismeldung ?
A: Ja, sowohl im ActiveX API als auch im DLL API ist es möglich ungewollte Ereignisse abzuschalten.

F: Ist es möglich die Ereignismeldung auf niedrige Ebene zu beobachten und anzupassen ?
A: Eine eher seltene Anwendung doch es ist möglich. Das DLL API ermöglicht es eigene Funktionen in die Ereignis-Meldekette einzubinden. Dadurch können Ereignisse beobachtet, abgefangen, verändert oder ergänzt werden bevor diese die Anwendung erreichen.
Siehe auch das folgende C/C++ Beispiel.

Event Filter-Funktion: Beispiel

// Die folgende Event-Funktion filtert das Modem-Ereignis "RING",
// damit es nicht an die Anwendung gemeldet wird.

   PUSEREVENTPROC pXEventProc = NULL;  // Vorgänger- bzw. Original-Funktion

   DWORD COMMAPI EventFilterProc (TCOMMID CommId, DWORD SComEvent)
   {
      DWORD Res=0;

      if (SComEvent & EV_RI)
      {
            // Das Bit löschen, das wir nicht gemeldet haben möchten
            // Anderen Ereignisse, soweit eingeschaltet, erreichen die Anwendung
         SComEvent = ~EV_RI;  // löschen
         SComEvent |= EV_DCD; // setzen
      }

            // Wenn noch etwas zu melden ist, wird die
            // Vorgänger- bzw. Original-Funktion aufgerufen
      if ( (SComEvent != 0) && (pXEventProc != NULL) )
         Res = ComCallUserEventProc (pXEventProc, CommId, SComEvent); 

      return (Res);
   }

// Initialisierung:
// Zuerst wird die neue Ereignis-Funktion installiert
// und die Adresse der Vorgänger-Funktion gemerkt.

   pXEventProc = ComGetSetEventProc(CommId, EventFilterProc);
     :
     :

Home   Back

It Simply Works!

Updated on: 2023-07-04 15:35:38