Unresponsive UI during lengthy processing

[Marcos Stefanakopolus]

Ok, I'll admit it, I'm a winforms newbie. I'm writing an image processing
program that, by its nature, gets into some fairly lengthy processing
cycles. As long as I don't touch the UI while it's working, don't alt-tab
away and come back, don't minimize and restore--in short, as long as I sit
there like a dope waiting for the processing to be completed, things are
fine. My UI updates itself at the right times with progress bar updates,
updates to the PictureBox control that has the image in it, and even updates
to a RichTextBox that shows some debugging type output. But the second I do
anything at all (even just dragging the window around), the entire UI stops
showing any updates. If I bring some other app on top of mine and then
bring mine to the front, it doesn't re-draw at all, leaving me with an empty
white box where my UI should be. Obviously, this is irritating as heck
because frequently I'd like to be doing other things, like checking my
e-mail and stuff, while my program is working.

I realize that there is probably some general principle of writing winforms
apps so the UI stays responsive no matter what the rest of the app is doing,
but I'm cluless as to what it might be. Worse, being new to windows
programming in general (having finally taken the plunge out of the crusty
world of the command line app), I have no idea what I should be searching
for in the Visual Studio documentation.

Any hints, even just a pointer to the relevent docs, would be greatly
appreciated! Thanks.

 

[Jon Skeet [C# MVP]]

I realize that there is probably some general principle of writing
winforms apps so the UI stays responsive no matter what the rest of
the app is doing, but I'm cluless as to what it might be.

See http://www.pobox.com/~skeet/csharp/threads/winforms.shtml

Basically, you shouldn't be doing any length processing on the UI
thread - but you also mustn't "touch" the UI from any thread *other*
than the UI thread.

 

[james]

Application.DoEvents

Add that just before the code that ties up your application and it "should" let other events occur without the problems. I had a
similar problem when parsing a large XML file for a database and adding that just before executing that part of the code freed
up the application.
james

 

[Ajay Kalra]

Marcos,

Following articles show how to solve this problem in WinForms. These discuss
couple of options, using threads and delegates. Its worth a look in addition
to Jon Skeet's site.

http://msdn.microsoft.com/vcsharp/u...brary/en-us/dnforms/html/winforms06112002.asp

http://msdn.microsoft.com/vcsharp/u...brary/en-us/dnforms/html/winforms08162002.asp

http://msdn.microsoft.com/vcsharp/u...brary/en-us/dnforms/html/winforms01232003.asp

 

[Jon Skeet [C# MVP]]

Application.DoEvents

Aargh, no. That's just a hack to simulate threading - when proper
threading is available, there's very rarely a good reason to use
Application.DoEvents, IMO.

 

[Marcos Stefanakopolus]

Excellent information; just what I was looking for. Thanks. So after much
further reading and thinking, tell me if I've got this right:

Since I want the worker thread to update controls created in the UI thread,
in C# parlance that means that I want the worker thread to delegate the
updating to a method in the UI thread. The clean windows-ish way to do that
is to create some events in the worker thread, and have the UI thread
subscribe the delegates to them. When I fire the event, do so in a
BeginInvoke() call.

 

[Jon Skeet [C# MVP]]

Excellent information; just what I was looking for. Thanks. So after much
further reading and thinking, tell me if I've got this right:

Since I want the worker thread to update controls created in the UI thread,
in C# parlance that means that I want the worker thread to delegate the
updating to a method in the UI thread. The clean windows-ish way to do that
is to create some events in the worker thread, and have the UI thread
subscribe the delegates to them. When I fire the event, do so in a
BeginInvoke() call.

Not quite - you don't need any events, and events themselves aren't
associated with any particular thread. You just need to create
appropriate delegates and call Control.BeginInvoke(). Other than that,
you're spot on.