.net-3.5 - edition - visual web developer 2008 download
¿Por qué DispatcherObject.CheckAccess() y VerifyAccess() están ocultos en Intellisense? (2)
La clase System.Windows.Threading.DispatcherObject
(en la que se basa DependencyObject
) 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 arroja una excepción cuando no está en el hilo de UI), aunque la biblioteca de MSDN lo enumera. Decidí investigar la clase usando Reflector. Parece que la función en cuestión tiene un EditorBrowsable(EditorBrowsableState.Never)
adjunto. La clase Dispatcher
, que es utilizada por DispatcherObject
, tiene el mismo atributo asociado 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), así que mi pregunta es: ¿por qué está ahí? ¿No deberían llamarse esos métodos directamente? Entonces, ¿por qué no están protected
(o internal
, como algunos de los métodos más útiles en el WPF)?
No encuentro ninguna documentación que diga que no debes usar esos métodos directamente, pero no he buscado mucho.
También se refiere a EditorVisibleAttribute, que no existe. Según Reflector, es el EditorBrowsableAttribute .
Desmontaje del reflector:
[EditorBrowsable(EditorBrowsableState.Never)]
public bool CheckAccess()
{
//CODE
}
Recientemente, un empleado de Microsoft indicó que CheckAccess se usa solo para "escenarios avanzados", por lo que lo ocultaron de Intellisense.
"CheckAccess y VerifyAccess siempre han sido marcados para no ser visibles, tal vez IntelliSense no lo respeta. Puede usar Reflector para confirmar. La idea aquí es que CheckAccess y VerifyAccess son escenarios avanzados, que los desarrolladores normales no necesitan.
Sin embargo, creo que EditorBrowsableState.Advanced habría sido un nivel más apropiado ".
Hay un caso de Microsoft Connect para este inconveniente. Vota por él si es importante para ti.