Form.Show() causes an InvalidOperationException in visual studio 2010 that was not there in 2008
I have some code that takes a form object (winforms) and calls form.Show() on a dedicated thread (it spins a new thread). This worked fine in Visual Studio 2008 (framework 3.5). I now migrated to 2010 and it fails with InvalodOperationException: "Cross-thread operation not valid: Control '' accessed from a thread other than the thread it was created on."
(of course half our files are checked out for the migration and the whole team is waiting...)
Here is some code (this is the running code so fogive me for some redundant level of detail):
private void ShowForm(object container)
{
FormContainer formContainer = (FormContainer)container;
Process sboProcess = GetSboProcess();
if (sboProcess != null)
{
WindowWrapper MyWindow = new WindowWrapper(sboProcess.MainWindowHandle);
if (formContainer.ShowDialog)
{
formContainer.Form.ShowDialog(MyWindow);
}
else
{
//formContainer.Form.Invoke((MethodInvoker)delegate() { formContainer.Form.Show(MyWindow); });
formContainer.Form.Show(MyWindow);
//Run thread while form is opened:
System.Windows.Forms.Application.Run(formContaine开发者_如何学Gor.Form);
}
}
}
public class FormContainer
{
private readonly Form form;
private readonly bool showDialog;
public FormContainer(Form form, bool showDialog)
{
this.form = form;
this.showDialog = showDialog;
}
public bool ShowDialog
{
get { return showDialog; }
}
public Form Form
{
get { return form; }
}
}
public class WindowWrapper : IWin32Window
{
private readonly IntPtr handle;
public WindowWrapper(IntPtr handle)
{
this.handle = handle;
}
#region Implementation of IWin32Window
/// <summary>
/// Gets the handle to the window represented by the implementer.
/// </summary>
/// <returns>
/// A handle to the window represented by the implementer.
/// </returns>
/// <filterpriority>1</filterpriority>
public IntPtr Handle
{
get { return handle; }
}
#endregion
}
Anyone with an idea?
Thanks,
Asher
In a sentence; the dedicated thread must call back to the UI thread that owns the form. Cross-thread UI operations are illegal, because there are certain operations that could cause the UI control involved to become detached from the Windows message pump. This is a bad thing because then Windows cannot tell the window to do anything, including draw itself, move, or even close. The window becomes "rogue", and all Windows can do is terminate the entire process that spawned the window.
The invocation of the form method can be a synchronous or asynchronous operation, but either way it has to be queued up to be run by the UI thread.
Here's a way to make calls from background threads SEEM like they're executed by the background thread, without violating cross-threading rules:
//in your form class
public new void Show()
{
if(!InvokeRequired)
base.Show();
else
this.Invoke((MethodInvoker)(()=>base.Show()));
}
Understand that you cannot deal with the form as its base class System.Windows.Form; it has to be the concrete form class you create. Otherwise the method hiding is ignored and the base implementation is used by default.
By setting it up this way, whenever an action might be about to run from a background thread, you avoid cross-threading operations. You can change this method to run asynchronously if desired by calling BeginInvoke() on the control instead of Invoke(), but as a call to Show() would normally run synchronously, I would stick with Invoke.
精彩评论