Unresponsive UI during lengthy processing

  • Thread starter Thread starter Marcos Stefanakopolus
  • Start date Start date
M

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.
 
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
 
Application.DoEvents
Click to expand...

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.
 
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.
 
Marcos Stefanakopolus said:
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.
Click to expand...

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