Curious about WinForm Control Thread Safety After Adding a Control on a Seperate Thread

Question

I have a FileSystemWatcher set to pick up an picture that will be dropped in a particular directory. The way I was handling it was to add a PictureBox in code that is docked in

Answer 1

No, it will not work. All GUI code must be done on the appropriate user interface thread. The thread context is not checked all the time, so it's possible to write something like that which will work now but fail on a future .NET framework update.

In your case FileSystemWatcher understands the ISynchronizeInvoke pattern, so just set its SynchronizingObject property to the form it works with. Note that if you put a FileSystemWatcher on a form using the designer, this property is set automatically.

Answer 2

Set Control::CheckForIllegalCrossThreadCalls to true in the beginning of the program. In this case, every cross-thread operation with Windows Forms immediately crashes the program. This is better than default undefined behavior, when CheckForIllegalCrossThreadCalls is false.

http://msdn.microsoft.com/en-us/library/system.windows.forms.control.checkforillegalcrossthreadcalls.aspx

Answer 3

No that will not work. Well, at least it will not work consistently. It might work for awhile, but eventually it will fail unpreditably and spectaculary. The general rule is that you cannot do anything to a Form or Control on any other thread than the one it was created on. In other words, they have thread affinity. What you really need to do is have the main UI thread create and modify the PictureBox by marshaling a message into it. This can be done by taking advantage of the ISynchronizeInvoke methods. All forms and controls implement this interface.

public void ThreadMethod()
{
  pnlCapturePicture.Invoke((Action)(() =>
  {
    PictureBox pb = new PictureBox(); 
    pnlCapturePicture.Controls.Add(pb); 
    pb.Dock = DockStyle.Fill; 
    pb.ImageLocation = photopath; 
  }));
}