Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt

Use this file to discover all available pages before exploring further.

In diesem Abschnitt werden die wichtigsten Aspekte der Verwendung von ABBYY FineReader Engine in Anwendungen beschrieben, die in verschiedenen Programmiersprachen geschrieben sind. Außerdem finden Sie Verweise auf Artikel, in denen verwandte Themen behandelt werden. Die Programmierschnittstelle von FRE für Windows entspricht dem COM-Standard und kann in C/C++, .NET, Java oder mit jedem Entwicklungstool verwendet werden, das COM-Komponenten unterstützt. Die Engine kann auch für den Einsatz in Skriptsprachen wie VBS, JS und Perl angepasst werden. FRE für Linux kann in C/C++ und Java verwendet werden.

​
Laden, Initialisierung und Deinitialisierung

Initialisieren und deinitialisieren Sie ABBYY FineReader Engine nicht an den Einstiegspunkten anderer dynamischer Bibliotheken und auch nicht in Konstruktoren und Destruktoren statischer und globaler Objekte, die in dynamischen Bibliotheken implementiert sind, da diese an den Einstiegspunkten dynamischer Bibliotheken aufgerufen werden.
ABBYY FineReader Engine sollte an anderer Stelle initialisiert und deinitialisiert werden, zum Beispiel in der Funktion main oder WinMain eines ausführbaren Moduls.
Unter Windows ist diese Einschränkung darauf zurückzuführen, dass die Win32-Funktionen LoadLibrary und FreeLibrary nicht reentrant sind.
Während der Initialisierung setzt ABBYY FineReader Engine die Einstellung LC_CTYPE auf die Standardwerte des Betriebssystems zurück. Dies sollte berücksichtigt werden, wenn Ihre Anwendung von gebietsschemaabhängigen Diensten abhängt.
Unter Windows setzt FRE die LC_CTYPE-Einstellung von msvcrt.dll zurück.
Die Ausnahme “Engine deinitialization failed” kann während der Deinitialisierung des Engine-Objekts ausgelöst werden, wenn nicht alle von der Anwendung erstellten und verwendeten Objekte vor der Deinitialisierung des Engine-Objekts gelöscht wurden. Wenn Sie mit Programmiersprachen arbeiten, die keine automatische Speicherbereinigung haben (z. B. C++), müssen Sie entweder Smart-Pointer-Klassen verwenden (unter Windows siehe die Beispiele in C++ (COM)) oder Objekte, die durch Erstellungsmethoden erzeugt wurden, freigeben, sobald sie nicht mehr benötigt werden. Wenn alle Objekte gelöscht wurden, kann die Ausnahme durch den Garbage Collector verursacht werden. Wenn die Anwendung unter Windows mit Visual Basic .NET entwickelt wird, werden alle Objekte mit dem Wert Nothing nur zum Löschen vorgemerkt, aber nicht gelöscht. Der genaue Zeitpunkt, zu dem der Garbage Collector das Objekt löscht, ist nicht bekannt. Daher sollten Linux- und macOS-Benutzer den Garbage Collector vor der Deinitialisierung des Engine-Objekts explizit aufrufen. Windows-Benutzer sollten vor der Deinitialisierung des Engine-Objekts die folgenden Methoden aufrufen, damit der Garbage Collector das Objekt löscht: 
GC.Collect()
GC.WaitForPendingFinalizers()
Wenn Sie das Protokoll verwenden (es kann mit der Methode StartLogging des Engine-Objekts aktiviert werden), kann in dieser Situation auch die Meldung “Warning: DeinitializeEngine() has detected external references to FREngine objects. It can indicate a leak if programming platform without automatic garbage collection is used.” erscheinen. Selbst wenn Sie den Garbage Collector explizit aufrufen (in FRE für Windows ist dies GC.Collect), bedeutet das nicht immer, dass die Objekte sofort gelöscht werden. Wenn Sie in Umgebungen mit automatischer Speicherbereinigung arbeiten, können Sie diese Meldung ignorieren. Bei der Arbeit in Umgebungen ohne automatische Speicherbereinigung (z. B. C++) können diese Ausnahme und diese Meldung auf ein Problem in Ihrem Quellcode hinweisen. Manche Objekte werden möglicherweise nicht korrekt behandelt, was zu einem Speicherleck führen kann. Nach der Deinitialisierung der Engine werden jedoch in jedem Fall alle FineReader Engine-Objekte gelöscht, sodass das Speicherleck im clientseitigen Code auftreten kann, d. h. wenn Sie eigene Wrapper für die FineReader Engine-Objekte erstellen und diese vor der Deinitialisierung nicht freigeben. Verwenden Sie nach Möglichkeit die Eigenschaft TotalObjectsCount des Engine-Objekts. Sie gibt die Anzahl der nicht freigegebenen Objekte zurück und kann Ihnen dabei helfen, das Speicherleck aufzuspüren.

​
Auch in diesem Abschnitt