Introduction to DTWAIN Acquisition Processing

When the Source is ready to acquire images, the Source UI is usually displayed to the user.  The UI may have a myriad of controls, scanning areas, preview scans, contrast settings, etc.  Once the user is satisfied with the selections, The UI would have a 'Start Scan' button, or some other control that the user would select to start the acquisitions.

Once all of the pages (or whatever each image would be called) are acquired, the user does one of the following

a) Close the UI.

b) Start another acquisition by selecting 'Start Scan' again.

c) Leave the UI open, and go back to the UI later.

The way TWAIN handles these situations is to send messages to the application as to whether to close the UI, whether to start another acquisition, etc.  The application is then responsible to respond to these messages appropriately and correctly.

The problem with implementing a library such as DTWAIN is how to encapsulate the message retrieval mechanism within the library.  DTWAIN has to intercept your application messages so that any TWAIN related messages are processed correctly.

DTWAIN uses two methods to overcome the message retrieval issue.

The first method is called the Modal Acquisition Processing.  This acquisition-processing model assumes that when the Source UI is initially displayed, the application is 'suspended' (in reality, the application is not suspended or disabled) until the user closes the Source UI.  The Source UI is initially displayed when a DTWAIN Acquisition Function is called, and the called DTWAIN Acquisition function returns only when the Source UI is finally closed (or disabled).  This type of processing is the easiest to implement in any application and for any programming language, and it is recommended if you want to implement TWAIN in the fastest time possible.  The following topic discusses this type of processing in depth:

DTWAIN Modal Acquisition Processing

The second method is called Modeless Acquisition Processing.  This acquisition-processing model assumes that when the Source UI is initially displayed, the application is not suspended.  When a DTWAIN Acquisition functions is called, the Source UI would be displayed, however unlike Modal Acquisition Processing, the DTWAIN Acquisition functions return immediately. Your application is responsible for calling a DTWAIN_IsTwainMsg function to determine if the message that is sent to your application is a TWAIN message.

Your application must also be ready to process DTWAIN messages that inform you of the progress of the acquisitions.  The Modeless Acquisition Processing model is recommended if you program in C, C++, or any other programming language that allows you to adjust the application message loop.  The following topic discusses this type of processing in depth:

DTWAIN Modeless Acquisition Processing

The tell-tale sign that a TWAIN Source relies on modeless processing is that if modal processing is used, the Source user interface may display, but the user interface does not respond to any user interaction, or the acquisitions show erratic behavior.  Please be aware of this fact when programming using DTWAIN.  If you use Modal processing, and the TWAIN Source does not respond, freezes, or acts erratically, switch to modeless acquisition processing.

Acquiring Without a User Interface

If you plan to acquire images without a user interface, the Modal and Modeless Acquisition Processing work the same way.  For the Modal Processing, the DTWAIN Acquisition function would return when the programmer finally closes the Source.