Cross thread exception

Question

I am having a problem for a while

this line:

txtPastes.Text = (string)e.UserState;

throws a cross thread exception and I didn't find any solution

txtPastes - textbox

GuiUpdate - BackgroundWorker

lstAllPastes - list of string

    private void GuiUpdate_DoWork(object sender, DoWorkEventArgs e)
    {
        while (true)
        {
            while (lstAllPastes.Count == 0) ;

            for (int i = 0; i < lstAllPastes[0].Length; i++)
            {
                GuiUpdate.ReportProgress(0, lstAllPastes[0].Substring(0, i));
                Thread.Sleep(1);
            }
            lstAllPastes.RemoveAt(0);
        }
    }

    private void GuiUpdate_ProgressChanged(object sender, ProgressChangedEventArgs e)
    {
        txtPastes.Text = (string)e.UserState;
    }

    private void GuiUpdate_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
    {

    }

You didn't find any solution? This is probably the most common problem when using threading in GUI applications. — svick, Feb 18 '12 at 16:23

Douglas · Accepted Answer · 2012-02-18T16:51:01.600

You cannot update a UI control from any thread other than the UI thread. Typically, the BackgroundWorker would take care of raising its ProgressChanged and RunWorkerCompleted events correctly on the UI thread. Since that doesn’t appear to be the case here, you could marshal your UI-updating logic to the UI thread yourself by using the Invoke method:

txtPastes.Invoke(new Action(() => 
{ 
    // This code is executed on the UI thread.
    txtPastes.Text = (string)e.UserState; 
}));

If you’re on WPF, you would need to call Invoke on the control’s dispatcher:

txtPastes.Dispatcher.Invoke(new Action(() => 
{ 
    txtPastes.Text = (string)e.UserState; 
}));

Update: As Thomas Levesque and Hans Passant have mentioned, you should investigate the reason why your ProgressChanged event is not being raised on the UI thread. My suspicion is that you’re starting the BackgroundWorker too early in the application initialization lifecycle, which could lead to race conditions and possibly a NullReferenceException if the first ProgressChanged event is raised before your txtPastes textbox has been initialized.

I was starting the BGW after the initializecomponent() – maryum375 Feb 18 '12 at 16:58 — maryum375, Feb 18 '12 at 16:58

Hans Passant · Answer 2 · 2012-02-18T16:45:29.500

Well, this is supposed to work of course. The cause of this exception is not visible in your snippet. What matters is exactly where and when the BackgroundWorker is started. Its RunWorkerAsync() method uses the SynchronizationContext.Current property to figure out what thread needs to execute the ProgressChanged event handler.

This can go wrong when:

You started the BGW too early, before the Application.Run() call. Winforms or WPF won't yet have had a chance to install its own synchronization provider.
You called the BGW's RunWorkerAsync() method in a worker thread. Only marshaling to the UI thread is supported, the message loop is the crucial ingredient to make running code on another thread work.
The form that has txtPastes control was created on another thread. With the BGW started on the UI thread that's still a thread mismatch
The form's Show() method was called on another thread. Which creates the native Windows window on the wrong thread.

"Its constructor uses the SynchronizationContext.Current": not true; check with Reflector ;). The synchronization context is actually picked up when you start the BGW with RunWorkerAsync, through the use of the AsyncOperation class — Thomas Levesque, Feb 18 '12 at 16:39
yes it was true I really started the work of the background worker in the windows constructor and now I fixed it by moving it into private void Main_Load which is called when the form loads but still the same problem — maryum375, Feb 18 '12 at 16:56

score 1 · Answer 3 · answered Feb 18 '12 at 16:27

1

Make sure you start the BackgroundWorker from the UI thread; if you do that, the ProgressChanged event will be raised on that thread, and the exception won't happen.

answered Feb 18 '12 at 16:27

Thomas Levesque

286,951
70
623
758

Cross thread exception

3 Answers3

Linked