ok, double checked. Seems that even with drivers that I normally consider
Back to the part of your question where you asked if I have a solution. Yes.. no.. a bit. I have a workaround. It isn’t a twain workaround, just a general windows programming workaround. I use a cbthook and a bit of polling to determine whether any new dialogs have been launched in 3 different places in my code. Whenever I am about to call OpenDs, EnableDs or EnableDsUiOnly – I record all of the open dialogs and set the cbtHook. I keep polling until the call is finished at which point I stop polling and remove the cbtHook. If any new dialogs are detected my code checks the details of the dialog and if they match the details for any dialog in my “known dialog” list, my code sends the “known response” to the dialog. The users have instructions to ‘train’ my app where they do various things that cause dialogs to come up – unplug the device and try to scan, cause ampaper jam and try to scan etc… After the training is complete they create rules of the unwanted dialogs and when a dialog would have come up and interupted their scanning at most they get a brief flash on screen and hear the error. Usually the cbthook closes the dialog before it even comes onscreen.
I wrapped all the dialog managment into my twain library, as I feel strongly that (unfortunately) dialog management is a part of twain’s problem domain. The .net code is open source and available over at http://www.codeplex.com/opentwain
.