Learn Powershell | Achieve More

One of the biggest pain points when working with WPF and PowerShell is that everything is done on a single thread with the UI. This includes performing various activities related to events such as button clicking and selecting data. While an operation is being performed (especially a long running operation), you will most likely see the window appear to be hung and unable to be moved or really any sort of action similar to below:

So it might not look like much is happening here, and you would be right. The window is hung as it is loading up in the background. Sometimes it may show a Not Responding message, and other times (like now) it will not.  As I mentioned, this is due to only a single thread being used to handle both the UI and the operation, meaning that only one thing can be handled at a time. The longer the operation, the longer the the wait to even move the window some place else. Perhaps this isn’t too bad for some people, but if most people see this, they start to complain or believe something is wrong.

Usually, my solution for this has been to use many PSJobs along with an event watcher (Register-ObjectEvent) to check on each background PowerShell job and handle the data from each job when it completes. When the last job is finished and the event handler performs the last data update, it would then perform a cleanup by removing the last job and itself, thus freeing up resources. I have used this method or something similar to this in a few of my scripts and also my project: PoshPAIG. While this method does in fact do its job, it is prone to issues with the background jobs and as you can see from a previous post, it can be a pretty heavy operation. Also mentioned in that post was the use of background runspaces that you create to handle other operations.

Similar to PSJobs, background runspaces cannot access other variables between other runspaces, which is by design to prevent issues. The way around this is to use a thread safe collection, such as a synchronized hash table, which is what I plan on using in the following example as it will provide easier access to the WPF controls.

Display the UI

$syncHash = [hashtable]::Synchronized(@{})
$newRunspace =[runspacefactory]::CreateRunspace()
$newRunspace.ApartmentState = "STA"
$newRunspace.ThreadOptions = "ReuseThread"          
$newRunspace.Open()
$newRunspace.SessionStateProxy.SetVariable("syncHash",$syncHash)          
$psCmd = [PowerShell]::Create().AddScript({   
    [xml]$xaml = @"
    <Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        x:Name="Window" Title="Initial Window" WindowStartupLocation = "CenterScreen"
        Width = "600" Height = "800" ShowInTaskbar = "True">
        <TextBox x:Name = "textbox" Height = "400" Width = "600"/>
    </Window>
"@
 
    $reader=(New-Object System.Xml.XmlNodeReader $xaml)
    $syncHash.Window=[Windows.Markup.XamlReader]::Load( $reader )
    $syncHash.TextBox = $syncHash.window.FindName("textbox")
    $syncHash.Window.ShowDialog() | Out-Null
    $syncHash.Error = $Error
})
$psCmd.Runspace = $newRunspace
$data = $psCmd.BeginInvoke()

The first line is where I set up my synchronized hash table that will then be fed into the new runspace by using the SessionState.SetVariable() method on the new runspace object. This will set up the runspace to already know what that variable is and what might already be assigned to it. But, by using this sync’d hash table, it is now thread safe so we can manipulate the contents of the hash table in a different runspace.  You will notice that I decided to store the relevant controls to this hash table so they will be made available outside of the UI’s runspace.

I am also placing everything for the UI in its own runspace so I can have my console free to do whatever I wish. Keep in mind that even though the console is open to use while the UI is still running, if I close the PowerShell console, the UI will also close as well.

With the UI open, I still have access to my console or ISE to do whatever I need to do. The next step is to actually make the connection to the other runspace and push some data to my UI. Looking at my synchronized hash table, you can see each control that I decided to add to the hash table in the case that I need to manipulate it.

$syncHash

PS C:\Users\Administrator> $syncHash
Name                           Value                                          
—-                           —–                                          
TextBox                        System.Windows.Controls.TextBox                
Window                         System.Windows.Window
Error                          {} 

Now if you think that you can read the control for all of its information, you will be partially right.

$syncHash.Window

Not exactly the information you would want to be seeing while looking at the Window control. The reason for this is that we do not have ownership of this control in our current runspace. The owner of this control is in another thread.

For further proof, lets try to push some simple text to the textbox and see what happens.

$syncHash.TextBox.Text = 'test'

PS C:\Users\Administrator> $syncHash.TextBox.Text = ‘test’
Exception setting “Text”: “The calling thread cannot access this object
because a different thread owns it.”
At line:1 char:1
+ $syncHash.TextBox.Text = ‘test’
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   + CategoryInfo          : NotSpecified: (:) [], SetValueInvocationExceptio
  n
   + FullyQualifiedErrorId : ExceptionWhenSetting

So how does on get around this issue? The answer lies within the Dispatcher object for each control. This object allows you to access the object while it is in a different thread to manipulate it (in this case, push data to the UI). Using the Invoke() method of the dispatcher object and supplying 2 parameters (Callback, DispatcherPriority). The callback is a delegate that you can assign a script block that contains the code you want to run against the UI through the dispatcher. The Dispatcher Priority tell what the priority of the operation should be when the Dispatcher is used. In most cases, using ‘Normal’ should be enough. The table below lists the possible priorities that can be used.

Ok, enough talk about this and lets finally see this in action! For my example, I am going to simply change the background color of the Window to Black while the UI is open and from a different runspace.

$syncHash.Window.Dispatcher.invoke(
    [action]{$syncHash.Window.Background='Black'},
    "Normal"
)

And there you have it! Easily modify the UI from another runspace with no effort at all!

Function to Push Data to UI in a Different Runspace

Function Update-Window {
    Param (
        $Title,
        $Content,
        [switch]$AppendContent
    )
    $syncHash.textbox.Dispatcher.invoke([action]{
        $syncHash.Window.Title = $title
        If ($PSBoundParameters['AppendContent']) {
            $syncHash.TextBox.AppendText($Content)
        } Else {
            $syncHash.TextBox.Text = $Content
        }
    },
    "Normal")
}

This function is just a simple function that I can use to append or overwrite whatever happens to the in the text box. It uses the same method that I showed above with changing the Window’s background color, but instead of using the Window’s dispatcher, I am now using the Textbox’s dispatcher object to perform the operations.

Manipulate the UI From a Different Runspace

Update-Window -Title ("Services on {0}" -f $Env:Computername) `
              -Content (Get-Service | Sort Status -Desc| out-string)

Very cool! I was able to run Get-Service from my ISE and take the output from the cmdlet and write it to my textbox. Given, this is a very simple demo, but you can make this as complex as needed for UIs that have more moving parts. You could even use this as a debugging method to write out all Verbose and Debug statements from your scripts or functions out to another window if you wanted to.

Summary

So I have now shown you how you can share data between runspaces that can make building UIs much simpler, especially when it comes to long running jobs. Using a synchronized hash table and then supplying that to another runspace gets you setup for working between runspaces and then using the Dispatcher object on each control gets you ability to actually write to the controls. Personally, I think this is a huge leap forward for writing UIs as it now allows you to off load operations to another runspace while keeping your main window free to move or do whatever you want with it. I am very much looking forward to expanding on this and seeing what else I can do.

In my case, this is the next step in evolution for both of my projects: PoshPAIG and PoshChat that will rely less on a timer object to help handle data and message traffic to being able to directly write to a control from another runspace. I hope to see what you will do with this in your UI builds in the future!