Why does Application.Current == null in a WinForms application?

Why does Application.Current come out to null in a WinForms application? How and when is it supposed to be set?

3 Answers 3

Application.Current is Specific for WPF Application. Therefore when you are using WPF controls in WinForms Application you need to initialize instance of WPF Application. Do this in your WinForms Application.

Based on this other SO question, Application.Current is a WPF feature and not a WinForm feature.

There is an MSDN post that shows how to leverage the feature in Winform by adding some references to your code:

you can add a reference to PresentationFramework first:

1.In Solution Explorer, right-click the project node and click Add Reference.

2.In the Add Reference dialog box, select the .NET tab.

3.Select the PresentationFramework, and then click OK.

4.Add «using System.Windows.Shell;» and «using System.Windows;» to your code.

Well IMHO opinion the other SO answer is not really the way to go for windows forms, although maybe not incorrect.

Normally you would use ISynchronizeInvoke for such a feature in WinForms. Every container control implements this interface.

You’ll need to BeginInvoke() method to marshall the call back to the proper thread.

Based on your previous question the code would become:

Where you pass the owning Form class to the constructor of SomeObject . The PropertyChanged will now raised on the UI thread of the owning form class.

Application.Current is null when calling from a unittest

I have a method that I’m trying to call from a unit test. This method will in real life be run from a background thread. It uses some code to kick off in the invoke updates to the UI thread (using Application.Current.Dispatcher.BeginInvoke . ).

However Application.Current is null when being called from the unit tests.

I don’t really what to put an if (Application.Current !=null) around everything to fix.

Is there any other way around this?

_statusUpdates is an ObservableCollection

Below is the part of the code in the method I’m looking to test (it is more of an integration test than a unit test to be fair).

5 Answers 5

As already stated, you simply won’t have an Application class during unit tests.

That said, there’s an issue here I think needs addressing — by having code that relies on a defined static property, in your case Application.Current.Dispatch , you are now very tightly coupled to the specific implementation of that class, namely the WPF Application class, where you do not need to be.

Even if you simply wrap the idea of «the current root dispatcher» in a Singleton -style class wrapper, now you have a way of decoupling yourself from the vagaries of the Application class and dealing directly with what you care about, a Dispatcher :

Note, there are MANY MANY ways to write this, I’m just putting up the simplest possible implementation; hence, I will not be doing any multithreaded safety checks, etc.

Ok, now this implementation is only slightly better than before, but at least you now have finer control over access to the type and are no longer strictly dependent on the existence of an Application instance.

Question: WinUI3 dispatchers (And why is Window.Current null in Desktop?) #2609

Comments

tomasfabian commented Jun 5, 2020

I wanted to create a Rx DispatcherScheduler for WinUI 3 Preview 1 based on UWP implementation, but the static readonly property Window.Current is null. How should I or the Rx team get the corresponding CoreDispatcher?

Steps to reproduce:

Steps to reproduce the behavior:

Create new Blank App, Packaged (WinUI in Desktop) app

Open MainWindow.xaml.cs and try get Window.Current

Expected behavior:

Window.Current in Blank App, Packaged (WinUI in UWP) returns a window instance

The text was updated successfully, but these errors were encountered:

Felix-Dev commented Jun 5, 2020 •

Your stated expected behavior (WinUI UWP) does not match your bug description (WinUI Desktop). Is that intended?

Window.Current only returns a window instance when called from a UI thread of a UWP app. In all other cases it returns null , including WinUI Desktop apps.

The CoreDispatcher is only available for UWP apps currently. Can you use the Dispatcher class from .NET instead?

tomasfabian commented Jun 5, 2020

@Felix-Dev sorry I probably confused you, I didn’t state that it’s a bug, it was just my expectation.

I tried to get the dispatcher from .NET as you kindly suggested me. This returned null:

but I was able to get the dispatcher like this:

I have to admit that I’m confused, because I checked that for example a text box returns a CoreDispatcher from it’s Dispatcher property:

I’m used from WPF that this is true:

Isn’t that CoreDispatcher confusing in WinUI Desktop apps, if it’s only used in UWP apps currently?

Thank you, Tomas

weltkante commented Jun 5, 2020 •

Your steps to reproduce are

But you say your expectation is

Packaged (WinUI in UWP) returns a window instance

As such you are mixing up UWP/Desktop packaging in your issue description and were asked to clarify which of them is actually your problem.

tomasfabian commented Jun 5, 2020

