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

Question

这 System.Windows.Threading.DispatcherObject 类（其中 DependencyObject 基于）包含一个有用的函数，称为 CheckAccess(), ，它确定代码是否在 UI 线程上运行。

昨天想用的时候，很疑惑的发现Intellisense并没有显示这个功能（也没有 VerifyAccess(), ，当不在 UI 线程上时会引发异常），即使 MSDN 库列出了它。我决定使用 Reflector 来调查该类。看来该函数有一个 EditorBrowsable(EditorBrowsableState.Never) 附加到它的属性。这 Dispatcher 类，它被使用 DispatcherObject, ，具有相同的属性附加到 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

微软员工 最近表示 CheckAccess 仅用于“高级场景”，因此他们对 Intellisense 隐藏了它。

“ CheckAccess和verifyAccess始终被标记为看不见，也许Intellisense并不尊重它。您可以使用 Reflector 来确认。这里的想法是，校验和验证是正常开发人员不需要的进步场景。

但是，我确实认为EditorBrowsablestate.Advanced将是一个更合适的水平。”

Microsoft Connect 有一个针对此缺点的案例。 投票给它 如果这对你很重要的话。

Answer 2

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

您还引用了 EditorVisibleAttribute，它不存在。根据 Reflector 的说法，这是 编辑器可浏览属性.

反光罩拆解：

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