2

I traditionally have a lot of trouble with BackgroundWorkers in C# for some reason; their concept really seems to stump me, so I'm hoping this is a fairly basic issue and something the can be corrected easily enough...

I have two forms that use .NET remoting to communicate back and forth. Right now, changing a setting on Form1 causes something to change on Form2 and that works great. However, now I need to make the same thing work the other way (changing something on Form2 causes Form1 to update) and I can't do it the same way (I cannot, due to restrictions in the design, have Form2 send the change to Form1). Right now, I'm trying to use a BackgroundWorker on Form1 to constantly call an 'Update()' method on each of the subcontrols (which are placed on Form1). Each of these controls have the means to grab the current state of their equalivalent settings from Form2 and update themselves (this works well; the 'Update()' method is already seen to be working on the initialization of Form1).

Here's where my issue comes up. I was unsure on how make the BackgroundWorker constantly call 'Update()' on each of the forms, so in my 'DoWork()' method, I have a "while(true)" loop and within that the BackgroundWorker calls the 'Update()' method of each subcontrol, then sleeps for a very short time, then repeats.

Doing it this way, I get an "InvalidOperationException was unhandled by user code" error with details stating that "Cross-thread operation not valid: Control 'comboBox_BGColor' accessed from a thread other than the thread it was created on." Now, I basically know what this means and I understand why it happened, however, I'm unsure what to do differently or how to change things to make it work as desired. Anyone have any tips on this or the way I'm using BackgroundWorker? Thanks a lot for any information and for taking the time to read this!

JToland
  • 3,630
  • 12
  • 49
  • 70

3 Answers3

3

UI controls have thread affinity. You shouldn't touch the controls (for read or write) from any thread except the UI thread. If the BackgroundWorker is talking primarily to the UI, you would probably be better off with just a Timer control, avoiding the need to call Invoke or BeginInvoke lots of times.

However, generally I would prefer a more "observer" based design here, with change-notification events (either FooChanged or INotifyPropertyChanged) and event-handlers that cause the UI to reflect changes.

Marc Gravell
  • 1,026,079
  • 266
  • 2,566
  • 2,900
1

you need timer control instead of Background worker

TalentTuner
  • 17,262
  • 5
  • 38
  • 63
1

The exception you're receiving would be the result of calling Update() (which is modifying one or more forms in your primary thread ) directly from _DoWork within your BackgroundWorker's thread.

If you're going to use the BackgroundWorker method:

  • Set your worker's .WorkerReportsProgress property to true
  • When you perform your loop, use the worker's .ReportProgress() method to trigger the worker's _ProgressChanged event handler.
  • The _ProgressChanged event handler can then perform a call to your form's Update() method safely

If you move away from using the worker (especially if your background worker solely exists for this loop), then I'd suggest you go with Marc's suggestion of standard event handlers. That route will yield less processor overhead (however minimal it currently may or may not be) than adding in your external loop or a Timer control.

Either route should address the Cross-thread exception.

Community
  • 1
  • 1
Halbert
  • 11
  • 1