Bug 447847

Quick comment: we cover this to some aspect by checking Control.InvokeRequired, then using Control.BeginInvoke to modify the controls as necessary.  Some things to look at:

* Are we using *Invoke* stuff everywhere we need to be?
* How are we testing this?
* When we use BeginInvoke, do we need to wait on the delegate to return? That is, do we move on, expecting the control to be modified when it might not yet have been?
* What other issues lurk?

Quick update:

* I believe we are using BeginInvoke everywhere we need to at this time
* QA's samples are the only real way of testing this, often enough.
* We use BeginInvoke instead of Invoke because we can't wait on the delegate to return...often the action we take in BeginInvoke will raise events that need to be handled back on our thread, and so we can't be waiting for the delegate to return or we get deadlock.
* Potential issue, untested: Because of using BeginInvoke, it seems possible that you could do provider.Select() and then immediately after check provider.IsSelected, and if there's any delay on the delegate then IsSelected would still return the old value.
* BIG ISSUE: We cannot allow *any* exceptions to occur in the delegate.  Unhandled exceptions in a BeginInvoke delegate go to the applications untrapped exception handler, and it's really messy and can be assumed to cause the app to crash.  So if we need to do checks and possibly raise exceptions, we need to do that in our thread *before* BeginInvoke.  We should keep our BeginInvoke delegates simple, do lots of checks before the BeginInvoke, and maybe even the entire body of each delegate in a try/catch that outputs exceptions so we can see them, even though we can't really handle them (since we can't wait for the delegate to return, etc etc).

I looked through all of our BeginInvoke calls and after a few fixes I don't see any place where I'd expect exceptions to occur in our delegates, but of course it's always possible so I think we should do the try/catch.