Windows Forms User Interface freezing for no apparent reason

Hi

I've got something odd going on which I hope will make sense to someone because at the moment it's making precisely no sense to me whatsoever.

I've built a Winforms application which reads the contents of a CSV file in, transfers those contents into a database and then proceeds to run a series of stored procedures against the full dataset.

The form that the import is launched from contains a number of controls designed to provide feedback to the user so that s/he can see how the import is coming along. When the user clicks the button to begin the import, the event behind that button launches a subroutine which is held in a dedicated class file.

The signature for that subroutine contains 17 separate elements, most of which correspond to controls on the main form. One of those elements is a Progress Bar which (perhaps obviously) increments as each row of data is read in from the incoming file. As each row is read in (using a StreamReader object), the information found is passed to an object. If the various elements in the row are as expected, they are passed to a stored procedure for insertion into the back-end database.

Here's the thing that's stumped me: when I run the application on my local machine (i.e. my development environment), everything proceeds without a hitch - everything is updated as it should be and the system is providing plenty of feedback to me. However when I deploy the application (we use Click-Once here), the application appears to become unresponsive during the import. There's no reason given for the lack of responsiveness and it's never at the same point in the file. Also, the application IS still working but my concern is that when I give it to my end-users to play with, they'll panic when they see the application reporting itself as not responding and will therefore crash out of it.

I've got a number of timers in use in other places in the application but I've disabled all of those in case they were running interference.

Something to be aware of: because of ongoing issues I've had with multithreading, I've got everything running on the same thread. If this isn't a good idea then that's my bad, but it still confuses me that the application runs properly when in development mode, but seems very flaky when deployed to a live environment.

If I helps, my development environment is 8.1 64-bit edition, with the application targetted to an x86 environment since our company is running both. I've also tried restarting my computer in case there was something hogging memory.

Hopefully someone can help me here....

TIA

Every Windows developer /has/ to learn about multithreading. Ideally, in a tame environment without a deadline. It sounds like you're going to have to learn as you go.

There is 1 legal thread from which controls can be accessed. It's called the "Main thread" or the "UI thread". That is also the thread that has to pain the controls. There is a data structure called a "message queue". When anything happens: mouse movements, key presses, repaints, a data structure describing that event ("a message") is placed in the queue. The UI thread loops, checking the queue and processing the messages in order. It looks like multithreading, but it's not.

Say you click a button that changes a TextBox's value. The click puts a message in the queue. The next time the UI thread loops, it sees the click message, removes it from the queue, and executes the button's event handler. That event handler changes the TextBox's text, which puts 2 new messages in the queue: TextChanged and "the textbox needs to paint again". Then the button event handler finishes. The UI thread loops again, and finds the TextChanged event. If there's an event handler, it's executed, and it might add more to the queue. Then the UI thread loops again and finds the "TextBox needs to be painted" event, and lets it repaint. This all happens so fast you think it's instantaneous.

Now imagine the button click handler changes the text, but takes 15 seconds to execute. When the text changes, TextChanged and "I need to paint" still go in the queue. But the button handler is still executing, so the UI thread's still busy. So the text can't change for at least 15 seconds.

The only way to get around this is to try and set up long-running tasks so they run on different threads. That leaves the UI thread free to process the message queue and respond quickly to user input and property changes. I like the Task API for this, lately. But a lot of people feel more comfortable with the BackgroundWorker API. I'm going to type up a crash course in either really quickly, but want to leave this here so you can hear the best instructions:

Go read about the BackgroundWorker class. Go play with the MSDN examples. Try to rewrite them without looking. Get comfortable with thinking about other threads. Don't try to do everything at once, yet. Learn this pattern:

• Gather the information the thread needs.
• Start the thread, using only variables that thread can access.
• Wait for the thread to finish and rejoin the main thread.
• Update controls and get ready to start the next thread.

It's much harder to try and coordinate many threads at once. You're already doing things one at a time. So let's stick with that, because it's easier.

