WPF's Dispatcher.CheckAccess() missing in intellisense

[TobiasKnauss]

Today, I noticed that WPF's Dispatcher.CheckAccess() is not shown in intellisense.

https://github.com/dotnet/wpf/blob/main/src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public bool CheckAccess()
...
[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
public void VerifyAccess()
...

A possible reason is given in this answer on stackoverflow:

A Microsoft employee recently stated CheckAccess is used only for "advanced scenarios", so they hid it from Intellisense.

"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."

Is it still true?

I use CheckAccess() in scenarios like the following:

private void UpdateUI ()
{
  if (!m_Label.Dispatcher.CheckAccess ())
  {
    _ = m_Label.Dispatcher.BeginInvoke (UpdateUI);
    return;
  }
  m_Label.Background = ... ;

But today I also found https://stackoverflow.com/questions/43364132/why-does-wpfs-dispatcher-invoke-not-cause-a-deadlock-when-run-on-the-main-threa/43364665
and also found the code

public void Invoke(Action callback, DispatcherPriority priority, CancellationToken cancellationToken, TimeSpan timeout)
{
  ...
  // Fast-Path: if on the same thread, and invoking at Send priority,
  // and the cancellation token is not already canceled, then just
  // call the callback directly.

from this stackoverflow answer inside the Dispatcher.cs. Therefore, I think I could directly call Invoke() instead:

private void UpdateUI ()
{
  Dispatcher.Invoke (UpdateUI_Invoke);
}

private void UpdateUI_Invoke ()
{
  m_Label.Background = ... ;

Whatever is the better solution (comments are welcome), in every case should the remarks on https://learn.microsoft.com/en-us/dotnet/api/system.windows.threading.dispatcher.invoke be enhanced by some information that Invoke() is not self-blocking.

[miloush]

Is it still true?

Not sure what you are asking about. If whether the two members are still hidden from intellisense, then yes:

wpf/src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs

Lines 207 to 208 in d4bb347

	[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
	public bool CheckAccess()

wpf/src/Microsoft.DotNet.Wpf/src/WindowsBase/System/Windows/Threading/Dispatcher.cs

Lines 222 to 223 in d4bb347

	[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]
	public void VerifyAccess()

the remarks [should] be enhanced

Methods are not self-blocking by default (not even sure what that would mean), so I don't see the need to mention that, or any claim otherwise to refer to.

Dispatcher.Invoke and Dispatcher.BeginInvoke are not equivalent. The latter places the callback on the queue at Normal priority.

[TobiasKnauss]

Not sure what you are asking about. If whether the two members are still hidden from intellisense, then yes:

Thanks for your reply. I know that these members are still hidden. I was referring to the reason for hiding them. Is there still a reason for it? If not, they should be made visible again, which I would prefer.

Methods are not self-blocking by default (not even sure what that would mean), so I don't see the need to mention that, or any claim otherwise to refer to.

Let me explain with some more details:
IIRC, calling control.Invoke() on the UI thread in WinForms is self-blocking (meaning, it causes a dead-lock), because it adds a message on the message queue and synchronously waits for it to be processed, although the UI thread was called by the message queue and therefore no further messages can be processed until the current call has returned. Therefore, it was necessary there to check control.InvokeRequired first.
In WPF, Dispatcher.Invoke() obviously does not block, because it does exacly this required check itself. Calling Dispatcher.CheckAccess() is not necessary then, so I thought that this maybe was the reason to hide it.
However, the docs do not mention this improved behaviour compared to WinForms, so the typical user could not know that Dispatcher.CheckAccess() is obsolete in some scenarios where it was required in WinForms. This information about the internal way of operation should still be added in the remarks of Dispatcher.CheckAccess() and Dispatcher.Invoke().

[miloush]

Well nothing magically changed, there are as "advanced" as they used to be and the same reasons to hide them. As far as I can tell they were never visible. Also if they were to be hidden for C# users, then Never was the only option, as Advanced is visible by default for C# users.

That said, I am not a fan of hidden members and wouldn't object changing all Never to Advanced across the codebase.

Thank you for the perspective, I didn't realize that was the case for WinForms. Yet I think my argument stands. That's not a normal behavior for methods and it is the abnormality that should be documented (in WinForms) rather than in WPF. It's not mentioned either in Control.Invoke or in InvokeRequired so I would even feel it's a bug and should be fixed.

[TobiasKnauss]

That said, I am not a fan of hidden members...

Well, maybe that was the opinion of one or a couple of developers at that time, and maybe they would think differently about it today. I share your idea.

I didn't realize that was the case for WinForms. Yet I think my argument stands. That's not a normal behavior for methods

I think this behaviour is normal, just because of the way the message queue works: If it is busy processing a message, then it cannot process a subsequent message, but the called function exactly waits for that. Everyone with the same understanding of the message queue could come to the same conclusion. And this holds true for WPF, too. But in WPF, the Invoke() is smart enough to check this beforehand to avoid blocking and walk a shortcut instead. This shortcut is really great and I don't want to miss it, however, I think it circumvents the 'normal' behaviour and should be documented, especially since it is known otherwise from WinForms (https://stackoverflow.com/a/287150/2505186).

and it is the abnormality that should be documented (in WinForms) rather than in WPF

It would be great if WinForms' Control.Invoke() was improved in this way, but this likely is not going to happen anymore. It should be documented for WinForms and WPF.

[miloush]

That is a very WinForms-centric point of view, and people who didn't come to WPF from WinForms/Win32 wouldn't have such model in their mind. Note that the shortcut is only for the Send priority; for other priorities, it does enter a "nested loop" to process subsequent messages.

[TobiasKnauss]

I have done years of WinForms development and recently switched to WPF (there was no time for it before), so your view on my view might be true. But having a nested message loop in WPF does not feel like a 'natural' solution to me when there is already one in Windows. It's like silently working around a problem to avoid a deadlook that simply arises from the working principle of the message loop and threading in combination with GUI, and I still think this should be mentioned. ;-)