This project is read-only.

twain scanning approaches

Apr 25, 2007 at 11:31 AM
Edited Apr 25, 2007 at 11:41 AM
I typically see 3 approaches to twain programming.

One of them is to call EnableDS and displays the device's internal dialog then pick up the image(s) after the acquisition is complete. In that approach, the application that starts the process doesn’t really set any of the capabilities; it just pops the Ui and lets the Ui handle all of the work. To me this is the least amount of work.
There are several benefits to this approach:
*The capability setup is almost always right .. or at least it is as right as the people who make the driver could make it.
*Almost all of the device features are available
*The configuration is usually valid for the device.

But there are some downsides to this approach,
*It provides little to no automation
*If the users have a lot of scanning to do with different scanning requirements, it is tedious to switch the settings
*The user error potential is high.

Another approach is to let the calling program set the capabilities that it needs.
This approach has a number of advantages,

*The automation potential is high.
*User error potential is low.

But there are (in my opinion) are a couple of serious flaws with this approach:

*Devices are rather unique - the capabilities supported across vendors are not consistent.
*Custom capabilities are almost completely unavailable
*If scanning if done outside of the application and if changes are made to capabilities that aren't set, then the application won't provide consistent scanning.

A third approach is somewhat of a combination of the above. It involves calling the EnabledsUiOnly. With EnableDsUiOnly, the device’s internal dialog comes up. The user sets up all options for a scan just like in the first approach, but when the device is configures instead of selection a button that is usually named "Acquire" or "Scan" they select a button that usually is labelled "OK". No scanning takes place. Instead the device will be in a state that you can query the settings (CustomDsData.Get) and save them for use later on. Then when the users would like to scan with those settings the application sends CustomDsData.Set with the information that was previously saved. It is more of a profile based approach.
The benefits to this approach are:
*The automation potential is high
*User error potential is low
*Custom capabilities are available
*Capability support problems between vendors is extremely low.

The main drawback to this approach (in my view) is that EnableDsUiOnly, and CustomDsData(Get and Set) aren't supported on all devices.

openTwain was deisgned for the third approach. The project's goal is to provide consistant scanning across a wide variety of devices without user intervention from winforms, console and windows service projects.