AcquireMulti fails (v14, COM)

Hello.

I am trying to create a program which consumes automatic-feeding capabilities of a TWAIN device. I use version 14.0 of the LeadTools COM library.

When I have read the TWAIN docs, I saw that I must know whether TWAIN device can do automatic-feeding, by doing the following:

1. Set CAP_FEEDERENABLED (without error/exception, of course, my code catches every one such) to TRUE.

2. Get CAP_FEEDERENABLED and assure it is TRUE.

3. Set CAP_AUTOFEED to TRUE.

4. Get CAP_AUTOFEED and assure it is TRUE.

A little note: I have taken care of error handling and I am 100% sure that I do not violate nothing in neither COM paradigma (such as wrong thread access to COM object) nor the MFC one (wrong resource instance handles, etc.). Furthermore, I know how to debug code and I must emphasize, that there can be no mistake here. The things are exactly as described below.

I have a scanner, which does not seem to be automatic-feeding device (it is a flatbed one, and as far as I can see, the only way to put paper in it is to lift the lid), but it passes all four steps. After that, I set the "FastConfig*" properties so that I am sure that I have requested TIFF file and file-transfer-mode. After that, I do 'AcquireMulti("multipage.tiff", 3, TRUE)' and I catch LeadTools error ERROR_DOCUMENT_NOT_ENABLED (code 20143), which translates to something like "Document express capability is required to use this function".

This does not seem like anything I can notice in the TWAIN capabilities! Can it be more informative?

Furthermore, I have tried TWACKER, the TWAIN's test program. There, the scanner allows setting "Automatic feeding" (by checking check-box with that name) and it does not complain when I do acquire, but it acquires only one page (after acquiring it, it shows that pending transfers are zero) and then finishes.

So, why would one scanner allow such settings, which are described by the TWAIN group themselves as "Informative about automatic-feeding capability of a device" and to not actually support it?

And, the most important question actually -- what is the meaning of error code 20143 in the code situation I described above?

At the end, I just want to be supplied with some working mechanism/algorithm. When I try my program with the fake scanner supplied with the TWAIN-kit, LeadTools COM library throws exception with code 20566 ("the capability is not supported"), my program catches that exception, marks that the device is not capable of automatic-feeding, and then does batch-scanning by asking the user to manually put the next page until the job is done. That's OK. But the situation I described looks like that either the scanner vendor were not so much concerned about its TWAIN compatibility, or I do not realize something very obvious in working with LeadTools TWAIN API. I will be grateful to be pointed to my mistake or omission.

Thanks for the attention.

The AcquireMulti function only works if you have a LEADTOOLS Document
Imaging toolkit, since it's part of the Fast TWAIN module. This is what
ERROR_DOCUMENT_NOT_ENABLED means.

If you don't have LEADTOOLS Document Imaging, you can still scan multiple pages using the Acquire function.

If you do own a Document toolkit, you need to unlock Document support before using Fast TWAIN functions.

About TWAIN drivers in general, their is always a possibility that the behavior with various capabilities is not always consistent with the standard. There is also another possibility that the scanner might have an optional Feeder module that can be installed separately, or that the same driver is used for different models. Try to check with the scanner's vendor support department.

Edited by user Monday, December 5, 2016 4:25:31 PM(UTC)  | Reason: Not specified

Thank you for the good answer.

I have discovered the unlock-stuff and now I can use document-capabilities of LeadTools. That was kind of stupid question, and I am sorry.

Further: What you say about same driver for a family of devices sounds very stupid, but I'm sure that it is a common practice of much vendors. Well, I have this question now: Is there other way to know for sure whether the TWAIN device is capable of automatic-feeding? I use the following C++ condition to know whether I can do ADF:

