Perché DispatcherObject.CheckAccess() e VerifyAccess() sono nascosti da Intellisense?

Question

IL System.Windows.Threading.DispatcherObject classe (che DependencyObject è basato su) contiene una funzione utile, chiamata CheckAccess(), che determina se il codice è in esecuzione o meno nel thread dell'interfaccia utente.

Quando ieri ho voluto usarlo, sono rimasto perplesso nello scoprire che Intellisense non mostrava la funzione (né VerifyAccess(), che genera un'eccezione quando non si trova nel thread dell'interfaccia utente), anche se la libreria MSDN lo elenca.Ho deciso di indagare sulla classe utilizzando Reflector.Sembra che la funzione in questione abbia un file EditorBrowsable(EditorBrowsableState.Never) attributo ad esso allegato.IL Dispatcher classe, utilizzata da DispatcherObject, ha lo stesso attributo allegato a CheckAccess() E 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();

    // ...
}

Non credo che l'applicazione di tale attributo sia casuale (o uno scherzo), quindi la mia domanda è:perché è lì?Questi metodi non dovrebbero essere chiamati direttamente?Allora perché non lo sono? protected (O internal, come alcuni dei metodi più utili nel WPF)?

Answer 1

Un dipendente Microsoft recentemente affermato CheckAccess viene utilizzato solo per "scenari avanzati", quindi lo hanno nascosto a Intellisense.

"CheckAccess e VerifyAccess sono sempre stati contrassegnati per non essere visibili, forse Intellisense non lo stava rispettando.Puoi usare Reflector per confermare.L'idea qui è che CheckAccess e VerifyAccess sono scenari di avanzamento, che gli sviluppatori normali non hanno bisogno.

Tuttavia, penso che l'editorBrowSableState.Advanced sarebbe stato un livello più appropriato ".

C'è un caso di Microsoft Connect per questa lacuna. Votalo se è importante per te.

Answer 2

Non riesco a trovare alcuna documentazione che dica che non dovresti usare questi metodi direttamente, ma non ho cercato molto a lungo.

Inoltre fai riferimento a EditorVisibleAttribute, che non esiste.Secondo Reflector è il EditorBrowsableAttribute.

Smontaggio del riflettore:

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