Re: TWAIN Acquire in Background Worker Thread, and AcquirePage Event Not Working?

Hi,

I am trying to create a .NET assembly that uses the LeadTool Twain classes to handle the scanning. Then I have my caller app (WinForm app) to call the assembly and display the image coming back. My assembly basically calls the Twainsession.Acquire(), and then, in the AcquirePage event, I in turn wrap the image object in my own argument with additional data, and fire my own event, and the caller app then handles that event to receive the image as well as other data.

If my caller app is written in single-thread mode, everything works fine. However, I noticed my UI form is non-responsive when the scanning is in progress (I am using the feeder to scan multiple pages). When the Twain Driver dialog first comes up, it is modeless, so I can click back to my app main form. But once the scanning process starts, and the progress dialog comes up, I cannot go back to my app main form.

That's what started me to think to convert my app to multi-threaded, so I can respond in my UI (like scrolling the image in the viewer). However, once I placed the call to Acquire in a background worker thread, the Twain Driver dialog still comes up. But when I click on the Scan button, the AcquirePage event is never being fired (set my breakpoint in there, and it never hit it). I can still click on the About button or Pre-scan button that will do things inside the Twain Driver dialog. I just can't Scan, and have the AcquirePage event being fired.

Is there something special I need to do to make Scanning work in a multi-threaded app?

Basically, I want to have my app UI to be responsive during scanning. I can refresh my form to receive the updated image and stuff in my app event handler, but my app is still not responsive.

I am using C#, .NET 3.5, VS 2008, and LeadTools Eval 16.5.

Thanks,

Ann

Ann,
About calling LEADTOOLS functions from your own assembly, please note 2 things:
1. Any programmer using this assembly, whether in your firm or outside it, must have a separate LEADTOOLS toolkit license because our toolkit are sold as one license per programmer per end-user application.
2. Even if only one programmer will be using this assembly, adding a layer on top of LEADTOOLS functions is likely to add complexity and make it harder to isolate and solve any problem you face. In general, when we have to look at customer code in a support call, we require that it has as little non-LEAD code as possible.

About the multi-threading issue, did you pass the InitializeMultithreaded flag to the TwainSession.Startup method?
In all cases, you can use Twain functions only from the same thread where you initialize them.

Hi,

Our company has been using LeadTool for years. We are currently on v15, and we are evaluating v16.5. We do have plans to upgrade, but we are evaluating and testing the new fuctionalities.

As to the multi-threading issue, I have tried passing both InitializeMultithreaded flag and None flag. I can see the InitializeMultithreaded flag is launching the scan job in a separate thread, so the Twain Driver dialog has response. I was just hoping that my app can have response back as well.

That is fine if I cannot place Twain functionality in a separate thread. The InitializeMultithreaded flag should be good enough for now. Like I said, I am evaluating the functionalities, and I was trying to see if this is even possible.

Thank you for your reply.

Ann

Ann,
Does this mean that using the InitializeMultithreaded flag solved the issue of the AcquirePage event not firing? If you are still facing problems with this issue, please provide me with more details.

No, the InitializeMultithreaded flag did not solve the issue of the AcquirePage event not firing. It just makes the Twain Driver dialog responsive, since LeadTools is launching the scanning process in a separate thread. However, this does not make my GUI responsive, since I cannot launch LeadTools in a separate thread that I spin off, and to get the event notification back on that thread.

It would be nice if I can get the event notification, but for now, I think I can work around the limitation.

Thanks,

Ann

If you would like us to investigate the event issue further, please create a small sample project (not your full application) and send it to me in a ZIP or RAR file? You can either attach the sample file here or send it to support@leadtools.com and mention this post.

If you want to attach a file in the forums, do not use the 'Preview' option.

One thing you might try is to disable the status indicator the scanner pops up as it's scanning.  The indicator maybe stealing the focus away from your application each time it restarts the status bar when the next page is scanned.

Disable the indicator using our method TwainSession::ShowProgressIndicator(false);

However, as each scanner driver's implementation is different you might want to put the scanning in a separate thread.  When doing this be sure to note that twain works with Window's Messaging.  This means that the window you pass into the TwainSession::Startup function must be a window created inside the child thread or the messaging will not work.  Most likely this is why you are not getting the AcquirePage event to fire.

I have attached a sample application that shows you how to spawn a separate thread and create a window in the thread to pass to our Twain object.  All objects must be created in the child thread to prevent cross threading and Window's Messages from getting lost. 

In the AcquirePage event if you are planning on updating your UI, you should use a delegate function to pass the image data to your UI control on the Main form. 

Hope this helps.

Here's a link to another Twain multithreading demo: http://support.leadtools.com/CS/forums/32491/ShowPost.aspx