Pourquoi DispatcherObject.CheckAccess() et VerifyAccess() sont-ils cachés d'Intellisense ?

Question

Le System.Windows.Threading.DispatcherObject classe (qui DependencyObject est basé sur) contient une fonction utile, appelée CheckAccess(), qui détermine si le code s'exécute ou non sur le thread de l'interface utilisateur.

Quand j'ai voulu l'utiliser hier, j'ai été perplexe de découvrir qu'Intellisense n'affichait pas la fonction (ni VerifyAccess(), qui lève une exception lorsqu'il n'est pas sur le thread de l'interface utilisateur), même si la bibliothèque MSDN la répertorie.J'ai décidé d'enquêter sur la classe en utilisant Reflector.Il semble que la fonction en question ait un EditorBrowsable(EditorBrowsableState.Never) attribut qui lui est attaché.Le Dispatcher classe, qui est utilisée par DispatcherObject, a le même attribut attaché à CheckAccess() et 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();

    // ...
}

Je ne crois pas que l'application de cet attribut soit aléatoire (ou une blague), donc ma question est la suivante :pourquoi est-il là ?Ces méthodes ne devraient-elles pas être appelées directement ?Alors pourquoi ne le sont-ils pas protected (ou internal, comme certaines des méthodes les plus utiles de WPF) ?

Answer 1

Un employé de Microsoft a récemment déclaré CheckAccess n'est utilisé que pour les "scénarios avancés", ils l'ont donc caché à Intellisense.

"CheckAccess et VerifyAccess ont toujours été marqués pour ne pas être visibles, peut-être que Intellisense ne le respectait pas.Vous pouvez utiliser Reflector pour confirmer.L'idée ici est que CheckAccess et VerifyAccess sont des scénarios Advances, dont les développeurs normaux n'ont pas besoin.

Cependant, je pense que EditorBrowsableState. Advanced aurait été un niveau plus approprié. "

Il existe un cas Microsoft Connect pour cette lacune. Votez pour si c'est important pour toi.

Answer 2

Je ne trouve aucune documentation indiquant que vous ne devriez pas utiliser ces méthodes directement, mais je n'ai pas cherché très longtemps.

Vous faites également référence au EditorVisibleAttribute, qui n’existe pas.Selon Reflector, c'est le ÉditeurBrowsableAttribute.

Démontage du réflecteur :

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