Warum sind DispatcherObject.CheckAccess() und VerifyAccess() vor Intellisense verborgen?

Question

Der System.Windows.Threading.DispatcherObject Klasse (welche DependencyObject basiert auf) enthält eine nützliche Funktion namens CheckAccess(), das bestimmt, ob der Code im UI-Thread ausgeführt wird oder nicht.

Als ich es gestern nutzen wollte, musste ich verwundert feststellen, dass Intellisense die Funktion nicht anzeigte (und auch nicht). VerifyAccess(), der eine Ausnahme auslöst, wenn er nicht im UI-Thread ist), obwohl die MSDN-Bibliothek ihn auflistet.Ich beschloss, die Klasse mit Reflector zu untersuchen.Es scheint, dass die betreffende Funktion eine hat EditorBrowsable(EditorBrowsableState.Never) Attribut, das damit verbunden ist.Der Dispatcher Klasse, die von verwendet wird DispatcherObject, hat das gleiche Attribut angehängt CheckAccess() Und 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();

    // ...
}

Ich glaube nicht, dass die Anwendung dieses Attributs zufällig (oder ein Scherz) ist, daher lautet meine Frage:Warum ist es da?Sollten diese Methoden nicht direkt aufgerufen werden?Warum sind sie es dann nicht? protected (oder internal, wie einige der nützlichsten Methoden im WPF)?

Answer 1

Ein Microsoft-Mitarbeiter kürzlich erklärt CheckAccess wird nur für „erweiterte Szenarien“ verwendet und daher vor Intellisense verborgen.

"CheckAccess und VerifyAccess wurden immer als nicht sichtbar gekennzeichnet, vielleicht respektierte IntelliSense es nicht.Zur Bestätigung können Sie Reflector verwenden.Die Idee hier ist, dass CheckAccess und VerifyAccess -Fortschrittsszenarien, die normale Entwickler nicht benötigen.

Ich denke jedoch, dass EditorBrowsablestate.advanced ein angemesseneres Niveau gewesen wäre. "

Für dieses Manko gibt es einen Microsoft Connect-Fall. Stimmen Sie dafür wenn es dir wichtig ist.

Answer 2

Ich kann keine Dokumentation finden, die besagt, dass Sie diese Methoden nicht direkt verwenden sollten, aber ich habe nicht lange gesucht.

Sie verweisen auch auf das EditorVisibleAttribute, das nicht existiert.Laut Reflector ist es das EditorBrowsableAttribute.

Demontage des Reflektors:

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