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’
.