Winforms and threading strangeness

[rein.petersen]

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]

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.

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

 

[rein.petersen]

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/winforms08162002.asp

Thanks for helping out

Rein

 

[Kevin Spencer]

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/winforms06112002.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms08162002.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms08162002.asp

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

 

[Richard Grimes]

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.

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

 

[Wojciech Bober]

If you are using framework 2.0 you can also use BackgroundWorker class
which is able to report progres thru ProgressChanged event.