- This topic has 3 replies, 4 voices, and was last updated 10 years ago by .
-
Posts
-
Is possible to manage a twain session inside a DLL without using the window message loop of the application ?
I’ve tried this creating a secondary thread inside the DLL which create a hidden window and I pass this window handle on the OPENDSM message.
The application using a DLL funciton start the image scan ( MSG_ENABLEDS ) , and the secondary
thread receive the msg MSG_XFERREADY on your message loop and process all the scanning data, but when I exec the MSG_ENDFER msg this command remain blocked forever.
can help me please ?
thanks
stevenI would like to know that also… if i go multithread the GetMessage can’t receive the proper messages in the secondary thread.
I don’t want to lock the main app while waiting for the scan to complete… any help guys?
Nobody never answer my questions… 😆
Depending on the driver it should work. I’ve successfully done that with Fujitsu, Panasonic and Kodak scanners. HP on the other hand caused lots of problems so it’s not supported in our app.
Greets.
Wow, a 4+ year-old thread revived.
The TWAIN spec doesn’t seem to cover reentrancy or multithreading. Note that messages may be posted to the wrong message queue if TWAIN is called from a thread other than the one which owns its window. This can result in unresponsive UI or deadlocks (e.g. XFERREADY is never received). For maximum compatibility a process should make all TWAIN calls from a single thread: the one that owns the parent window provided to TWAIN. The thread that calls TWAIN does not have to be the app’s main UI thread; it can be a worker thread with it’s own message loop.
–