Pourquoi DispatcherObject.CheckAccess() et VerifyAccess() sont-ils masqués dans Intellisense?

Question

La classe System.Windows.Threading.DispatcherObject (sur laquelle DependencyObject est basé) contient une fonction utile, appelée CheckAccess(), qui détermine si le code s'exécute ou non sur le thread d'interface utilisateur. Quand j'ai voulu l'utiliser hier, j'ai été intrigué pour découvrir que Intellisense n'affichait pas la fonction (ni VerifyAccess(), qui lève une exception quand il n'était pas sur le thread UI), même si la librairie MSDN le répertorie. J'ai décidé d'étudier la classe en utilisant Reflector. Il semble que la fonction en question ait un attribut EditorBrowsable(EditorBrowsableState.Never) attaché. La classe Dispatcher, qui est utilisé 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 est aléatoire (ou une blague), donc ma question est : pourquoi est-ce là? Ces méthodes ne devraient-elles pas être appelées directement? Alors pourquoi ne sont-ils pas protected (ou internal, comme certaines des méthodes les plus utiles dans le WPF)?

Answer 1

Un employé de Microsoft recently stated de CheckAccess est utilisé uniquement pour "scénarios avancés", afin qu'ils l'a caché de IntelliSense.

« CheckAccess et VerifyAccess ont toujours été marquées ne pas être visible, peut-être IntelliSense ne respectait pas les il. Vous pouvez utiliser réflecteur pour confirmer. L'idée ici est que CheckAccess et VerifyAccess sont des scénarios d'avances , que les développeurs normaux ne ont pas besoin.

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

Il existe un cas de Microsoft Connect pour cette lacune. Vote for it si c'est important pour vous.

Answer 2

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

Vous faites également référence à EditorVisibleAttribute, qui n'existe pas. Selon Reflector c'est le EditorBrowsableAttribute.

démontage du réflecteur:

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