Passer au contenu principal
Cette section décrit les principaux aspects de l’utilisation d’ABBYY FineReader Engine dans des applications écrites dans différents langages de programmation et renvoie vers des articles traitant de sujets connexes. L’interface de programmation d’applications de FRE for Windows est conforme à la norme COM et peut être utilisée en C/C++, .NET, Java ou avec tout outil de développement prenant en charge les composants COM. L’Engine peut également être adapté à une utilisation avec des langages de script comme VBS, JS et Perl. FRE for Linux peut être utilisé avec les langages C/C++ et Java.

​
Chargement, initialisation et désinitialisation

N’initialisez ni ne désinitialisez ABBYY FineReader Engine aux points d’entrée d’autres bibliothèques dynamiques, ni dans les constructeurs et destructeurs d’objets statiques et globaux implémentés dans des bibliothèques dynamiques, car ceux-ci sont appelés aux points d’entrée des bibliothèques dynamiques.
ABBYY FineReader Engine doit être initialisé et désinitialisé ailleurs. Par exemple, dans la fonction main ou WinMain d’un module exécutable.
Sous Windows, cette restriction est due au fait que les fonctions Win32 LoadLibrary et FreeLibrary ne sont pas réentrantes.
Lors de l’initialisation, ABBYY FineReader Engine rétablit le paramètre LC_CTYPE à la valeur par défaut du système d’exploitation. Il faut en tenir compte si votre application dépend de services liés aux paramètres régionaux.
Sous Windows, FRE rétablit le paramètre LC_CTYPE de msvcrt.dll.
L’exception “Engine deinitialization failed” peut être levée lors de la désinitialisation de l’objet Engine si tous les objets créés et utilisés par l’application n’ont pas été supprimés avant la désinitialisation de l’objet Engine. Si vous travaillez avec des langages de programmation qui ne disposent pas d’un garbage collection (par exemple, C++), vous devez soit utiliser des classes de pointeurs intelligents (sous Windows, voir les samples en C++ (COM)), soit libérer les objets créés par des méthodes de création lorsqu’ils ne sont plus nécessaires. Si tous les objets ont été supprimés, l’exception peut être due au fonctionnement du garbage collection. Si l’application est développée sous Windows avec Visual Basic .NET, tous les objets ayant la valeur Nothing sont seulement marqués pour suppression, sans être supprimés. Le moment exact où le garbage collection supprime l’objet n’est pas connu. Par conséquent, les utilisateurs de Linux et de macOS doivent appeler explicitement le garbage collection avant la désinitialisation de l’objet Engine. Les utilisateurs de Windows doivent appeler les méthodes suivantes avant la désinitialisation de l’objet Engine afin que le garbage collection supprime l’objet : 
GC.Collect()
GC.WaitForPendingFinalizers()
Si vous utilisez le journal (il peut être activé avec la méthode StartLogging de l’objet Engine), le message “Avertissement : DeinitializeEngine() a détecté des références externes à des objets FREngine. Cela peut indiquer une fuite si une plateforme de programmation sans garbage collection automatique est utilisée.” peut également apparaître dans cette situation. Même si vous appelez explicitement le garbage collection (dans FRE pour Windows, il s’agit de GC.Collect), cela ne signifie pas toujours que les objets sont supprimés immédiatement. Lorsque vous travaillez dans des environnements avec garbage collection, vous pouvez ignorer ce message. Lorsque vous travaillez dans des environnements sans garbage collection (comme C++), cette exception et ce message peuvent indiquer un problème dans votre code source. Certains objets peuvent être gérés incorrectement, ce qui entraîne une fuite de mémoire. Toutefois, après la désinitialisation d’Engine, tous les objets FineReader Engine seront supprimés dans tous les cas. La fuite de mémoire peut donc se produire dans la partie cliente du code, c’est-à-dire si vous créez vos propres wrappers pour les objets FineReader Engine et ne les libérez pas avant la désinitialisation. Nous vous recommandons d’utiliser la propriété TotalObjectsCount de l’objet Engine, qui renvoie le nombre d’objets non libérés et peut vous aider à localiser la fuite de mémoire.

​
Voir aussi dans cette section