losSystem.Windows.Threading.DispatcherObject clase (queDependencyObject se basa en) contiene una función útil, llamadaCheckAccess(), que determina si el código se está ejecutando o no en el subproceso de la interfaz de usuario.

Cuando quise usarlo ayer, me sorprendió descubrir que Intellisense no mostraba la función (ni tampocoVerifyAccess(), que lanza una excepción cuando no está en el subproceso de la IU), aunque la biblioteca de MSDN la incluya. Decidí investigar la clase utilizando Reflector. Parece que la función en cuestión tiene unaEditorBrowsable(EditorBrowsableState.Never) atributo que se le atribuye. losDispatcher clase, que es utilizada porDispatcherObject, tiene el mismo atributo adjunto aCheckAccess() yVerifyAccess():

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();

    // ...
}

No creo que la aplicación de ese atributo sea aleatoria (o una broma), entonces mi pregunta es: ¿por qué está ahí? ¿No deberían llamarse esos métodos directamente? Entonces porque no son ellosprotected (ointernal, como algunos de los métodos más útiles en el WPF)?