Sorry about the length of this question, I've tried to keep it brief and clear.
I am using the ABBYY API, via both the DLL interface and the COM interface. Our users can configure our application to use one or the other according to preference. When our application starts, it loads the engine in the required manner.
The way we implement our application is using a WPF/.Net GUI, and a C++ DLL (with no message pump) which implements the ABBYY processing.
Anyway, the DLL interface calls all have to be made from the same thread, therefore I have created a worker thread which processes all ABBYY requests. This is quite nice, as it allows us to remain responsive if an ABBYY API call hangs (we have a timeout).
I found that this did not work when using the in-proc COM interface. A client thread would send a request to the worker thread, and then wait until either the worker thread had performed its work using ABBYY API calls, or a timeout had elapsed. I found that the timeout always expired because the worker thread's first call to an ABBYY API hung, the client thread returned, and then the ABBYY API returned, allowing the worker thread to complete! It is as if the client thread grabs a resource, and the ABBYY calls cannot run until that resource has been released. I wonder if this is something to do with the .Net front end competing with the in-proc COM calls?
Anyway, I got round this in two ways. Firstly by running the ABBYY API calls in the client thread i.e. do not use the worker thread. Secondly by using the out-of-proc COM interface.
I have chosen to use the second solution, it allows our client thread to return a timeout error if the ABBYY calls take too long.
Does anyone know why the in-proc COM API calls do not work when done from a worker thread?