Edit Question - KnowledgeHub

Title Body

The System.Windows.Threading.DispatcherObject class (which DependencyObject is based on) contains a useful function, called CheckAccess() , that determines whether or not the code is running on the UI thread. When I wanted to use it yesterday, I was puzzled to find out that Intellisense didn't show the function (nor VerifyAccess() , which throws an exception when not on the UI thread), even though the MSDN library lists it. I decided to investigate the class using Reflector. It seems that the function in question has an EditorBrowsable(EditorBrowsableState.Never) attribute attached to it. The Dispatcher class, which is used by DispatcherObject , has the same attribute attached to CheckAccess() and 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(); // ... } I don't believe that the application of that attribute is random (or a joke), so my question is: why is it there? Should those methods not be called directly? Then why aren't they protected (or internal , like some of the most useful methods in the WPF)?

Tags (comma-separated) Cancel