Home › Forums › TWAIN Classic › .NET Application.Run and ShowDialog problem
- This topic has 6 replies, 3 voices, and was last updated 17 years, 10 months ago by gabe.
- AuthorPosts
I have a C#.Net interface to the twain_32.dll. The scenario that works is:
frm1 is the twain source selection form
frm2 is a save/image adjustment formform frm1 = new form();
Application.Run(frm1);The user selects the twain device from frm1, the twain/driver interface
is activated, the user selects acquire and frm2 is activated via
ShowDialog. The user then cancels the save form (frm2) and the
twain/driver interface is once again activated.The scenario that has a problem is:
from frm1 = new form();
frm1.ShowDialog();The user selects the twain device from frm1, the twain/driver interface
is activated, the user selects acquire and frm2 is activated via
ShowDialog. The user then cancels the save form (frm2) and the
twain/driver interface closes down.The code that works with starting the form via Application.Run() is the
same code that doesn’t work when starting the form with ShowDialog.Does anyone have some insight as to what might be going on?
sounds like the same problem I recently had with my vb.net 2005 library when I run it from the console. The issue was message pump/thread related. I’ve got it worked out in vb.net for my private library, and should have the gotdotnet workspace updated within a week with a working sample that can acquire from the command line and that deals with the problem you’re having. the short answer (well, … the oner i used) is to open the twain lirary on a thread that isn’t your UI thread, and use thread.Join after you enableDs or enable DsUiOnly.
gabe
Hey Gabe – I totally did not understand the OP, but was interested in your comment. I just wanted to mention, that I think there are TWAIN drivers that create windows during the MSG_OPENDS – they don’t necessarily wait until MSG_ENABLEDS to create windows. Don’t know if that affects your code, but I was thinking about the fact that Win32 window handles are thread-specific – that is, they can only be used in the creating thread. I suppose even from .Net you are still dealing with Win32 handles underneath.
And I see you are responding to a lot of recent questions – well done, I was saddened to see a lot of old and unanswered questions on the forum.
yeah, i’ve got an epson that pops up a dialog in openDs. its a pain, but i’ve got the popups somewhat under control with a background thread that starts to poll before openDs, EnableDs, and EnableDsUiOnly. if it ‘sees’ a known dialog it sends the known command to close the dialog and live goes back to normal. I don’t like the polling aspect and i’m this close (holds up two fingers only somewhat close together) to getting a cbt hook in place so that the polling isn’t needed, and the dialogs at that point shouldn’t even touch the screen. Still a bother cataloging the dialogs that just dont belong in what i would like to conside a well behaved source. the code over at openTwain has the initial dialog manager now, when i get the cbthook in place i’ll post the update.
And if anyone wants to send in known dialogs that are bothering, i’ll add them to the catalogue and make them available.
thanks for the kind words spikeA 2nd thread – I would not have thought that would work (and obviously I would have been wrong…) – I’ve used the Hook technique to automatically handle a dialog, not in a TWAIN context.
I would love to see the TWAIN standard (1) require that sources not display *any* error dialogs until the app has had a chance to negotiate, and (2) add a capability that suppresses all pop-ups. It actually wouldn’t be hard for most driver writers to code – basically an “if !bSuppressDialogs” around each MessageBox call. One alternative would be a MSG_OPENDSQUIETLY – which would mean “open the DS with absolutely *no* user interaction allowed”. A failure from that would be much more useful than e.g. CAP_DEVICEONLINE as it is currently implemented.
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.@spike wrote:
..love to see the TWAIN standard (1) require that sources not display *any* error dialogs until the app has had a chance to negotiate, and (2) add a capability that suppresses all pop-ups…
no kindin huh. those dialogs are just show stoppers a lot of solution that work with twain.
But if we’re wishing here, I’d love to see enableDsUiOnly made mandatory. How else do you get reliable production scans without running all of the caps independantly? the std caps aren’t bad to work with but the custom ones are bit tiresome to code arround. At one point i think 25% of my code was just working around cap managment for a ds that didn’t suporrt enabledsuionly.- AuthorPosts