bool haveADF = (canDetectPaper() && haveLoadedPaper() && (canDoAutoFeed() || canFeedPage());

where:

=> canDetectPaper() returns "is CAP_PAPERDETECTABLE existing and if it is,
is its value TRUE?"

=> haveLoadedPaper() returns "is CAP_FEEDERLOADED existing and if it is,
is its value TRUE?"

=> canDoAutoFeed() returns "is CAP_AUTOFEED existing and if it is, is it
setable to TRUE?"

=> canFeedPage() returns "are CAP_EXTENDEDCAPS and CAP_FEEDPAGE existing,
if they are and if CAP_FEEDPAGE is not in CAP_EXTENDEDCAPS, is
CAP_FEEDPAGE add-able to CAP_EXTENDEDCAPS?"

For now, this seems to work on my very strange scanner, but I strongly doubt that this is an universal solution.

Sorry for the TWAIN-specific question here. I posted almost same question in TWAIN working group mailing list and so far I did not got the answer (a week passed since then). If you have any experience regarding this issue, please share it with me, I will be very grateful.

 

More: I am using Java-to-COM (and vice versa) library to work with LeadTools library (mostly TWAIN for now) in order to directly use Java proxy-classes to work with LeadTools library. Since the Java-to-COM/COM-to-Java library I use denies me to create "ICapability" (possible bug there, I have contacted its developer), I found myself forced to work with "ILEADTwainCapability" (plus "ICapability2", "ICapabilityOneValue2" etc.). Retrieving capability values works just fine (at least, works for one-value capabilities, I did not tried other container-types yet, but I expect no problems). But, when I want to set a capability, I receve either "Invalid parameter passed" or "TWAIN bad value". In the example I paste here, I try to change ICAP_PIXELTYPE, and I am SURE, that the capability and the value I assign it (2 == TWPT_RGB) are supported by my selected TWAIN source.

 

==> Here is the VB sample that LeadTools supplies:

 

   Dim CapVal As Integer
   Set TwainCap = New LEADRasterTwainCapability

   TwainCap.CapInfo.ConType = L_TWON_ONEVALUE
   TwainCap.CapInfo.Capability = L_ICAP_UNITS
   TwainCap.EnableMethodErrors = False
  
   CapVal = L_TWUN_INCHES
  
   TwainCap.CapOneValue.OneValItemType = L_TWTY_UINT16
   TwainCap.CapOneValue.OneValCapValue = CapVal

   iRet = RasterTwain.SetCapability2(TwainCap, L_LTWAIN_CAPABILITY_SET)

 

==> Here is my JAVA code snippet:

 

  ILEADTwainCapability _iltc = new ILEADTwainCapability (LEADTwainCapability.clsID);

  _iltc.setEnableMethodErrors(true);

  DispatchPtr _icap2 = (DispatchPtr) _iltc.get ("CapInfo");
  _icap2.put ("ConType", 5);
  _icap2.put ("Capability", 257);

  DispatchPtr _icap21 = (DispatchPtr) _iltc.get ("CapOneValue");
  _icap21.put ("OneValItemType", 4);
  DispatchPtr _ltvr = (DispatchPtr) _icap21.get ("OneValCapValue");
  _ltvr.put ("Type", 4);
  _ltvr.put ("LongValue", 2);
  _icap21.put ("OneValCapValue", _ltvr);

  LeadUtil.ltCheck (ltrt.SetCapability2 (_iltc, 1)); // obviously, "ltrt" is of type "ILEADRasterTwain"

 

When "EnableMethodErrors" is "true", I receive error on the last-but-one-line -- "Ivalid parameter passed". When "EnableMethodErrors" is "false", I receive error on the last line: "TWAIN Bad Value Passed".

But that's not the worse. I was initally thinking that there must be some bug in the Java-to-COM/COM-to-Java library, but that's not the case. In C++ the things are 100% same. Here is my C++ code:

 

ILEADRasterTwain *ltrt; // instantiated & called InitSession() already.

ILEADTwainCapability *iltc = ... // intantiate new.
iltc->EnableMethodErrors = VARIANT_FALSE;
iltc->CapInfo->ConType = L_TWON_ONEVALUE;
iltc->CapInfo->Capability = L_ICAP_PIXELTYPE;

ILEADRasterVariant *var = ... // instantiate new.
var->Type = VALUE_BOOLEAN;
var->BooleanValue = TRUE;

iltc->CapOneValue->OneValItemType = L_TWTY_BOOL;
iltc->CapOneValue->OneValCapValue = var;         // NOTE THIS LINE ALSO!

ltrt->EnableMethodErrors = VARIANT_FALSE;
short rc = ltrt->SetCapability2(iltc, L_LTWAIN_CAPABILITY_SET);

 

Here, "rc" becomes 20568. I tried many combinations, including extraction of "ICapability2" and "ICapabilityOneValue2" and storing them in variables, with no effect. Always the same error. More curious, on the line where I put a note (where we assign the variant to the capability-value) actually an error occurs. When I set "ILEADTwainCapabality" "EnableMethodErrors" to "true", on this line is thrown exception, whose user-error-code is 20013 (ERROR_INV_PARAMETER). I do not understand why.

I would be grateful if you give me EXACT directions on how to deal when SETTING capabilities and what's the problem of using VB-style (I do not know why it is VB-style) in C/C++ (even Java, through using proxy classes).

 

Regards,

Dimitar

If you need more help verifying your feeder test against more scanners,
create a small test project and send it to us and we can run it against
some of our scanners here.

About setting CAP_PIXELTYPE, I tested the following VB code and it's
working. If you don't have VB and you would like to test it, send me a
message to support@leadtools.com and I will send you a compiled EXE
containing this code.

Sub TestCAP_PIXELTYPE()
Dim var As New LEADRasterVariant
Dim TwainCap As New LEADTwainCapability
Dim RasTwain As New LEADRasterTwain
RasTwain.InitSession Me.hWnd

RasTwain.SelectSource
TwainCap.CapInfo.ConType = 5 ' L_TWON_ONEVALUE
TwainCap.CapInfo.Capability = 257 'L_ICAP_PIXELTYPE
TwainCap.EnableMethodErrors = False

var.Type = VALUE_USHORT
var.LongValue = 2 'L_TWPT_RGB
TwainCap.CapOneValue.OneValItemType = 4 'L_TWTY_UINT16
TwainCap.CapOneValue.OneValCapValue = var
RasTwain.SetCapability2 TwainCap, 1 ' L_LTWAIN_CAPABILITY_SET
Set TwainCap = Nothing
Set var = Nothing
RasTwain.Acquire 1 'L_LTWAIN_SHOW_USER_INTERFACE
RasTwain.EndSession
End Sub

Edited by user Monday, December 5, 2016 4:29:19 PM(UTC)  | Reason: Not specified

Hello Amin,
Thank you for your answer, and thank you for your helpfulness.


I did not knew that I am required to have Visual Basic so that I can
use "ILEADTwainCapability". I think that it is "IDispatch"-derived
interface which simply requires COM, right? Partially, Visual Basic is
just a wrapper for easier access to some COM interfaces. Maybe I am not
precise in this, but I do not believe that Visual Basic by itself is necessary to work with "ILEADTwainCapability". Am I right?


As for TWAIN test codes, I will do one small package of C++ code
(bundled as Visual C++ project). I will gladly send it to you. If I am doing some stupid mistake, at least I can receive feedback for it.

Regards,

Dimitar Panayotov.

Dimitar,

Our COM objects should work with any platform that supports standard COM interfaces. They are not for Visual Basic only. From another post I found out you had an old build of our COM objects. I hope applying the latest patches solved your problems. If it didn't, please feel free to contact our support email or post to this forum.

Edited by user Monday, December 5, 2016 4:27:26 PM(UTC)  | Reason: Not specified