BackgroundWorkers abd WebBrowsers

[Mike B]

I'm a bit of a threading newbie, and have just converted an app from
Threads to BackgroundWorke rs to try to get some more life out of the
UI. From reading here and elsewhere, I have a general understanding
of the "don't mess with the UI" rule and why that is.

But, what about the case where your thread fires off an async
operation? In that case, the thread's RunWorkerComple ted event fires
almost immediately. Does this mean you're safe? More specifically,
the thread only starts a WebBrowser.Navi gate, the WebBrowser
(eventually) fires a DocumentComplet e event, and in response to *that*
event, the UI gets updated. (This is the method I'm using to open ten
web pages at once in a tabbed form, and update a visible counter as
each finishes loading.)

On every machines here, that works just fine. I'm suspecting though,
that it might be behind a "cascade of JIT debug messages" reported by
a user whose machine I'm hoping to access in the next few days. But
where to look - just trying to make substantial use of these
WebBrowser controls has taught me many new ways a pc can die, so I
don't want to rush to judgement.

So the question - does the rule still apply here, meaning that I
should used a timed check to keep the BackgroundWorke rs alive until
DocumentComplet e fires, then raise an event from the thread? If I am
breaking the rule, am I any more likely to see these "intemitten t"
symptoms when I'm really overworking a machine?

If that's not a potential source, I'm still a little confused by the
whole error-handling issue when using BackgroundWorke rs. Is this
supposed to be something that can cause runtime errors, or is it just
a nuisance in the IDE? I use a standard try-catch on *every* routine,
it passes the exception to a global sub that will log the error, and
pops up a custom error form if that's enabled. The first time I read
about this, it looked like I *must* remove them from anything that
might be in a calling chain originating from a BackgroundWorke r. But,
I just haven't had any problems in the IDE - I forced some errors &
saw just what I normally would, both in and out of the IDE.

OTOH, I do not have any error handling in the DoWork event handler,
and was not using the RunWorkerComple ted event at all. Could this
mean that the JIT messages were just unhandled errors (unhandled even
though they have try-catch, because of this issue) that bubbled up to
DoWork, and had nowhere else to go?

I hope that all makes sense, because it's staring to confuse the heck
out of me. Any breadcrumbs would be greatly appreciated.

MikeB

[Steve Gerrard]

Re: BackgroundWorke rs abd WebBrowsers

Mike B wrote:

I'm a bit of a threading newbie, and have just converted an app from
Threads to BackgroundWorke rs to try to get some more life out of the
UI. From reading here and elsewhere, I have a general understanding
of the "don't mess with the UI" rule and why that is.
>
But, what about the case where your thread fires off an async
operation?

I wouldn't do that. There is no reason not to call an async method directly from
the UI thread, since it will return almost immediately, and later raise an event
when completed. Nesting that within another thread is asking for issues, it
seems to me.

When you do use a background worker, it should only catch exceptions that the
thread can fix and consume, not ones that need to percolate back up to the UI.
Those should be left alone. They will cause the background worker to end and
raise its completed event, with the fact that there was an exception, and what
the exception was, ready for your completed event handler to process
appropriately within the UI thread.

[Mike B]

Re: BackgroundWorke rs abd WebBrowsers

On Sat, 26 Jul 2008 12:49:57 -0700, "Steve Gerrard"
<mynamehere@com cast.netwrote:

>Mike B wrote:

>I'm a bit of a threading newbie, and have just converted an app from
>Threads to BackgroundWorke rs to try to get some more life out of the
>UI. From reading here and elsewhere, I have a general understanding
>of the "don't mess with the UI" rule and why that is.
>>
>But, what about the case where your thread fires off an async
>operation?

>
>I wouldn't do that. There is no reason not to call an async method directly from
>the UI thread, since it will return almost immediately, and later raise an event
>when completed. Nesting that within another thread is asking for issues, it
>seems to me.
>
>When you do use a background worker, it should only catch exceptions that the
>thread can fix and consume, not ones that need to percolate back up to the UI.
>Those should be left alone. They will cause the background worker to end and
>raise its completed event, with the fact that there was an exception, and what
>the exception was, ready for your completed event handler to process
>appropriatel y within the UI thread.
>

Thanks Steve. That's what I get for doing real work based on
subjective analysis I guess - could have sworn the WebBrowser was less
of a hog when in a thread. But having now stripped all that out, what
should have been intuitively obvious - async is async, doing it twice
improves nothing - is apparently true. The real shock was doing
something I should have done long ago - compared my app's performance
loading x pages to IE7's loading the same ones in a tab group. IE7
takes twice as long and is far less responsive during load, so I guess
I'm ok. :)

MikeB