Windows On A Different Thread

Introduction

This is a helpful solution if you want to dive deeper into multithreading windows using WPF. I hope it helped you understand how to develop Windows in a different thread and sort of situation which you need to figure out. You can use it for your own purposes and even bind more complex logic to your window which runs in different threads.

Plan

Purpose and problem description
Annoying while trying to find the right solution and meanwhile solution
Good idea with a custom window and final solution
Summarize
Links and greetings

Purpose and Problem Description

I’m an experienced WPF/.NET developer. And everyone who works with that amazing technology knows that there are a lot of backside things which unfortunately don’t have right or good solutions. I’d like to tell you about this kind of exceptional case.

This time, I was developing a desktop application and on the right top of the working window, I have to put the EKG gif (The Graphics Interchange Format, which is by simple words just animated image). This EKG should show you that the application doesn’t stick, that it’s alive, and gives a good feeling to the user who is working with it.

So, before, I had some experience with that kind of apps. Of course, I implemented everything together, don’t mind and sometimes it stuck.

A little step to left. When you work with a big amount of data in WPF that kind things unfortunately happen. Because, when you are sending data to the UI the WPF-renderer at the moment stuck and all your live objects stopped moving, which makes a bad impression for users. Of course, there are existing solutions, that can work for your needs for some point: you can send it partially (old school solution using BackgroundWorker), using virtualization (which is also far from an ideal solution), and so on. Always controlling these things is annoying me, I’d say.

That’s why I started to think on some better solution which could make this EKG animation works totally independent from the rest of app processes. Finally, I found it, but on my way, I met a lot of difficulties and showstopper cases.

Annoying trying to find the right solution and meanwhile solution

Yes, my decision was to make it running on a different thread. You know it is easy with the backend process but isn’t so on UI. In WPF starts with two threads: one for handling rendering and another for managing the UI. The rendering thread effectively runs hidden in the background while the UI thread receives input, handles events, paints the screen, and runs application code. The WPF-applications use a single UI thread, although in some situations it is not the best solution.

First of all, I wasn’t sure if this is a really good way, but when I’m starting something new which I’m not sure I always say to myself that this is programming and there is everything is possible.

So, I started with running a new window, but you can’t write just a new Window() (because it will run in the same thread), you should run it in a different one, specially dedicated thread. The solution didn’t make me wait:

internal void MakeEkgOnDifferentThread()
{
try
{
Thread newWindowThread = new Thread(new ThreadStart(ThreadStartingPoint));
newWindowThread.SetApartmentState(ApartmentState.STA);
newWindowThread.IsBackground = true;
newWindowThread.Start();
}
catch (Exception ex)
{
// logging it
}
}
private void ThreadStartingPoint()
{
try
{
EkgController = new EkgController();
EkgController.Show();
System.Windows.Threading.Dispatcher.Run();
}
catch (Exception ex)
{
// logging it
}
}

I have authentication in my app and I call the method MakeEkgOnDifferentThread() right after a successful login. From this time the Other thread window is running in other thread and it will not be stuck even if you will call something like Thread.Sleep(5000) in your main app. This is exactly what we need, but there are a lot of “underwater stones”, mostly with UI part and user feelings from using the app.

My WPF application designed for adaptive layout, you can maximize or change the size of the window how you want, or moving it from place to place. In the window, by design, I have also place for EKG, the user should see it through all app lifecycle. From the information above you can understand that EKG-window should be glued to the main window. This wasn’t a big problem to resolve. I was subscribed to main window events StateChanged, LocationChanged, SizeChanged.

I made 2 help methods, which will return you real window coefficient for calculating real width and height (also depends on which screen you use (in case of multiple connected screens), which scaling settings you have set in windows settings (very often for HD 125% and for 4k 200 or 150%), etc.),

internal static double GetWindowsScalingWidth()
{
return Screen.PrimaryScreen.Bounds.Width / SystemParameters.PrimaryScreenWidth;
}
internal static double GetWindowsScalingHeight()
{
return Screen.PrimaryScreen.Bounds.Height / SystemParameters.PrimaryScreenHeight;
}

FYI: In the main window view I use the Grid to make a layout markup. And I put the Grid with name GridForOtherThreadWindow where I’d like to see the EKG-Window. And I decided to wrap the EKG-window to some controller class EkgManager which will handle my window and keep some settings there, just for comfort.

Below is the method that I will call a lot of times when events StateChanged, LocationChanged, SizeChanged will be invoked. This method defines the position of the EKG-window,

