クラスSystem.Windows.Threading.DispatcherObject
(に基づいています) には、コードが UI スレッドで実行されているかどうかを判断する とDependencyObject
呼ばれる便利な関数が含まれています。CheckAccess()
昨日、これを使おうとしたとき、VerifyAccess()
MSDN ライブラリにリストされているにもかかわらず、Intellisense に関数 (および UI スレッド上にない場合は例外をスローする ) が表示されないことを発見し、困惑しました。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 の最も便利なメソッドのいくつかのように) 呼び出されないのですか?
ベストアンサー1
マイクロソフトの社員最近述べたCheckAccess は「高度なシナリオ」にのみ使用されるため、Intellisense からは非表示になっています。
「CheckAccess と VerifyAccess は常に非表示としてマークされていますが、IntelliSense がそれを尊重していなかった可能性があります。Reflector を使用して確認できます。ここでの考え方は、CheckAccess と VerifyAccess は高度なシナリオであり、通常の開発者には必要のないということです。
ただし、EditorBrowsableState.Advanced の方が適切なレベルだったと思います。」
この欠点については、Microsoft Connect のケースがあります。投票してくださいそれがあなたにとって重要なら。