If you need to update the UI based on work being done in the BackgroundWorker's DoWork event handler, I recommend using the BackgroundWorker.ReportProgress method and handling the BackgroundWorker.ProgressChanged event. The ProgressChanged event is guaranteed to run on the UI thread (if the BackgroundWorker object was created on the UI thread) and you can avoid having to manually marshal calls to the UI thread.
...of course, this requires that the BackgroundWorker.WorkerReportsProgress property is set to true upon initialization of the BackgroundWorker. It's actually a Windows limitation that .NET recognizes; Windows doesn't support cross-thread access to windows. On Fri, 20 Jul 2007 15:39:20 -0400, kara hewett <[EMAIL PROTECTED]> wrote: >Hi, > >Someone wrote me privately about this thread email chain expressing >questions about my previous remarks. Presently, .NET is not designed to >safely and reliably interact with Windows Forms controls across thread >boundaries. To correct this deficiency, marshal any data or interactions >from the background thread to the same thread of the Windows Forms. One >option for accomplishing this is a delegate. For example, if you want to >update a GUI component from the BackgroundWorker's event handler, you need >to define a delegate with arguments mirroring the data to pass and use the >Form's Invoke method. Call Invoke with the delegate address and data >marshalling. The thread pool using ThreadPool.QueueUserWorkItem or joined >worker threads would operate on the server and respond back to the client. > >The article "Safe Multithreading with the BackgroundWorker Component" >provides a better explanation than my previous emails. =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
