yeah the trick with the second thread heree is that it isn’t interacting with my code at all. its just winapi calls. and the second thread is ‘pushing’ the appropriate button. the multithread issue you mentioned,as i understood, has to do with accessing bits of your code from a different thread than they were created on. and you’re right, there are some issues there. there are workarounds to those, but for the most part you’re correcct.
my second thread gets started before i execute the tw call, when it starts it runs thru all of the top level windows and puts a bit of info about them in an array. then i run the tw call that sometimes pops the messagebox (that tw call is on the main tw thread) if a messagebox comes up then the tw thread is just hung. not much to do about it. But that second dialog thread polls every x ms, and on poll it rechecks all of the toplevel windows, and if it finds anything new – then it compares what is new to the list of known dialogs that i want whacked. the comparison is made on the window title and the messagebox text. if the title and texyt are a match , then it posts the known message to the window. so my second thru never touches any of the data that my main tw thread created, just does some win interop. but like i said, i don’t like the polling. Its slow. maybe not slow in terms of waiting for a scanner to warm up, but its slow and i don’t like it. the next step, the cbt hook, should eliminate the polling and it’ll present itself cleaner – fact it might even look (at least to me) like the twain drivers are nicer than they really are.