How long it takes for an application to be marked as "not responding" varies depending on a wide variety of things (including per-machine settings), and how likely it is that will happen depends on several others (such as other applications running at the same time, and things to do with your application, in this case a database lock is one of many potential causes).

To avoid the "not responding" state, the best answer is usually using a separate thread (even if that gets blocked, the main thread can still respond). A simple way to do that is to use a BackgroundWorker, which has a built in way for you to report progress back to the main thread, which can then update the progressbar.

Unfortunately I haven't got time to make an example, but finding one should be easy enough (I know we have some in the CodeBank forum).


edit: beaten to it!

There are several ways to go about threading in a WinForms application. Before we mention any of them, there's a very important fact to know. I'm going to bold it, because if you forget or neglect it you will find the results very confusing.

There is only one thread that can interact with controls or the UI. 90% of mastering Windows Forms threading is learning how to know if you're on that thread, and how to guarantee you're on that thread when needed.

Get that tattooed on your arm. If you forget it, you're going to hurt.

There's a lot of ways to go about writing "asynchronous code". That's the fancy way of saying "bits of code that do something on another thread and coordinate with the UI thread in a controlled manner." That's the important part, a good approach to asynchronous code will guarantee parts of your code always run on a particular thread. That means a lot less worrying about whether some activity is safe.

Now one bad thing that may be going for you? If you're using a DataAdapter and binding to controls, I'm going to be talking the wrong way. If you work with that thing from another thread, it's going to end up trying to update bindings from that thread, and everything will fall apart. There's probably a way to use it asynchronously. I haven't used a DataAdapter in more than ten years. Someone else will have to teach that.

A bandage: Application.DoEvents()
Let's get one bad idea out of the way first, because you might have to use it. There's a method, Application.DoEvents(), that people will tell you "fixes" this problem. It 'makes the problem better', but does not fix it. When you understand what it does, and you understand the message queue, you'll understand what I mean.

Application.DoEvents() runs the message queue loop until there are no messages to process. So back when I said the button click handler wouldn't update text for 15 seconds? If the order were, "Update text, DoEvents(), take 15 seconds", then the text will update right away. Problem solved, right? Well, that's not the full answer. What really will happen is, "The text updates, the form freezes for 15 seconds, then the form is fine." If you're not constantly calling Application.DoEvents() during that 15-second operation, the form's still unable to process events. And if you're waiting on a stored procedure, you don't have a way to call Application.DoEvents() while waiting.

So you can probably figure in some applications, this works fine and solves the problem. But in other applications, it only solves part of the problem. This is why I tell people never use Applicaton.DoEvents(). I'd rather teach solutions that always work. But. If you're in a pickle, you might be able to buy yourself some time with it. Your choice. Don't blame me if things get worse.

What you're not picking: Thread, or IAsyncResult patterns.
Don't bother imagining you're going to create a Thread. Thread is the nuclear option. It gives you the most control, but asks you to worry about synchronization and getting to the UI thread yourself. Definitely don't learn it first. Save it for when you're real comfortable with other methods.

There's an older .NET Asynchronous pattern that uses methods named "BeginSomething()" and "EndSomething()", and uses an instance of IAsyncResult to coordinate the calls. You can live without this pattern. MS isn't making any new types that use it going forward, and in many cases has added newer methods alongside them on popular APIs. It's an OK pattern, and worth learning before Thread, but it asks you to think a little too hard about getting onto the UI thread.

BackgroundWorker
HERE is an actual asynchronous helper class. It's an implementation of a pattern MS introduced in VS 2005 called the "Event-Based Asynchronous Pattern". You can write your own BackgroundWorker from scratch, but let's save that for when we want to have some fun.

The pattern is best explained in terms of BackgroundWorker. Here's how it goes.

