none
Why is Dispatcher.CheckAccess disabled in Intellisense? RRS feed

  • Question

  • If you're writing multithreaded apps in WPF, you frequently need to confirm whether you're executing on the same thread as the UI.  The appropriate methods for doing this are CheckAccess and VerifyAccess -- but both of those are marked as invisible to Intellisense:

        [EditorBrowsable(EditorBrowsableState.Never)]

    Why is that?  That seems like a brain-dead design decision to me, but astonishingly, it's been that way for going on three years now, and still hasn't been fixed.  Why hasn't MS changed this?  And are they planning to?

    Ken Smith
    Wednesday, February 18, 2009 8:14 AM

Answers

  • Hi,

    I searched earlier forum posts and came up with a response from Dwayne Need on this in this post: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/bd0e6f6c-cadd-48f1-8e1a-163c2f17e4ca/

    "CheckAccess and VerifyAccess have always been marked to be not visible, maybe IntelliSense wasn't respecting it.  You can use Reflector to confirm.  The idea here is that CheckAccess and VerifyAccess are advances scenarios, that normal developers don't need.

    However, I do think that EditorBrowsableState.Advanced would have been a more appropriate level."

    I think I'll open a bug on this and say what Dwayne said above.  Update: we've already got a bug open on it.  I think several people have hit this and rightly complained.

    Andre
    Friday, February 20, 2009 11:17 PM
    Moderator

All replies

  • Hi,

    I searched earlier forum posts and came up with a response from Dwayne Need on this in this post: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/bd0e6f6c-cadd-48f1-8e1a-163c2f17e4ca/

    "CheckAccess and VerifyAccess have always been marked to be not visible, maybe IntelliSense wasn't respecting it.  You can use Reflector to confirm.  The idea here is that CheckAccess and VerifyAccess are advances scenarios, that normal developers don't need.

    However, I do think that EditorBrowsableState.Advanced would have been a more appropriate level."

    I think I'll open a bug on this and say what Dwayne said above.  Update: we've already got a bug open on it.  I think several people have hit this and rightly complained.

    Andre
    Friday, February 20, 2009 11:17 PM
    Moderator
  • Thanks, appreciated.  I'm not sure about the significance of marking it as "Advanced", but it's not really that advanced: unless I'm missing something, and there's a better way to check whether the current thread can update the form, it's something you're almost certainly going to need if you ever want to write a multithreaded app in WPF.  (I guess it's as "advanced" as threading in WPF is.)
    Ken Smith
    Friday, February 20, 2009 11:21 PM
  • I write multithreaded WPF apps and I've never had to check. I always know whether a certain piece of code will be running on a thread other than the UI thread, and when it does, I use Dispatcher.BeginInvoke. Perhaps that's why they hid them.
    Controls for WPF, Windows Forms and Silverlight at http://www.divelements.co.uk
    Saturday, February 21, 2009 9:53 AM
  • Here's the thing ...

    It allows you to put the thread logic in the "called" method instead of the "calling" method.

    It also allows you to have one method instead of two ...
    IE
    DoSomethingToUI
    and
    InvokeDoSomethingToUI

    EX
    void DoSomethingToUI()
    {
       if(!Dispatcher.CheckAccess())
       {
          Invoke( ... );
          return;
       }

       ... do stuff to ui ...
    }
    Monday, December 14, 2009 1:56 PM
  • Hello! Probably, Microsoft doesn't want developers to use Dispatcher.CheckAccess(). Taking into account that all controls, including page, are created inside the UI thread, inside a page constructor the property Thread.CurrentThread.ManagedThreadId is the required UI thread identifier. We can use this fact it in the next way:

    using System;
    using Microsoft.Phone.Controls;
     
    namespace WindowsPhoneApplication1
    {
      public partial class MainPage : PhoneApplicationPage
      {
        private int _uiThreadID = -1;
     
        private bool IsUIThread
        {
          get { return _uiThreadID == System.Threading.Thread.CurrentThread.ManagedThreadId; }
        }
     
        // Constructor
        public MainPage()
        {
        // preserve UI thread id
          _uiThreadID = System.Threading.Thread.CurrentThread.ManagedThreadId;
          InitializeComponent();
        }
     
        public void UpdateSomeTextBox(string text)
        {
          if (IsUIThread) // if it's UI thread, just set the new text directly
            someTextBox.Text = text;
          else  // otherwise, invoke UpdateSomeTextBox in UI thread
            Dispatcher.BeginInvoke(delegate()
            {
              UpdateSomeTextBox(text);
            });
        }
      }
    }
    
    Thanks!

    .Net Follower (http://dotnetfollower.com)
    Tuesday, July 19, 2011 4:28 AM
  • As far as I'm concerned, there isn't any reason you should not call Dispatcher.CheckAccess, even though it doesn't show up in Intellisense.  Just because the method is marked as EditorBrowsable(Never) does not mean that Microsoft does not want you to use it -- it may simply be because of a bug in Visual Studio Intellisense.  See the documentation for Dispatcher.CheckAccess: http://msdn.microsoft.com/en-us/library/system.windows.threading.dispatcher.checkaccess.aspx.
    • Proposed as answer by Tony Sneed Tuesday, July 19, 2011 12:32 PM
    Tuesday, July 19, 2011 12:32 PM
  • I didn't test it yet in wpf, but in winfoms the CheckAccess-method (InvokeRequired) shouldn't be used, because it is slower to check if invoking is required than just doing it.

    Because this method is not visible, I think it's the same in WPF. Just invoking should be faster than checking for it.


    ecspand your SharePoint - Find out more at www.ecspand.com
    Monday, August 15, 2011 8:20 AM
  • Although a few years late, you might like to know the results of some timings using .Net 4.0 and WPF.  Since all were run on the same machine, memory, processor etc. should not influence the results. All measurements were taken after the first run to allow for jitting.

    Call to Invoke took between 289ns and 22,280ns.  (ns = nanoseconds)

    Call to CheckAccess took 8ns repeatedly.

    I always use check access with the following code:

    public static void InvokeOnUIThread(this System.Windows.Threading.Dispatcher uiDispatcher, Action task)
    {
    if (uiDispatcher == null || task == null)
    return;
    if (uiDispatcher.CheckAccess())
    task();
    else
    uiDispatcher.Invoke(task);
    }

    Tuesday, June 12, 2012 3:14 AM
  • How on earth has this still not been fixed even in .NET 4.5.1 and VS 2013 Preview... Like others have already said, this is a standard method that is used commonly for most people that are using multi threading in WPF apps (and surely using an extra thread to perform long running operations to keep the UI responsive is not THAT advanced and rare!?) so it is pretty annoying that it is hidden from intellisense. Is this ever going to be fixed? Surely it is an extremely simple and quick thing to fix and it can't really cause any problems

    My website (free apps I've written for IT Pro's) : www.cjwdev.co.uk My blog: cjwdev.wordpress.com

    Thursday, August 15, 2013 12:45 PM
  • it's mid 2015 and 2 years into VS2013 RTM, and this issue still exists.
    speaks volumes about how serious MS is about fixing customer issues.

    Also a hint of where wpf is going (...nowhere).

    Monday, June 22, 2015 3:46 AM
  • You know, so many things are async and Task.Run(() => { }) everywhere these days, to say that "this is an advanced concept, most developers are too stupid or don't need this" is stupid now. (Sept 2018)
    Wednesday, September 12, 2018 5:32 PM