ansaurus

Question

Being Able to Debug a WinForms Application and Avoid the GUI from Freezing

Answer 1

A:

How is your thread posting information back into the main thread? I've been able to debug multithreaded apps by placing breakpoints in the worker thread before.

Really, you ought to make the bit that runs in the seperate thread testable on it's own. That way you can debug it in isolation and not have to worry about the inter-thread issues.

Jon Cage 2009-09-18 13:51:58

@Cage - true about making it testable. I whipped it up quickly, but will definitely do this.

nickyt 2009-09-18 14:53:38

Answer 2

A:

The UI (User Interface) thread is the main thread in your application responsible for processing windows messages, such as mouse clicks, keyboard input, repainting the screen etc.

So the UI thread is what calls RestoreDatabaseButton_Click (since this is a user interface interaction).

Before you introduced the new worker thread, this function was restoring a database from the UI thread. So while this was happening, the UI thread was not available to perform its other duties, such as redrawing the screen or responding to other user input, which was why your application appeared to freeze up.

The difficulties in debugging may just be because restoring a database is potentially a fairly intensive operation, involving writing to the file system which is a fairly low level task. The operating system may decide it needs to devote most of its time to the database restore, and not "context switch" very often, which is when the processor would switch to working on the UI thread. You could try starting the thread will a lower thread priority which should tell the OS to switch to your application more often.

Also, you need to be careful with how you manage the worker thread. For example, you should probably make it a member variable, and prevent the user from starting multiple worker threads concurrently (and disabling the restore button while the restore is happening). You should also consider providing a mechanism for stopping the thread should things go wrong, or when your application shuts down, to ensure the it shuts down cleanly.

John Sibly 2009-09-18 13:52:53

Answer 3

+1 A:

I think what you want to do here is send a message to the UI thread to take some action. You can pass this action has a delegate to the UI thread synchronously and asynchronously.

Basically, have your non-UI thread pull a reference to some UI object (any pre-existing instance of the Control class will do, perhaps your RestoreDatabaseButton instance) and call the Invoke method on it, passing a delegate containing the code to be executed as the parameter. This will enqueue a message on the UI thread to execute the delegate in its context rather than the context of your non-UI thread. The UI thread might already have a stack of messages to process, clicks, mouse movement, resize, etc., and will handle each in the order it was received. The Invoke method, will not return until the delegate you passed has been executed.

There's also a BeginInvoke method, this allows you to send a message to the UI thread that it will execute asynchronously. This method will return immediately, allowing your non-UI thread to continue executing even though the delegate may not have been executed yet. The EndInvoke method can be called after the BeginInvoke method and allows the non-UI thread to block until the delegate has been executed so that it can retrieve results from the delegate's execution. If the delegate doesn't return anything, there's no need to call this method.

In either of these ways, your non-UI thread can influence the UI thread and take actions against objects the live on it.

Travis Heseman 2009-09-18 13:53:53

Answer 4

+2 A:

Whenever you create an event handler for your form or controls it runs on the UI thread. The UI thread in a win forms app. is often also called the main application thread. This is the thread running the Application.Run() message loop.

I find it concerning that you say you "naturally decided to create a thread". Introducing extra threads is almost guaranteed to increase complexity and make your application harder to debug, as you have immediately discovered.

You have said you are inexperienced in non-web applications, so why introduce the complexity of threading on top of the learning curve of Windows Forms? Try a bit harder to get it working without using threads, then consider threads later on if it is still absolutely necessary.

In Windows forms you can often avoid threads by using a Timer and/or Application.DoEvents(). I am not saying don't use threads, just that I have seen many applications where it doesn't even make sense to allow the user to continue working while a process has not complete.

If you do want to stick with threads, I would also strongly recommend using the BackgroundWorker class. It nicely encapsulates a worker thread and provides good safe communication such as ProgressChanged and RunWorkerCompleted events.

Looking at your code I would also suggest doing some reading on accessing UI controls from worker threads. In short don't do it, unless using Control.Invoke() or Control.BeginInvoke(). This previous StackOverflow question would be a good start.

[UPDATE]

There are a number of places where your code is setting or checking properties of a UI control directly from the worker thread. To avoid exceptions and undefined behaviour you must always access UI controls from the thread that created them, ie. the UI/Main thread. Using Invoke() or BeginInvoke() allow you to do this safely.

Ash 2009-09-18 13:55:33

