Issue with DTWAIN_AcquireFile and DTWAIN_IsUIControllable

[rokoduran]

Hello there,

I am currently trying to perform a file acquisition:

int status = 0;
// Begin file acquisition
var uiFlag = TwainAPI.DTWAIN_IsUIControllable(_selectedSource); 

var success = TwainAPI.DTWAIN_AcquireFile(_selectedSource, "placeholder." + foundType.fType, foundType.DTWAINType, 
    TwainAPI.DTWAIN_USENATIVE | TwainAPI.DTWAIN_USELONGNAME, TwainAPI.DTWAIN_PT_DEFAULT, 
    TwainAPI.DTWAIN_ACQUIREALL, 0, 1, ref status);
if (status == 0)
{
    throw new Exception("File acquisition failed!");
}

This code acquires properly with a status of 1000 only and ONLY if I set ShowExceptions = 1 for DTWAIN logging and it shows an exception upon calling DTWAIN_IsUIControllable.

(No idea what this nullptr error refers to, the source and the DTWAIN states are all properly set up at this point)

If I don't call DTWAIN_IsUIControllable or turn ShowExceptions to 0, the acquisition status instantly goes to 1002 / acquisition cancelled.

The C# DTwain demo acquires successfully for the same driver. (also using the exact same AcquireFile parameters and setup)

[dynarithmic]

Can you produce a full TWAIN log? The DTWAIN_IsUIControllable is equivalent to calling DTWAIN_GetCapValues using the CAP_UICONTROLLABLE capability:

DTWAIN_ARRAY a;
TwainAPI.DTWAIN_GetCapValues(source, CAP_UICONTROLLABLE, DTWAIN_CAPGET, ref a);

This operation should never fail if the TWAIN source is compliant.

From here, it looks like this function failed for some reason, but shouldn't fail given that this capability has to be supported by the TWAIN driver.

[dynarithmic]

Right now, no check is done on the internal code to check if DTWAIN_GetCapValues fails for this call, so I will put the check in there. But again, this should never fail, unless there is an underlying problem with the driver.

[dynarithmic]

I made a change to check for the failure of DTWAIN_IsUIControllable in the development-32bit and development-64bit branches.

The change only checks for failure and probably prevents the exception being thrown, but it would be better to get a TWAIN log to see the failure actually get detected by the TWAIN DSM and driver. As mentioned in the previous comment, this failure should never occur if the TWAIN driver is compliant as of TWAIN 1.6 and above.

[rokoduran]

Hi again!
First of all, thank you so much for the quick responses.

I did some snooping around and found an older issue with near identical scenario as mine, barring the UIControllable: #46

I forgot to mention that the driver in mind was indeed a WIA driver, but I gave it no heed considering it worked in the demo.
By using

[SourceXferWaitInfo]
WIA-* = 1000

in the dtwain32.ini and using the dtwain32u.dll from the experimental branch you mentioned in that issue, my problem was solved and I can now use the WIA driver in my project.

BTW,
Regarding the IsUIControllable issue, I tried using the bins from the updated dev branch - the exception is now gone but I still can't use the driver (remember that the driver only worked if the exception was shown, presumably because it causes a stall, similiar to the waiting now done due to the .ini).

For all intents and purposes you can consider this solved, unless you still want to see the log/ more info?

Thank you again

[dynarithmic]

I will keep the issue open until the 5.3.0.4 version of DTWAIN is released.

It looks like the stock WIA-Twain bridge is broken, much more than it was in the past. So I guess the workaround for a WIA based driver when using it for TWAIN access is for the application to make a choice between using or not using the UI when accessing the scanner without help from DTWAIN_IsUIControllable().