scanning from epson

[ZiggyShort]

I’m testing on a few scanners and while scanning from a canon canonscan lide 20 works fine, an epson stylus dx6000 gives me a few problems.

The problem occurs between the Control/UserInterface/EnableDS and Image/ImageInfo/Get.

Basically the scanner’s proprietary user interface is displayed after the Control/UserInterface/EnableDS triplet, and once the user presses the scan button I reach the Image/ImageInfo/Get breakpoint in my (! mine? I nicked it!) code.

The problem is: while clicking scan on the Canon causes the UI to return control to my program, and my breakpoint to be reached, the Epson scan button “seems” not to respond. The only way to get rid of the dialog is stop debugging the application. Is this a known issue or am I doing something wrong?

Here is my call to EnableDS:

TwUserInterface guif = new TwUserInterface();
guif.ShowUI = 1;
guif.ModalUI = 1;
guif.ParentHand = hwnd;
rc = DSuserif( appid, srcds, TwDG.Control, TwDAT.UserInterface, TwMSG.EnableDS, guif );

(So the dialog IS Modal)

[gabe]

dialogboxes are difficult. I have a thread built to watch for them and close them as they often (read:always) block twain communication when they are shown. Usually you’ll have to watch for them after EnableDs, OpenDs and EnableDsUiOnly calls.

And ModalUi doesn’t play a role in twain on windows – unless I misremember the spec. I am almost certain that the spec says that parameter only applys to Mac development.

.

[ZiggyShort]

Do you have an example of your thread code? And how do you get the dialog to subsequently close, and the scan press to get acted upon?

[gabe]

yup. opentwain’s monitor project.

the basic idea is that you test the ‘profile’ and try to make the device pop any and all dialogs that may show up in production (I know it’s not perfect but how else do you get values for unknown/undocumented dialogs that kill you app?… )
while testing, the monitor’s thread watches for dialogs that are created during critical portion of your code. If a dialog is detected, the monitor records some information about the dialog (text, buttons control Ids, etc) via some windows polling (which i wouldn’t have to do if some vendors cough*hp*cough would create thier dialogs on the smame thread) and a cbthook. after each test, open the Tools, Dialog Manager menu of the guiHarness and you’ll see the details. from there you double click on each item and you have some options for posting messages to the dialogs with the controlIds of the various CButtons that the monitor found in each dialog.
You end up with a rule set so that later the ‘profile’ knows that if a dialog with title ‘Epson kill twain’ shows up that the monitor thread needs to post the control Id of the button named ‘no, don’t kill twain just yet’

.

[gabe]

and I understand that this would be easier on you if I ever got around to producing a ‘how to’ or a ‘getting started’ (or any documentation really) for opentwain, but,.. well maybe someone else will write it for me – because somehow other projects keep coming up.
😉

[Author]

Posts