I'm of mixed feeling about this answer. I like the explanation of what the UI thread is, but asking why a thread is introduced seems to take a step backwards. The short answer is that Windows requires it to keep the GUI responsive, as it uses the GUI thread to do things like window paints/redraws, operating the message pump, etc... See what Jon Skeet says here: http://stackoverflow.com/questions/1035439/database-access-in-gui-thread-bad-isnt-it/1035451#1035451

R. Bemrose 2009-09-18 14:23:25

@R Bemrose, introducing threads to an application where they don't add some real benefit or there may be a viable alternatives is a BIG no-no. When you combine this with inexperience in Windows Forms this is a recipe for problems. Remember KISS and "the simplest thing that could work"?

Ash 2009-09-18 14:27:52

@R Bemrose, in that answer Jon says about a non-responsive GUI: "In some cases, particularly for "quick and dirty" tools, that's actually the right choice". The real point is that if you use threads, your debugging, testing and maintenance complexity automatically increases.

Ash 2009-09-18 14:37:43

Answer 5

+2 A:

It's kind of hard to understand exactly what you're asking, but I just wanted to tell you about one little helpful thing when multithreading windows apps. In order to update any UI elements from another thread, you need to call invoke. Example:

Say you want to update a progress bar from a worker thread:

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        Thread thread = new Thread(DoSomeLongRunningTask);
        thread.Start();
    }

    private void UpdateProgressBar(int amount)
    {
        Action<int> action = (p) => { this.progressBar1.Increment(p); };
        this.Invoke(action,amount);
    }

    private void DoSomeLongRunningTask()
    {
        //do whatever....
        UpdateProgressBar(1);
    }
}

EDIT: My bad, I didn't realize you weren't working with C# 3.0. Here's the same code without the fancy anonymous method:

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
        Thread thread = new Thread(DoSomeLongRunningTask);
        thread.Start();
    }

    delegate void ProgressBarIncrementer(int amount);

    private void UpdateProgressBarDelegateMethod(int amount)
    {
        this.progressBar1.Increment(amount);
    }

    private void UpdateProgressBar(int amount)
    {
        ProgressBarIncrementer incrementer = UpdateProgressBarDelegateMethod;
        this.Invoke(incrementer, amount);
    }

    private void DoSomeLongRunningTask()
    {
        //do whatever....
        UpdateProgressBar(1);
    }
}

BFree 2009-09-18 14:01:00

+1 for using a anonymous function to update UI. That's kewl.

Steve 2009-09-18 16:10:22

@BFree - Thanks but what you proposed doesn't work in .NET 2.0. I did stuff like this instead. Invoke((MethodInvoker)delegate { LogViewer.Text += "Running versioning scripts..." + Environment.NewLine; }); and it worked well. IS there a better way in .NET 2.0 to do this?

nickyt 2009-09-24 17:54:52

See my edit. You need to create a delegate and then pass that in to the Invoke method.

BFree 2009-09-24 19:22:12

Answer 6

+1 A:

The UI thread is responsible for painting the graphical elements of an application on the screen as well as handling user input.

When developing a multithreaded Windows application, there really is one main rule:

Any code that accesses the UI must run in the UI thread.

This means that, for example, in order to update the status of a progress bar from a background thread you need to run the code that accesses the ProgressBar control object in the UI thread.

There are a couple of ways to achieve this. When using Windows Forms you can take advantage of the BackgroundWorker class.

This class allows you to run code in a background thread and access the UI whenever you need to update it with the status of the operation simply by handling some specific events. The BackgroundWorker then takes care of running the code in the appropriate thread for you behind the scenes.

Enrico Campidoglio 2009-09-18 14:14:45

Answer 7

+1 A:

In a couple of your methods, you're creating and starting a Process and then going into a While() loop with a Thread.Sleep(3000) call and waiting for the Process' HasExited property to return true.

A better way to do this is to add a handler for the Process' Exited event, and perform your clean-up code there. Since your methods are running on the UI thread, the While() loops are part of your problem.

MusiGenesis 2009-09-18 14:18:25

Answer 8

A:

Here's how I would approach this:

Run all long running functions in individual Threads. You can accomplish this with the Thread class or a BackgroundWorker. Anytime I see a Sleep call, I would probably opt for a new Thread.
Do the parameter validation in the UI thread. You are updating the "LogViewer" TextBoxes and returning on error. That's fine.
Create a new Thread directly after the parameters are validated, the thread will call a function that handles spawning and waiting for the process.
Report the feedback by calling Invoke on a function that updates the UI. See BFree's post on a cool way to call Invoke.

Steve 2009-09-18 16:06:55

ansaurus

tags:

views:

answers:

Being Able to Debug a WinForms Application and Avoid the GUI from Freezing

related questions