Bug: await CoreDispatcher.RunAsync does not continue.

[sjb-sjb]

This item was identified in the discussion thread #2609.

WinUI documentation says that the CoreDispatcher can be obtained from any UI element (https://docs.microsoft.com/en-us/windows/winui/api/microsoft.ui.xaml.dependencyobject.dispatcher?view=winui-3.0-preview).

However, in a test of RunAsync the continuation did not execute.

Steps to reproduce: Install Visual Studio Version 16.9.0 Preview 2.0 with WinUI 3 Project Templates [Preview] version 3.0.0.2011130. Download and compile the Xaml Controls Gallery branch for WinUI 3 - Desktop (i.e. with the MSIX package). In ButtonPage.xaml.cs, add the following lines to the Button_Click method after the first line (and make the method async):

    System.Diagnostics.Debug.WriteLine("Dispatching....");
    await b.Dispatcher.RunAsync( Windows.UI.Core.CoreDispatcherPriority.Normal, () => { System.Diagnostics.Debug.WriteLine("Dispatched!"); }).AsTask();
    System.Diagnostics.Debug.WriteLine("Awaited.");

Expected: when you click the button it should print "Dispatching..." and "Dispatched" and "Awaited.".
Actual: When you click the button it prints "Dispatching..." and "Dispatched!" but not "Awaited". The continuation of the method after the "await" is not executed. Noting that the UI remains responsive, i.e. this does not seem to be a deadlock situation.

[sjb-sjb]

I tested this on the master branch of the Xaml Controls Gallery, which is a UWP app, and it does give the expected behavior i.e. the output includes "Awaited.". Consequently this is not a problem with the VS 16.9 preview compiler or environment, nor is there some kind of logic error. This increases the confidence that this is a WinUI 3 bug.

[huoyaoyuan]

Can you confirm this with WinUI3 UWP and desktop? This looks like a CsWinRT issue, which shouldn't repro for WinUI3 UWP.

[sjb-sjb]

I have run the following variants of Xaml Controls Gallery

(a) The WinUI 3 desktop branch with the XamlControlsGallery.Desktop.sln solution. This is WinUI 3 in a packaged desktop app. The test failed, the continuation didn't run (as indicated by "Awaited." not being printed).

(b) The WinUI 3 desktop branch with the XamlControlsGallery.sln solution. I guess this is a WinUI 3 UWP app, although I am not aware of that being a supported configuration. The test succeeded, the continuation ran and "Awaited." was printed.

(c) The master branch with the XamlControlsGallery.sln solution. This is a UWP app without WinUI 3; it uses Microsoft.UI.Xaml v 2.5.0. The test succeeded, the continuation ran and "Awaited." was printed.

As relates to CsWinRT, I upgraded Microsoft.Windows.CsWinRT to v 1.1.0 and also upgraded Microsoft.NET.Compilers.Toolset to 3.9.0-2.final, with no effect on (a).

This bug is hanging up my project, how can I get a fix for it ?

Steve

P.S. for both (b) and (c) I encountered a NuGet problem which I fixed using the method described in https://franckgaspoz.fr/en/how-to-solve-a-failure-of-nuget-restore-impossible-to-access-a-deleted-object-from-the-package-manager-of-visual-studio-2019/

[StephenLPeters]

@Scottj1s and @stevenbrix another cswinrt issue?

[stevenbrix]

No, this is a difference between Desktop and UWP. In Desktop apps, CoreDispatcher doesn't work, because there is no CoreWindow that owns the message pump. Instead, you need to use the DependencyObject.DispatcherQueue property. In fact, DependencyObject.DispatcherQueue will work in both UWP and Desktop, so it's recommended to always use that if you can

[sjb-sjb]

@stevenbrix, thanks, what you say here is consistent with @MikeHillberg’s comments in #2609.

In that case the Dispatcher property documentation in the WinUI documentation set (linked above) is wrong and should be deleted or modified. I would suggest that the Dispatcher property of DependencyObject also be modified to return null since it is pretty confusing that it returns an invalid (i.e. not usable) object.

Can you explain how to implement an equivalent of RunAsync using the DispatcherQueue only? The equivalence is not clear to me, because CoreDispatcher.RunAsync waits for the delegate to begin executing, while DispatcherQueue.TryEnqueue returns immediately. Is it as simple as adding in a TaskCompletionSource that is completed at the start of the delegate execution, or are there some tricks or subtleties involved?

P.S. What's a bit weird about this is that you can access the CoreDispatcher object and use it to dispatch a delegate onto the UI thread ... it just doesn't continue. I am not sure why the continuation part would be where it hangs up rather than the dispatching part.

[sjb-sjb]

Also, any thoughts on how to get an event similar to CoreDispatcher.AcceleratorKeyActivated, in the WinUI environment ?

Noting that in UWP at least you cannot use KeyUp for this because the system does not, for example, generate KeyUp for ALT key after the ALT key has been held down for a period of time.

[MikeHillberg]

@sjb-sjb, could you explain that last part? You're expecting to get a KeyUp while the key is still down?

[sjb-sjb]

No, what I meant was this: the accelerator key activated event occurs when the ALT key is pressed and then released, i.e. it occurs when the key is released. If you try to simulate this by trapping KeyDown and KeyUp, you will not succeed because if the ALT key is held down for a while then when it is released the KeyUp will not be generated. You will not be able to generate the simulated AcceleratorKeyActivated when the ALT key is released. Caveat, I am telling you this from memory of an experiment I did quite a while ago.

[marb2000]

@sjb-sjb There is not plan yet for introducing an event similar to CoreDispatcher.AcceleratorKeyActivated (ideally, there should be a DispatcherQueue.AcceleratorKeyActivated).

About this:

if the ALT key is held down for a while then when it is released the KeyUp will not be generated.
I tested this and it worked as expected. When pressing the ALT key, the KeyDown event was fired, and after pressing it for several seconds, I released the button, and the KeyUp event was fired. Was this your scenario?

[sjb-sjb]

I believe that the sequence was: ALT key down, alphabetic key down, alphabetic key up, then ALT up. One of the two key-ups was not generated when there was a pause in the sequence (either after the ALT down or after the alphabetic down). It was on UWP.

Anyway, I guess I'm asking for a documented replacement for CoreDispatcher.AccelratorKeyActivated.

[marb2000]

I do recommend to you to open a feature proposal for AcceleratorKeyActivated.

About your issue to implement ALT, perhpas you can do something like this:

myGrid.KeyDown += (sender, e) => {
     bool altDown = KeyboardInput.GetKeyStateForCurrentThread(VirtualKey.Menu).HasFlag(CoreVirtualKeyStates.Down);
     if (e.Key == VirtualKey.F4 && altDown)
    {
              // Do something
    }
};

[bpulliam]

Closing this issue as By Design.