the main trick to getting twain to work with the commandline is the messagepump and handle that twain requires. console apps don’t pump messages the way that traditional gui apps do. The main workaround (that I’ve found) is the same one you would use if you wanted to work with twain from a service, as services lack a lot of the same things as console apps when it comes to working with twain. you create a class that inherits from nativeWindow to talk to twain for you.
from there, why is a simple app difficult… difficult isn’t quite the work I would use., maybe monotonous. With the 270ish seperate capabilities defines in the twain (without considering the custom capabilites that will end up being a whole seperate kind of pain later) and the conbination of dependancies for those caps you end up with miles of code. Or, you skip the idea of altering/setting caps one-by-one and instead you use the Ui that comes with the device for setup related stuff and then save the setup as a profile and later run all of the setting together. It’s a cleaner method, plus you no longer worry (as much) about dealing with devices that don’t quite follow the protocol. Instead you take the device’s Ui as thier contract (and don’t try to hold the vendors to a protocol that they more often than not don’t follow in the first place).
I hope that helps somewhat, but again if you want to see opentwain offer more from the console sample shoot me an IM or email.
.