为什么 DispatcherObject.CheckAccess() 和 VerifyAccess() 对 Intellisense 隐藏？

Question

System.Windows.Threading.DispatcherObject 类（DependencyObject 的基础）包含一个有用的函数，称为 CheckAccess()，它确定代码是否在 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();

    // ...
}

我不相信该属性的应用是随机的（或玩笑），所以我的问题是：它为什么会存在？不应该直接调用那些方法吗？那为什么它们不是protected（或internal，就像WPF 中一些最有用的方法）？

Answer 1

Microsoft 员工 recently statedCheckAccess 仅用于“高级场景”，因此他们对 Intellisense 隐藏了它。

"CheckAccess 和 VerifyAccess 有 总是被标记为不可见， 也许 IntelliSense 不尊重 它。您可以使用 Reflector 来确认。 这里的想法是 CheckAccess 和 VerifyAccess 是高级场景， 普通开发者不需要的。

但是，我确实认为 EditorBrowsableState.Advanced 将 已经是更合适的水平了。”

有一个 Microsoft Connect 案例可以弥补这个缺点。 Vote for it 如果对您很重要。

Answer 2

我找不到任何说明您不应该直接使用这些方法的文档，但我没看很久。

您还引用了 EditorVisibleAttribute，它不存在。根据 Reflector 的说法，它是 EditorBrowsableAttribute。

反光板拆解：

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