Question

The only reason I chose to use a BackgroundWorker for the application I am currently developing is to move the lengthy time-consuming browsing via a WebBrowser away from the UI thread.

But isn’t WebBrowser.Navigate() accessing the UI?

In other words, I went through all this effort, only to land in the same spot (or worse! because I have no idea what side-effects could a non-UI thread have when accessing UI controls).

I am pretty sure I am not the first one wanting to implement something like this, so my question is: What is an acceptable way to solve this problem? i.e. To WebBrowser.Navigate() from BackgroundWorker?

Answer 1

Navigate() is not a blocking call (see the first line in the MSDN docs), but it does update UI, and so it needs to be called from the UI thread.

You have a couple of options:

1. Marshal the Navigate() call onto the UI thread from the BackgroundWorker via an Invoke call
2. Don’t use a BackgroundWorker – just make the call to Navigate() from your UI (e.g. a button click event handler) and listen for the WebBrowser DocumentCompleted event.

For an example of 1 – see https://stackoverflow.com/a/1862639/517244

Here’s a code sample for 2:

public partial class MainForm : Form
{
    public MainForm()
    {
        InitializeComponent();
    }

    private void _goButton_Click(object sender, EventArgs e)
    {
        _webBrowser.Navigate("http://google.com/");
        // Non-blocking call - method will return immediately
        // and page will load in background
    }

    private void _webBrowser_DocumentCompleted(object sender, WebBrowserDocumentCompletedEventArgs e)
    {
        // Navigation complete, we can now process the document
        string html = _webBrowser.Document.Body.InnerHtml;
        // If the processing is time-consuming, then you could spin
        // off a BackgroundWorker here
    }
}