System.Windows.Threading.DispatcherObject类(DependencyObject所基于的)包含一个有用的函数，称为CheckAccess()，它确定代码是否在UI线程上运行。
当我昨天想使用它时，我很困惑地发现Intellisense没有显示该功能(也没有VerifyAccess()，该功能在不在UI线程上时也会引发异常)，即使MSDN库列出了该功能。 我决定使用Reflector调查课程。 似乎该函数具有附加的EditorBrowsable(EditorBrowsableState.Never)属性。 Dispatcher使用的Dispatcher类具有与CheckAccess()和VerifyAccess()相同的属性：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
| 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中一些最有用的方法)呢？
微软的一名雇员最近表示，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案例可解决此缺点。 如果对您很重要，请投票。
我找不到任何说明您不应该直接使用这些方法的文档，但是我看起来并不长。
您还引用了不存在的EditorVisibleAttribute。 根据Reflector，它是EditorBrowsableAttribute。
反光镜拆卸：
1
2
3
4
5
| [EditorBrowsable(EditorBrowsableState.Never)]
public bool CheckAccess()
{
//CODE
} |