private void GetEkgSettings()
{
if (EkgManager.Current == null) return;
var content = (FrameworkElement)this.GridForOtherThreadWindow;
var currentPosition = content.PointToScreen(new Point(0, 0));
var widthFactor = MainWindow.GetWindowsScalingWidth();
var heightFactor = MainWindow.GetWindowsScalingHeight();
EkgManager.Current.Settings["Left"] = currentPosition.X / widthFactor;
EkgManager.Current.Settings["Top"] = currentPosition.Y / heightFactor;
EkgManager.Current.Settings["Width"] = content.ActualWidth * widthFactor;
EkgManager.Current.Settings["Height"] = content.ActualHeight * heightFactor;
EkgManager.Current.WindowSettingsChanged();
}
// EkgController is our target EKG-window managed from EkgManager.
internal void WindowSettingsChanged()
{
try
{
if (EkgController == null) return;
EkgController.Dispatcher.Invoke(() => UpdateWindowSettings());
}
catch (Exception ex)
{
// log it
}
}
private void UpdateWindowSettings()
{
EkgController.Width = Settings["Width"];
EkgController.Height = Settings["Height"];
EkgController.Left = Settings["Left"];
EkgController.Top = Settings["Top"];
}

Here we are. Ready to go deeper and see what happens when event LocationChanged is invoked?

private void WindowLocationChangedHandler(object sender, EventArgs e)
{
GetEkgSettings();
}

Go to the next one SizeChanged. But be careful, it will not work properly if you will subscribe to the event of your Main Window SizeChanged.

You should subscribe on the event of your container (Grid, StackPanel, whatever) which holds your content, that’s why I named it as Content SizeChanged.

private void ContentSizeChanged(object sender, SizeChangedEventArgs e)
{
GetEkgSettings();
}

For now, it looks pretty easy, doesn’t it?

Implementing handlers for LocationChanged and SizeChanged events let us stick our other thread window to the main window. But we also want to see it above our main window. And in this case, TopMost property helps us to implement it. Just set it is true and you will get the needed result. Of course, I will not remind you about it if all has been done without trouble.

The most interesting part is coming here when we implement handler for the StateChanged event. You should make it because, in case of minimizing your Main Window, the Ekg-Window will not be minimized. And this isn’t only one bad thing which happens. Your Main Window will not restore back anymore, because Windows OS somehow thinks that it is already restored because of visible Ekg-Window. So, for this reason, I implemented a handler for StateChanged event and I’d like to minimize my window I’m killing the Ekg-window and after restoring creating it again. Believe me, this works fine solution (Maybe, you will find better, describe it in comments). Also, one more reason to use wrapper for another thread window. Here is the implementation:

private void MainRootStateChanged(object sender, EventArgs e)
{
if (this.WindowState == WindowState.Minimized)
{
// remove ekg
if (EkgManager.Current == null) return;
EkgManager.Current.KillEkg();
}
else
{
// make ekg
if (EkgManager.Current != null && EkgManager.Current.EkgController != null) return;
EkgManager.Current.MakeEkgOnDifferentThread();
if (this.WindowState != WindowState.Maximized)
{
// this is some trick for refreshing main window, as I said before WPF and Windows
// management there isn’t ideal.
Task.Run(() =>
{
Thread.Sleep(1000);
this.Dispatcher.Invoke(() =>
{
this.Left += 0.1;
});
});
}
}
}
internal void KillEkg()
{
try
{
EkgController.Dispatcher.Invoke(DispatcherPriority.ApplicationIdle, new ThreadStart(() =>
{
EkgController.Close();
if (EkgController != null)
{
EkgController.Dispose();
}
}));
EkgController = null;
}
catch (Exception ex)
{
// log it
}
}

After these tricks, I’d be sure that I was on the right way. And here is coming one more problem related to TopMost property of Ekg-window. Of course, somehow you should manage it when you switching between windows. Because, if not – your ekg-window will be above others.

As a rule, all that happened in our app should be related to Main Window and in this case, we need to play with Activated and Deactivated events. The main idea was to play with property TopMost of Ekg-window when Main Window activated or deactivated. For this purpose, I made two methods on EkgManager which set TopMost to true, and to false depends on MainWindow IsActive property changed. Here is some piece of code:

internal void WindowActivated()
{
try
{
if (EkgController == null) return;
if (EkgController.Dispatcher.CheckAccess())
{
EkgController.Topmost = true;
}
else
{
EkgController.Dispatcher.Invoke(DispatcherPriority.ApplicationIdle, new ThreadStart(() =>
{
EkgController.Topmost = true;
}));
}
}
catch (Exception ex)
{
// log it
}
}

It was not working fine for me. When I was clicking between other app windows, very often Ekg-window still appeared above them and didn’t hide. I said, okay, let’s try to manage it from native functions provided by User32.dll. I imported “SetWindowPos” function and played with it. From the first few tests it seemed like a working solution, but finally, I went to similar problems and I’d like to ask Microsoft corp.: “WTF with it?”.

