I've been attempting to create a task that writes to a database without blocking the UI thread. The biggest problem I'm having is waiting for that process to finish without the blocking happening.
I've been trying to avoid using DoEvents (though it's used quite frequently through this program right now, I'd like to move out of using it while moving forward).
I've attempted to create the process to run on a 2nd thread and waiting for it to finish as well as using a BackgroundWorker.
The problem I have with this is not having the code run in a different thread, but trying to find a way to wait for it to finish.
Basically, Right now I do the following:
- Connect to the database
- Create a background worker (or thread) to do the writing to the database (I will probably end up with the
BackgroundWorker so I can use the ReportProgress
- Start the thread or
BackgroundWorker
- Use a While loop to wait for the thread /
BackgroundWorker to finish. For the thread, I wait for IsAlive to become false, for the BackgroundWorker, I toggle a boolean variable.
- I let the user know the process is finished.
The problem is in #4.
Doing a while loop with no code in it, or a Thread.Sleep(0) leaves the UI blocked (Thread.Sleep(0) makes the program take 100% of the program resources as well)
So I do:
while (!thread.IsAlive)
Thread.Sleep(1);
-or-
while (bProcessIsRunning)
Thread.Sleep(1);
which blocks the UI.
If I call Application.DoEvents() there, the UI is updated (though it's clickable, so I have to disable the entire form while this process runs).
If I run the process synchronously, I still need to create some sort of way for the UI to be updated (in my mind, a DoEvents call) so it doesn't appear locked up.
What am I doing wrong?
C# uses an event model -- what you want to do is dispatch the process that does the work and then have that process fire a custom event when done or use one of the threading events. While the process is running in the "background" release control back to the system from your code.
Firstly, why do you wish to avoid DoEvents()?
Secondly, you're using conflicting terms.
waiting == blocking
You say you don't want to block the UI thread, but you do want to wait for the task to finish. These are mutually exclusive states. If you're waiting for something to finish, you're blocking your thread.
If you want the UI to actually be usable (not blocked), then you don't wait for your task to finish. Just register an event handler to fire when it finishes. For instance with a BackgroundWorker, handle the RunWorkerCompleted event. For a Task, you can use a continuation to dispatch a callback to your main thread.
But it seems you just want the UI to be updated, not usable. Usually that only makes sense if you want a progress bar or some other UI animation to keep moving. In that case, I would open a modal dialog, kick off my task, and then wait on it while, yes, calling DoEvents().
var dialog = new MessageBoxFormWithNoButtons("Please wait while I flip the jiggamawizzer");
dialog.Shown += (_, __) =>
{
var task = Task.Factory.StartNew(() => WriteToDatabase(), TaskCreationOptions.LongRunning);
while (!task.Wait(50)) // wait for 50 milliseconds (make shorter for smoother UI animation)
Application.DoEvents(); // allow UI to look alive
dialog.Close();
}
dialog.ShowDialog();
The modal dialog prevents the user from doing anything, but any animation will still work because of DoEvents() being called 20 times a second (or more).
(You would probably want to add special handling for different task completion states, but that's off-topic.)
You cannot wait on the UI thread.
Instead, add a handler to the Exited event.
I don't know if this will simplify your issue, but we use the Essential Objects controls: http://www.essentialobjects.com/Products/EOWeb/ to manage our long processes.
If you delegate the long db operation to a backgroundworker thread then
progress is signalled by firing the ProgressChangedEvent from worker, you handle that say updating a progress bar in the UI.
Equally finished is signalled by firing RunWorkerCompleteEvent.
No polling required / looping Do events required.
The question is while your background thread is doing something what are you not allowed to do in the form.
Close it, change an edit box? etc.
That's done through some sort of state machine could be somethings as simple as you disable a button when you kick the thread off and then enable it again in the RunWorkerCompleted event.
Of you could leave the buutom alone and check a boolean called busy in it's Click handler.
Are you offloading the process to show progress or simply to avoid "Windiows is not responding" or are there other things the user can sensibly do while it's in mid process, such as close the form, cancel the operation etc.
Once you've figured out what the UI should be doing you can hook the backgrondworker events into some code that will manage things.