First, you set up. This happens on the UI thread. If you need information from controls, it's time to get it, because soon you're going to be on another thread and they will not be safe. Got everything you need? Good. Now you create a new BackgroundWorker, and configure it. You might be adding progress reporting, you might be adding cancellation, you can read about those later. Now you add event handlers. You need to handle the DoWork event. And you probably want to handle the RunWorkerCompleted event. You might need to handle the ProgressChanged event. We'll get cozy with these later. Got your data? Got your BackgroundWorker? Got your events configured? It's time to call RunWorkerAsync(). This method starts the worker thread.

When you call RunWorkerAsync(), the BackgroundWorker starts a worker thread, and from that worker thread it raises the DoWork event, which you handled. This event handler runs on a worker thread, not the UI thread. You can't safely access a control from it. This is where you do your stored procedure call or whatever. Maybe you want to update some controls while this is happening.

To do that, you can call the BackgroundWorkers's ReportProgress() method. It takes an integer for a percentage, and an optional Object that can be any other data you want to send. When you call this method, the BackgroundWorker will raise its ProgressChanged event on the UI thread. So understand: if you're about to do something that is slow, you will make the form freeze. But this also means it's perfectly safe to update controls from the ProgressChanged event. You can get the things you passed to ReportProgress() via the EventArgs that the ProgressChanged event receives.

Eventually, your DoWork work finishes. It probably has results and you probably want to put those in the UI. DoWork's event handler receives a DoWorkEventArgs. It has a Result property. That's how you "give results back" to the UI thread. When the DoWork event handler finishes, the thread is finished.

When that happens, the BackgroundWorker raises the RunWorkerCompleted event on the UI thread. Again, this means it's safe to update UI controls but you want to be quick about it. You can get the result you set in DoWork from the EventArgs that RunWorkerCompleted receives.

So if you think about it, you'll see that BackgroundWorker makes it very clear which code runs on which thread, and how you send information back and forth between them. That's why I like it, and that's why it's very popular. Here's a cheat sheet:

• Setup: gather control data, create the BackgroundWorker, handle its events, call RunWorkerAsync(). This raises DoWork on another thread. If you pass an object to RunWorkerAsync, the DoWorkEventArgs will contain that in a property named UserState.
• DoWork: Happens exclusively on the worker thread. Receives data from the UI thread via DoWorkEventArgs. Can send data to the UI thread by either calling ReportProgress() or setting its EventArgs' Result property.
• ProgressChanged: Happens exclusively on the UI thread. Receives data from the worker thread via its ProgressChangedEventArgs. Cannot send data back to the worker thread.
• RunWorkerCompleted: Happens exclusively on the UI thread. Receives data from the worker thread via its RunWorkerCompletedEventArgs. Cannot send data back to the worker thread.

Does this sound useful? I'd have loved to talk about the Task API, but I'm running out of time. I think if you play around a bit with BackgroundWorker (and find examples), you'll find it a lot easier than trying to manage a thread yourself.

Thanks to both of you for your prompt replies. In the intervening period I've had a play with the Application.DoEvents method which doesn't seem to have made any difference. For my next trick (tomorrow) I'll have a look at the BackgroundWorker stuff and see what I can make of that, in tandem with Sitten Spyne's comments.

Si, I wondered if the issue was coming from my own machine. I recently installed an Express edition of SQL server on my machine (and promptly forgot I'd done so) so I was having performance issues for a while until I remembered I'd done it. Long story short, SQL Server services have now been disabled on my PC and the machine was restarted before I started this thread. I agree that it could be a database timeout, given that the length of time that passes before the application becomes non-responsive is never the same twice.

I'll take all of your comments away and see what I can sort out. I'll let you know once I have a working solution.

It may be down to your SQL Server situation, but that is only one of a very large amount of possible causes... even if you track down the specific things that are currently causing you problems and 'fix' them, there is no guarantee that the issue will be gone (or stay away).

Switching to using a separate thread (such as the BackgroundWorker) means that the issue doesn't exist any more, so you don't need to worry about any of the causes of it.

While using a BackgroundWorker for the first time may be a little time consuming, it should be less time than attempting to work out the cause(s) you are currently experiencing.