Packaged (WinUI in Desktop) app is my actual problem.
Packaged (WinUI in UWP) was an example how it could behave in Packaged (WinUI in Desktop), too.

tomasfabian commented Jun 5, 2020

Your stated expected behavior (WinUI UWP) does not match your bug description (WinUI Desktop). Is that intended?

Yes it was intended, but it is obviously confusing, sorry again.

So my main issue was to get the correct current dispatcher for switching from a background thread to the main UI thread. I wanted to use Window.Current.Dispatcher for that purpose in a Packaged (WinUI in Desktop) app, but it was null.

Felix-Dev commented Jun 5, 2020

@tomasfabian Interesting that you get a valid CoreDispatcher reference when accessing MyTextBox.Dispatcher in a WinUI Desktop app! I honestly thought a CoreDispatcher was related to a CoreWindow and as WinUI Desktop apps don’t have a CoreWindow (they directly use the classic HWND) I was under the impression that there won’t be a CoreDispatcher then for WinUI Desktop apps. If I’m wrong here and this caused you additional confusion I would like to apologize!

MikeHillberg commented Jun 5, 2020

In a UWP WinUI app there’s guaranteed to be one Window on the UI thread, because multiple windows aren’t supported. To create a second Window you need to create a new thread. So Window.Current returns the Window on the calling thread.

In a Desktop WinUI app, in the current preview only one Window can be created, but the plan is to allow multiple Windows to be created on the same thread. So Window.Current doesn’t make sense any longer, and now just returns null. (It’s behavior is unchanged in a UWP app.)

About dispatchers, CoreDispatcher only works in a UWP app, but DispatcherQueue always works. DispatcherQueue isn’t new to the WinUI preview, it’s been around for a while, but what is new in the preview is that Xaml elements (and Window) have a DispatcherQueue property so that you can get one for any element.

tomasfabian commented Jun 5, 2020 •

@Felix-Dev that’s alright. Your constructive explanation was actually very helpful for me to learn that there is another (not used?) core dispatcher in the Desktop version which misled me.

For all I’m going to change the title to WinUI 3 dispatchers (Why is Window.Current null?) if it’s not a problem for anyone.

I realize now, based on the information gathered by you, that my original question should be split to two issues (these issues are coupled via Dispatcher property):

1. Window.Current is not self explanatory in my opinion. @MikeHillberg explained to us that it produces different results in both platforms and the behavior in Desktop WinUI will probably change. What kind of behavior should we expect from MAUI integration (Android/iOS etc)?

Originally I used Window.Current only to get the dispatcher, but it was null (and of type CoreDispatcher).

1. It would be great to have a unified (cross-platform) dispatcher provider.
   I learnt that MyTextBox.Dispatcher is a CoreDispatcher used only in UWP, but the DispatchedHandler agileCallback passed to RunAsync was «suprisingly» called in the main thread.

@MikeHillberg DispatcherQueue is not new in WinUI, but it is new for new/adapting developers. Is this the way how to call DispatcherQueue?

How is it possible to get the «current» Dispatcher for ticks for example?

I wasn’t able to find this in the documentation.

How can SynchronizationContext.Current of the main thread become null in a Windows Forms application?

I have a problem in my application: At some point, the SynchronizationContext.Current becomes null for the main thread. I’m unable to reproduce the same problem in an isolated project. My real project is complex; it mixes Windows Forms and WPF and calls WCF Web Services. As far as I know, those are all systems that may interact with the SynchronizationContext.

This is the code from my isolated project. My real app does something that resembles that. However, in my real app the SynchronizationContext.Current is null on the main thread when the continuation task is executed.

What could cause the SynchronizationContext.Current of the main thread to become null?

Edit:

@Hans asked for the stack trace. Here it is:

3 Answers 3

Sly, I have run into the exact same behavior when a mixture of WPF, WCF, and TPL is used. The Main thread’s current SynchronizationContext will become null in a few situations.

According to this post on the msdn forums, this is a confirmed bug in the TPL in 4.0. A coworker is running on 4.5 and does not see this behavior.

We solved this by creating a TaskScheduler in a static singleton with the main thread using FromCurrentSynchronizationContext and then always reference that task scheduler when creating continuations. For example

This avoids the issue in the TPL on .net 4.0.

Update If you have .net 4.5 installed on your development machine, you will not see this issue even if you are targeting the 4.0 framework. Your users who only have 4.0 installed will still be affected.