Hey All,
I have introduced a new thread in my Winform application to control a
scanner that can often take some time and freezes up the application.
The thread and callbacks work great - I create and start a thread for
my scanning operations and I can continue to process commands (I tested
using a timer and writing to the console). But my windows form still
freezes until the callback is executed by the thread. I'm confused -
the whole point of the exercise was to allow my windows form to
continue to be responsive while scanning operations performed in
another thread in the background.
Before I post reams of code, does anyone have any ideas of what I'm
doing wrong?
Thanks in advance,
Rein
Kevin Spencer - 05 Jan 2006 19:15 GMT
The background thread should have no effect on the Windows Form, in terms of
interruption. A Scanner generally slows everything down a good bit (lots of
IO, I believe). Are you sure that the Form is frozen? If so, there must be
some link between the Form and the thread that is blocking the Form
execution from continuing.

Signature
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
> Hey All,
>
[quoted text clipped - 15 lines]
>
> Rein
rein.petersen@gmail.com - 05 Jan 2006 19:30 GMT
I think I understand the problem (a suspect problem anyway). I'm using
Windows XP and I expect it's handling my contravention of a prime
directive in Windows programming "Though shalt not operate on a window
from other than its creating thread"
I think this article will help me:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/wi
nforms08162002.asp
Thanks for helping out :)
Rein
Kevin Spencer - 05 Jan 2006 20:31 GMT
This could indeed be a problem, if the background thread attempts to make
changes to the state of Controls in the Form. There are actually 3 articles
in the series. Here are URLs to all 3:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/wi
nforms06112002.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/wi
nforms08162002.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/wi
nforms08162002.asp

Signature
HTH,
Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
>I think I understand the problem (a suspect problem anyway). I'm using
> Windows XP and I expect it's handling my contravention of a prime
[quoted text clipped - 8 lines]
>
> Rein
Richard Grimes - 10 Jan 2006 11:44 GMT
> The thread and callbacks work great - I create and start a thread for
> my scanning operations and I can continue to process commands (I
[quoted text clipped - 3 lines]
> form to continue to be responsive while scanning operations performed
> in another thread in the background.
What do you mean by callback? Any access to the UI should be on the UI
thread. Your worker thread should do this through a call to
ISynchronizeInvoke.Invoke on the form. Even so, the methods you call on
the UI thread should be small, if they take a long time then you'll find
that the UI will freeze because the UI thread will be spending time
running that code whjen it should be handling Windows messages.
Richard

Signature
Fusion Tutorial: http://www.grimes.demon.co.uk/workshops/fusionWS.htm
Security Tutorial:
http://www.grimes.demon.co.uk/workshops/securityWS.htm
Wojciech Bober - 11 Jan 2006 20:54 GMT
If you are using framework 2.0 you can also use BackgroundWorker class
which is able to report progres thru ProgressChanged event.