Forum Replies Created
- AuthorPosts
I’m assuming this is on some version of Windows…
Your scanning application should be waiting for a DG_CONTROL / DAT_NULL / MSG_XFERREADY message. This is sent from the TWAIN driver to the Data Source Manager (DSM), which forwards it on to the application.
The application retrieves the event either through calls to DG_CONTROL / DAT_EVENT / MSG_PROCESSEVENT (old style – TWAIN_32.DLL or TWAINDSM.DLL), or through a callback function registered using DG_CONTROL / DAT_CALLBACK / MSG_REGISTER_CALLBACK (TWAINDSM.DLL only).
TWAIN_32.DLL is an old DSM that comes with every version of Windows since Windows 98. TWAINDSM.DLL is an open source project maintained by the TWAIN Working Group. Any TWAIN driver or application can used the supplied .msi file referenced through twain.org to install this version of the DSM.
If your application is using TWAIN_32.DLL with the MSG_PROCESSEVENT method, then the following conditions need to be followed for successful receipt of MSG_XFERREADY…
– the window handle supplied to MSG_OPENDSM and MSG_ENABLEDS much match the window event loop monitoring for MSG_XFERREADY…
– all TWAIN commands should original from the same thread that issued MSG_OPENDSM, and this should be the same thread that creates the window handle described in the previous statement…
The callback mechanism is less restrictive in that a window handle isn’t needed for receipt of MSG_XFERREADY, though it’s still true that all TWAIN commands should originate in the same thread…
Hope that helps…
Howdy…
I tried this with one of my Kodak TWAIN drivers (i940), running the 32-bit Twacker 1.8.0.0 on Windows 8 (64-bit). I ran numerous native transfer scans with black-and-white, grayscale and color, and encountered no problems using either TWAINDSM.DLL or TWAIN_32.DLL. I also confirmed with another vendor that they’re not seeing any issues with this configuration…
Based on that admittedly limited feedback it seems reasonable to conclude that the scanner driver is having a problem.
If you can provide more details on all of the settings used for the scanning session (assuming that makes a difference), I’d be happy to retry a test that’s more exact compared to what you’re doing. Otherwise I’d take a closer look at the contents of the data being passed to CreateDIBitmap…
Howdy…
First off, here are the rules…
If the application reports itself as TWAIN version 2.0 or higher *and* it includes the DF_APP2 flag in its TW_IDENTITY.SupportedGroups field, then the application fully supports TWAIN 2.0.
If the TW_IDENTITY.SupportedGroups field from the application includes the DF_DSM2 flag, then the Data Source Manager (DSM) fully supports TWAIN 2.0.
If the TWAIN driver reports itself as TWAIN version 2.0 or higher *and* it includes the DF_DS2 flag in its TW_IDENTITY.SupportedGroups field, then the driver fully supports TWAIN 2.0.
Any combination of the three situations described above is allowed, but the following two are the only ones you need to worry about. Refer to the TWAIN Specification to see what DAT_ENTRYPOINT is doing.
If the DSM and the application both support TWAIN 2.0, then the application must call DG_CONTROL / DAT_ENTRYPOINT / MSG_GET down into the DSM before calling DG_CONTROL / DAT_IDENTITY / MSG_OPENDS.
If the DSM and the driver both support TWAIN 2.0, then the DSM will automatically call DG_CONTROL / DAT_ENTRYPOINT / MSG_SET down into the driver before it passes along a call to DG_CONTROL / DAT_IDENTITY / MSG_OPENDS from the application.
You have a couple of options, but I’m going to recommend one that has a high chance of success, if you still have access to your old machine…
This site provides access to a free system that allows you to convert your old physical PC to a virtual machine. You’ll probably need access to a large external USB drive to make this work, since the finished result will be the same size as the amount of disk space used on the old system:
http://www.vmware.com/products/converter/overview.htmlThe same company provides a free player to run that virtual machine:
http://www.vmware.com/products/player/So, you take your old XP system, turn it into a virtual machine (basically a set of large files) and then you run your old PC as an application on your new PC. This will allow you to run all of your old applications and drivers. You’ll be able to plug your scanner in and use it on the same XP system. It’s easy to get the VM to share the host disk, so passing files back and forth won’t be a problem.
Unfortunately, any other option requires knowing a lot about how Canon’s TWAIN driver works, which is vendor specific knowledge. You also need to understand the difference between 32-bit vs 64-bit Windows. If you really have to investigate that path then you’ll need to learn about file and registry redirection, the difference between “System32” and “SysWOW64”, “Program Files” vs “Program Files (x86)”, and the use of OS compability mode.
At that point I’d recommend getting a scanner that’s rated for your OS…
Hmm…something didn’t work about setting the debug flag. The log has this…
00000 184015375 twn_dat_identity 737 0 S3 (2012/11/13 18:40:15.375) Debug=0 DebugFilter=<>
That should have shown Debug=1 in the log file, if setting const.ini worked…
Unfortunately, I don’t have an i30 scanner handy to check, however I did install the i30 on Win8 and confirmed in simulation mode that things are working, so that’s a start.
If you edit this file:
C:ProgramDatakds_kodakkds_i30_i40const.iniYou’ll find a line like this:
Debug=0
Change it to be:
Debug=1Then run your application. Afterwards you’ll find this file:
C:ProgramDatakds_kodakkds_i30_i40kds.logIt should be small enough that you can copy-and-paste its contents as a reply…
The installer places the DSM in the proper location, but all it’s doing is copying the appropriate twaindsm.dll to the appropriate directory. There’s no registry update or anything of that sort.
How have you determined that it’s not working? Are you in control of the application that’s accessing the DSM? Are you sure that it’s not accessing the older twain_32.dll?
Okay…so when you have TWACKER up, you want to use “File / Select Source…” to pick your scanner.
Then click on “Special / 1 Load/Open SM”, then “Special / 2 Open Source”
Then click on “Special / 3 Send…”, and you’ll get the negotiation dialog…
It should already be set for DG_CONTROL / DAT_CAPABILITY / MSG_GET, so click on the “Capability:” dropdown and see if ICAP_CAPABILITY shows up in the list. If it does, then you can investigate it and make sure it’s set to TWCP_NONE. If it doesn’t, then keep going…
Are you using DAT_IMAGEFILEXFER to get the image? If so, then you need to look into the setting on ICAP_IMAGEFILEFORMAT and make sure that DAT_SETUPFILEXFER isn’t asking for TWFF_JFIF (the offical name of a JPEG header). Try setting it to TWFF_BMP.
If that doesn’t help, then make sure the scanner has a piece of paper ready, click on “File / Message Level / Full”, then click on “Special / 5 Enable/Transfer”
You’ll get a dialog for the DAT_IMAGEINFO command. Check the value of compression. If it’s anything other than 0, then the image was compressed by the driver. (6 is the value for JPEG)
Hopefully, that’ll give you some more information to figure out what’s happening…
October 24, 2012 at 3:55 pm in reply to: Problem with TwainDotNetProject and CanoScan Lide 110 #25716From a defensive programming standpoint, the safest way to access the scanner is from a process that separate from your main application. That way if the scanner process hangs or crashes, it doesn’t take out the application. That doesn’t solve the problem, though, it just makes it easier to recover.
TwainResult.NotDSEvent is part of the TWAIN protocol. When an application asks a data source to begin scanning or bring up its GUI, then it’s supposed to redirect all Windows messages to the driver, so that the driver’s GUI has first crack at any messages. Just moving the mouse around your application should be enough to generate that response from the driver.
Essentially, TwainResult.NotDSEvent is the TWAIN driver saying “that Windows message doesn’t belong to me, so you can have it back.”
Make sure that you only use one thread to access the TWAIN driver (the same thread that opened the driver). Also, try moving the mouse over the splash screen to see if that makes a difference. I don’t recommend accessing a TWAIN driver from your main application thread, create a thread that’s dedicated to communicating with the scanner.
Finally, contact Canon and/or the Twain Dot Net forum for more help…
The TWAIN Data Source Manager looks for .ds files inside of the TWAIN_32 directory. If those data sources respond to a DG_CONTROL / DAT_IDENTITY / MSG_GET, then they are listed. That does not mean that the physical scanner is connected or ready for use. The application doesn’t find that out until the DG_CONTROL / DAT_IDENTITY / MSG_OPENDS command is issued.
So that explains why you’re seeing the “device”…you’re really seeing the driver, not the device…
When you run “Remote Desktop Connection” click the Options arrow (bottom left corner) to see the advanced settings. Go to the Local Resources tab and press the “More..” button at the bottom of the dialog.
Confirm that “Ports” is checked, and that “Other supported Plug and Play (PnP) devices” is checked, then check “Devices that I plug in later”.
There’s no guarantee that USB redirection works for the scanner you’re using, but if it does, that’ll set it up. If that doesn’t work, then you’ll need to hunt around for a redirector option for Terminal Server, or investigate other options like Silex (using the net to access a USB device), or something like Citrix, which has a TWAIN redircetor…
My first thought is that I don’t know of anything like what you’re describing. However, I think a bit of clarity might help. Can you describe in a little more detail what you’re looking for. A simple example would be useful…
It’s possible that you’ve run into a “protected mode” issue. IE9 on Win7 is sandboxed, and that can cause problems with TWAIN drivers that weren’t designed to run in that situation.
The quickest way to determine if that’s the problem is to browse to the following directory…
C:Program Files (x86)Internet ExplorerRight click on “iexplore.exe”, and select “Run as administrator”. If scanning works, then you have a protected mode issue. If that’s the case, then I recommend contacting both the scanner vendor and Dynamic Web for more advice…
ICAP_COMPRESSION is the capability that controls the use of JPEG. Setting it to TWCP_NONE (no compression) should take care of that problem.
There’s a remote possiblity that the new driver is automatically detecting color content and is returning JPEG as a “convenience”.
I recommend downloading the TWACKER, which is a standalone application that can be used to tinker with TWAIN drivers. You can find it at the bottom of this page…
http://twain.org/scannerdriverdevelopers/specification-and-tools.htmlSee if the driver is automatically JPEG when you bring it up. Check the ICAP_COMPRESSION setting. You may also want to bring up the driver’s GUI to see if it has any settings that relate to your problem. Some drivers remember their GUI settings, so turning it off in the driver GUI and then running from your preferred application might give the result you want.
You should also consider contacting Canon for more help…
The looks like it may be a “sequence error”, an error return of TWRC_FAILURE / TWCC_SEQERROR.
This typically happens when the application and the data source get out of sync with each other on what the current TWAIN state is. In this case the driver is complaining that it received a command that is only valid in state 5.
Well, as it happens, the only command that’s typically issued in state 5 is DG_CONTROL / DAT_USERINTERFACE / MSG_DISABLEDS, which is the command to return to state 4 (negotiation mode).
Regardless, the standard way to handle that sort of thing is to write a generic “resync” function. Something like the following…
ResyncState(target) { // get us back to state 4…
if (target < 7) DG_CONTROL / DAT_PENDINGXFERS / MSG_ENDXFER
if (target < 6) DG_CONTROL / DAT_PENDINGXFERS / MSG_RESET
if (target < 5) DG_CONTROL / DAT_USERINTERFACE / MSG_DISABLEDS
}At this point you should be able to negotiate some value, like ICAP_XFERMECH to confirm that you’re in state 4.
It’s also possible that the driver is in a bad situation, and it can’t work it’s way down to state 4. In that case you might try closing and reopening it with DG_CONTROL / DAT_IDENTITY / MSG_CLOSEDS and DG_CONTROL / DAT_IDENTITY / MSG_OPENDS. Even though MSG_CLOSEDS wasn’t designed to be run from any state, a lot of drivers support it.
I recommend the following. First, download the Twacker_32.msi from the TWAIN website…
http://twain.org/scannerdriverdevelopers/specification-and-tools.htmlSee if you can communicate and/or scan with the driver using the TWACKER application. If it works, then it may suggest an issue in the application’s TWAIN interface.
If TWACKER does not work, that suggests a possible problem in the scanner driver. You should contact the scanner vendor for more help.
- AuthorPosts