Meanwhile, I also wanted to resolve the issue with visibility Ekg-window from Task Manager. Every window in WPF has the property ShowInTaskbar, which when you set to false will hide your window from Processes tab in Task Manager, but in Details tab there you still able to find it which I didn’t want to. Here is some trick which helped me totally hide it, and here is User32 helped me. Below is a listing of class OtherThreadWindowBase which Ekg-window inherits:

public class OtherThreadWindowBase : Window, IDisposable
{
private const int GWL_EXSTYLE = -20;
private const int WS_EX_TOOLWINDOW = 0x00000080;
internal WindowInteropHelper _wndHelper;
public OtherThreadWindowBase()
{
this.Loaded += OtherThreadWindowBase_Loaded;
}
private void OtherThreadWindowBase_Loaded(object sender, RoutedEventArgs e)
{
_wndHelper = new WindowInteropHelper(this);
int exStyle = GetWindowLong(_wndHelper.Handle, GWL_EXSTYLE);
SetWindowLong(_wndHelper.Handle, GWL_EXSTYLE, exStyle | WS_EX_TOOLWINDOW);
}
[DllImport("user32.dll")]
internal static extern int SetWindowLong(IntPtr window, int index, int value);
[DllImport("user32.dll")]
internal static extern int GetWindowLong(IntPtr window, int index);
public void Dispose()
{
try
{
this.Loaded -= OtherThreadWindowBase_Loaded;
GC.Collect();
GC.WaitForPendingFinalizers();
}
catch (Exception ex)
{
// log it
}
}
}

So, we are happy with a lot of useful things, but still here is a problem with appearing EKG above other app windows. I understood, that keeping TopMost property of the Ekg-window set in true is a troublemaker solution. Let’s look at the solution what I did to resolve this problem in the next paragraph.

Finally, a good idea with custom window

The right solution was lying on the top. This is making the custom window (Main Window). I will not describe all subtleties of the creation custom window in WPF (because it could get the place for a separate story if you want you can add the questions related to comments or just review how it implemented in the attached sources), but I’ll describe the most important goals of it.

Default Window has property AllowsTransparency, but you can set it to true only when other property WindowStyle set to None, in other words, it will not work. WindowStyle property is setting the style of the window which defines the top-buttons - minimize, maximize and close the window and providing you the title with an icon if defined. As you understand, here is a key, but I can’t publish the app without title and top-buttons. If you need to mix these properties, you should define your own window style and related behavior, which is what I did.

How did this all behave on my solution? I made the background of my custom window transparent and I colored different pieces of the window to the background which I need, but that one piece which I named GridForOtherThreadWindow kept transparent. And I modified the handlers for methods Activated and Deactivated related to Main Window. Deactivated handler I removed, cause you don’t need it anymore and Activated modified,

private void MainRootActivated(object sender, EventArgs e)
{
if (EkgManager.Current == null) return;
EkgActivator();
}
private void EkgActivator()
{
if (EkgManager.Current == null) return;
EkgManager.Current.WindowActivated();
}
internal void WindowActivated()
{
try
{
if (EkgController == null) return;
if (EkgController.Dispatcher.CheckAccess())
{
EkgController.Topmost = true;
EkgController.Topmost = false;
EkgController.Focus();
}
else
{
EkgController.Dispatcher.Invoke(DispatcherPriority.ApplicationIdle, new ThreadStart(() =>
{
EkgController.Topmost = true;
EkgController.Topmost = false;
EkgController.Focus();
}));
}
}
catch (Exception ex)
{
// log it by your favorite logger
}
}

As you can see above, I just setting Ekg-window TopMost property to true for appear the Ekg-window above other app-windows and setting it back to false which returns it back to our main window, but above of 3d party app-windows, and we still can see the Ekg because it located in our transparent peace of Main Window.

We are almost done, but one more thing, when the app is starting and you switched to a different window which makes the main window deactivated then Ekg-Window appearing above of 3d party app-window. I resolved this issue by the trick – when window loaded (in my case you successfully login to the system) I’m setting TopMost to true and back for Main Window also and as a result, everything appears above other all windows, which you could see in the behavior of the different apps and it will not take questions from users, because it seems like normal.

Summary

This is a helpful solution if you want to dive deeper into multithreading windows using WPF. I hope it helped you understand how to develop Windows in different threads and sort of situation which you need to figure out. You can use it for your own purposes and even bind more complex logic to your window which runs in different threads. You need to use Dispatcher if you want to communicate between these windows. For my apps, I also use this kind solution for showing a busy indicator (progress ring) or for “notification” progress bar.

I will be glad to get all of your thoughts and advice to improve this solution, don’t hesitate to describe negative opinions or your own experiences.

Links and greetings

Threading model
How to create custom window chrome in WPF?
Custom WPF Window with Windows System Functionality Restored
Also, thanks to StackOverflow, C# Corner, Code project, and WPF/.NET developers’ communities.