Does anyone have implemented the Twain functionality in parallel with MICR (CMC7) recognition?
We are using CMC7 recognition on a DLL module that implements MICR recognition from GdPicture alongside with engines. It combines the results for better performance.
We've just implemented the twain integration using GdPicture (v14.1.122) in a thread that save front and back images. When it finishes saving both images we move them to another folder where another thread read them and runs the MICR recognition.
We noticed that image indices returned by GdPicture aren't local: when running only the twain without the MICR recon, indexes are returned in sequential order (1,2,3,4 and so on). But when we enable the MICR on the other thread this sequence is broken: it returns something like 1,2,3,4,49,50,51 (since our MIRC solution does some image processing, it may request GDP many different images).
The thing is: when running with the MICR on parallel, the twain module fails to save the last image (the back from the last document): SaveAsTIFF returns 0 but with GetStat we get 2 (GdPictureStatus_InvalidParameter).
Thanks for your feedback and for best describing your issue.
We would like to take a look at this further on our end. Does this only occur when you use both TWAIN+MICR in your code? Or can this be replicated only using the MICR parallel processes feature?
If this can be isolated down to only using MICR I would appreciate if you could provide me with a code project allowing me to reproduce the issue on my end.
If we are able to replicate this our developpers can then start working on a fix if this is indeed an issue internally on our end.
Feel free to contact us and provide this to us here:
Both codes (TWAIN and MICR recon) works great when running independently. The issue only seems to occur when both are running in parallel: we have a DLL (C++ COM interface) that implements both the TWAIN and MICR code on a custom class.
The TWAIN code runs on a thread that talks to the scanner and save images to a folder. Another thread wait for a set of images to be produces (front, back) them calls the MICR code using another class instance (each thread use their own class instance, which use their own GDP objects as private members, thus no obj is shared on our side).
Btw, this all was observed while running with version 122. We'll test it on 124 asap.
Thanks for the response. I am not sure if you have contacted us via our support platform. If you have, we have likely already handled/are handling your issue.
This is very odd that this only occurs when both processes work together.
To proceed further we would be needing a code project isolating what you are trying to do so I may attempt to reproduce this on my end.
You can provide this to me via sending us this in a zip via our support platform for privacy if you need or you can provide me with a download link if this is not confidential.
Who is online
Users browsing this forum: No registered users and 1 guest