Which parts of the communication with TWAIN can be put into another thread, e.g. a BackgroundWorker? Or: Is it possible to split the loop that handles the image transfer?
Some scanner drivers scan all images before returning to the calling application which forces the application to handle all images at once. This results in e.g. OutOfMemoryException or weird behavior in my WPF application when suddenly all events (raised after every scanned image) have to be handled at once. Additionally the application hangs until the transfer was completed.
I am using TwainDotNet: http://code.google.com/p/twaindotnet/ but I'm also looking for a generic solution describing the message filter and the interaction with TWAIN independant of TwainDotNet. A workflow containing the TWAIN messages would suffice. Other languages are also welcome, preferrable something like C or Deplhi.
The current implementation of the message filter in DataSourceManager can be described as following:
- Get message info from window handle (hwnd)
- Complicate filter, send stuff to TWAIN etc.
- if message close (e.g. when pressing the cancel button in the TWAIN UI)
- Close data source
- Disable filter
- Call ScanningComplete event
- if message transfer ready:
- In a loop (until the ADF is empty etc., this blocks the message filter)
- Get image
- Convert image pointer to GDI+ image
- Call TransferImage event with image as parameter
- Reset transfer
- Close data source etc. (same as message close)
- Notify windows, that the message has been handled
I've tested this with several scanners:
- A Fujitsu fi-5120C calls the TransferImage event every time a page has been transferred. The image pops up immediately in an image list in my WPF application.
- A Canon DR-5010C blocks my WPF application until all images have been scanned (until the loop ends). Windows even says, the WPF application is not responding. After all images have been transferred, only few images are displayed and the selection in the image list flickers etc..
I am not concerned about the display problems, but rather about the blocked window and the memory problems. Putting the loop that transfers the images into a BackgroundWorker caused several crashes, that I could not debug. Of cause I considered the threading issues of WPF. I also don't know how to split the transfer loop, so that, after transferring one image, the program returns to the message filter and the message can be marked as handled.