¿Por qué DispatcherObject.CheckAccess() y VerifyAccess() están ocultos de Intellisense?

Question

El System.Windows.Threading.DispatcherObject clase (que DependencyObject se basa en) contiene una función útil, llamada CheckAccess(), que determina si el código se ejecuta 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 VerifyAccess(), que genera una excepción cuando no está en el subproceso de la interfaz de usuario), aunque la biblioteca MSDN lo incluya.Decidí investigar la clase usando Reflector.Parece que la función en cuestión tiene una EditorBrowsable(EditorBrowsableState.Never) atributo que se le atribuye.El Dispatcher clase, que es utilizada por DispatcherObject, tiene el mismo atributo adjunto a CheckAccess() y 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();

    // ...
}

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 ¿por qué no lo son? protected (o internal, como algunos de los métodos más útiles en WPF)?

Answer 1

Un empleado de Microsoft declarado recientemente CheckAccess se usa sólo para "escenarios avanzados", por lo que lo ocultaron de Intellisense.

"Comprobación y verificar el acceso siempre se ha marcado para no ser visible, tal vez Intellisense no lo respetó.Puede utilizar Reflector para confirmar.La idea aquí es que CheckAccess y VerifyAccess son escenarios de avances que los desarrolladores normales no necesitan.

Sin embargo, creo que EditorBrowsableState.Advanced habría sido un nivel más apropiado ".

Existe un caso de Microsoft Connect para esta deficiencia. vota por ello si es importante para ti.

Answer 2

No puedo encontrar ninguna documentación que diga que no deberías usar esos métodos directamente, pero no he buscado mucho.

También hace referencia al EditorVisibleAttribute, que no existe.Según Reflector es el EditorBrowsableAttribute.

Desmontaje de reflectores:

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