Reputation: 9106
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
?
Upvotes: 4
Views: 3781
Reputation: 11567
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:
Navigate()
call onto the UI thread from the BackgroundWorker via an Invoke
callNavigate()
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
}
}
Upvotes: 4