System.Windows.Threading.DispatcherObject类(DependencyObject基于该类)包含一个有用的函数CheckCheck()，该函数确定代码是否在UI线程上运行。

当我昨天想使用它时，我很困惑地发现Intellisense没有显示该函数(也没有显示VerifyAccess()，该函数在不在UI线程上时也会引发异常)，即使MSDN库列出了该函数。我决定使用Reflector调查课程。似乎该函数具有添加的EditorBrowsable(EditorBrowsableState.Never)属性。 DispatcherObject使用的Dispatcher类具有与CheckAccess()和VerifyAccess()相同的属性：

public abstract class DispatcherObject
{
    // ...

    [EditorBrowsable(EditorBrowsableState.Never)]
    public bool CheckAccess();
    [EditorBrowsable(EditorBrowsableState.Never)]
    public void VerifyAccess();

    // ...

    [EditorBrowsable(EditorBrowsableState.Advanced)]
    public Dispatcher Dispatcher { get; }
}

public sealed class Dispatcher
{
    // ...

    [EditorBrowsable(EditorBrowsableState.Never)]
    public bool CheckAccess();
    [EditorBrowsable(EditorBrowsableState.Never)]
    public void VerifyAccess();

    // ...
}

我不认为该属性的应用是随机的(或者是个玩笑)，所以我的问题是：为什么在那儿？那些方法不应该直接调用吗？那么为什么不对它们进行"保护"(或者"内部"保护，就像WPF中一些最有用的方法一样)？

解决方案

回答

我找不到任何文档说明我们不应该直接使用这些方法，但是我用了很长的时间。

我们还引用了不存在的EditorVisibleAttribute。根据Reflector，它是EditorBrowsableAttribute。

反光镜拆卸：

[EditorBrowsable(EditorBrowsableState.Never)]
public bool CheckAccess()
{
//CODE
}

回答

一位Microsoft员工最近表示，CheckAccess仅用于"高级方案"，因此他们将其隐藏在Intellisense中。

"CheckAccess and VerifyAccess have
  always been marked to be not visible,
  maybe IntelliSense wasn't respecting
  it.  You can use Reflector to confirm.
  The idea here is that CheckAccess and
  VerifyAccess are advances scenarios,
  that normal developers don't need.
  
  However, I do think that
  EditorBrowsableState.Advanced would
  have been a more appropriate level."

有一个Microsoft Connect案例可解决此缺点。如果对我们很重要，请投票。