跨线程操作无效，即使使用 InvokeRequired

Question

我有一个带有自定义控件的表单。

我的表单中有一个方法：

private void SetEnabledOnControls(bool val)
{
  if (InvokeRequired)
  {
      Invoke((Action<bool>)SetEnabledOnControls, val);
  }
  else
  {
       //do the work - iterate over child controls, 
       //and they iterate over their children, etc...
  }
}

在 else 分支上的方法内，我得到了提到的异常：
跨线程操作无效：控制“txtNumber”是从创建它的线程以外的线程访问的。

我的场景实际上有点复杂 - 我只是以此作为示例进行推断。实际情况是，我正在使用 WorkflowFoundation - 我在 WorkflowApplication 中运行 StateMachineActivity (CTP1)（在它自己的线程中运行），我订阅了它的事件，然后从那里调用 SetEnabledOnControls。另外，我正在使用书签来恢复我的工作流程（而且，旁边还有 MEF，不参与该场景）。

所有这些都与我对 InvokeRequired 的明显误解无关 - 如果 InvokeRequired 为 false，我怎么可能出现跨线程异常？我不会“手动”创建任何控件 - 它全部位于设计者放置的 Initialize() 中。

有人能解释一下吗？

谢谢！

编辑 根据 GWLlosa 建议，我使用 System.Threading.Thread.CurrentThread.ManagedThreadId 跟踪了 ThreadId。现在出现了奇怪的部分...Initialize() 中的线程 ID 是 10。在传递前 2 个状态之间，它的 ID 为 13 - InvokeRequired 为 true，并且调用正确。但是，在第二个状态之后，当它进入 SetEnabledOnControls 时，它又是 13，但这次 InvokeRequired 为 false！怎么会！？当然，后来它无法更改子控件（这并不奇怪）。难道表单以某种方式改变了它所在的线程？

编辑2 现在我正在调用：

 if (IsHandleCreated)
 {
     Invoke((Action<bool>)SetEnabledOnControls, val);
 }

并且它的 IsHandleCreated 为 true，但仍然因 devSpeed 指向，否则不能在控件上调用。

编辑3 FACEPALM :) 恢复状态的按钮之一首先是表单的 CancelButton。当它从属性中删除时，codebihind 仍然有 DialogResult=Cancel - 所以我的表单确实正在关闭，当然它缺少句柄，因此 InvokeRequired 没有返回正确的信息，因此出现错误。

谢谢大家！我今天学到了新东西:)

Answer 1

如果在创建控件时（在 Initialize() 函数中）记录线程 ID 以及在尝试触摸控件之前记录线程 ID，可能会使调试更加容易。一般来说，当您以某种方式在线程上创建控件而不是您最初期望的线程时，我就看到过这种情况发生。

Answer 2

我自己也遇到了类似的问题，我拆除了一个函数，然后在 FlowLayoutPanel 中动态创建控件：

        public static void RenderEditorInstance(DataContext dataContext, object selectedItem, Form targetForm, Control targetControl, List<DynamicUserInterface.EditorControl> editorControls, EventHandler ComboBox_SelectedIndexChanged, EventHandler TextBoxControl_TextChanged, EventHandler CheckBox_CheckChanged, EventHandler NumericUpDown_ValueChanged, CheckedListControl.ItemChecked OnItemChecked, EventHandler dateTimePicker_ValueChanged, DynamicUserInterface.DuplicationValidationFailed liveLookupValidationFailed, DynamicUserInterface.PopulateComboBoxCallback populateComboBoxCallback)
        {           if (targetForm.InvokeRequired)
            {
                InstanceRenderer renderer = new InstanceRenderer(RenderEditorInstance);
                targetForm.Invoke(renderer, dataContext, selectedItem, targetForm, targetControl, editorControls, ComboBox_SelectedIndexChanged, TextBoxControl_TextChanged, CheckBox_CheckChanged, NumericUpDown_ValueChanged, OnItemChecked, dateTimePicker_ValueChanged, liveLookupValidationFailed, populateComboBoxCallback);
            }
            else
            {
                targetControl.Padding = new Padding(2);
                targetControl.Controls.Clear();

                ...{other code doing stuff here }
            }
         }

在使用此代码的大约 12 个实例中，引发了跨线程异常。使用此代码的所有实例都是以这样的方式编写的，即使用“await”关键字异步实现界面构建。

根据 GWLlosa 提出的建议，我为控件编写了一个扩展方法，以获取控件所属的 OwningThread：

    public static Thread OwnerThread(this Control ctrl)
    {
        Thread activeThread = null;

        if (ctrl.InvokeRequired)
        {
            activeThread = (Thread)ctrl.Invoke(new Func<Control, Thread>(OwnerThread), new object[] { ctrl });
        }
        else
        {
            activeThread = Thread.CurrentThread;
        }

        return activeThread;
    }

..这强调了经过几次迭代后，线程 ID 确实发生了变化。

这些代码的深处埋藏着一些例程，用于通过使用来自 MSDN (https://msdn.microsoft.com/en-us/library/hh195051(v=vs.110).aspx)明确指出：

该示例显示异步任务在不同的
线程比主应用程序线程

一旦从等式中取出 Task.Run()，控件的线程就永远不会改变。因此，您需要谨慎使用它的方式和时间！