ah. Enter my favorite rant: Don’t set the caps one-by-one. Let the users use the vendor’s Ui to set up the scanner. My users don’t want to see the vendor Ui either, at least not while they are scanning, but they don’t seem to mind seeing it to setup the device (or they talk about me when I leave, I gotta admit there is a strong possibility that is the case). Use EnableDsUiOnly to display the Ui, after the user closes the vendor ui (with and ok or save or whatever) you use CustomDsData.Get to gather all of the settings. Then when the users wants that ‘profile’ of a scan you enableDs and use CustomDsData.Set to config the scanner. In this fashion you skip all the cap getting/setting, the user get a consistant scan from your app and you don’t have figure out all of the custom caps. In most cases if there is some oddness in the vendor’s implementation of the spec their Ui has the best chance of getting it right.
You are still able to scan without a Ui coming up… well it doesn’t detract from that ability in that if the vendor supports it, it is still available.
And the disadvanages to setting caps one-by-one are many. Look thru the
questions and problems people have with twain in the on this site. The vast majority are the type you describe where the spec isn’t quite followed by the vendor and as a result getting the device to acquire is a pain. In the rare case where you get one device just right, what happens when your users get a new device? You go back to the table and figure out all of the particulars again? No. Least not me. I tell the users to get a scanner that supports EnableDsUiOnly and CustomDsData. I occationally get a user with a scanner that doesn’t support the caps I use. What follows is a short talk about the state of the world and the cost of custom development, it takes about 3 minutes and the user goes scanner shopping. If you like reading .net code and are looking for a sample I have my source posted over codeplex/openTwain.
.