I got the following query in one of my Google hits today: "pipeline.Invoke() "Read-Host" Cannot invoke this function because the current host does not implement it."

I believe that this query was in reference to the lack of host functionality in the default settings for a runspace in Windows Powershell. I don't recall ever actually taking much about this, yet I am known for having abstracted the runspace API for use as a multi threading interface in Powershell. Now is a good time to talk some about this.

A runspace in Powershell is a big blob of information that pertains to a particular shell within Powershell. The runspace has several components within it, such as the cmdlets, aliases, functions, providers, etc. The host component specificly is ment to be used as an abstract interface to the console. The default host object used by a runspace doesn't have much functionality, so you may encounter error messages like the one above when you are using a generic host object.

It is possible to tell Powershell what host object should be used when the runspace is initialized. I do know that version 1.0 of powershell.exe will use a host that writes to the console used by the powershell.exe process. Since most other instances of Powershell don't have a console the host object will often be the default host object, that doesn't provide any functionality on its own, or a very simple host object, using only implementing a few methods in the PSHostUserInterface class.

From the query above it looks like this googler was trying to use Read-Host within an asynchronous runspace. The easy solution to this is to just not do so. It's easier, in most cases, to simply pass the needed information into the asynchronous runspace from the parent runspace. However, there are still some cases where you must use Read-Host from an asynchronous runspace. In that case you'll have to code and compile your own host class, and use that when initializing the runspace.

Write-EncryptedString message secret -gnupg

Write-EncryptedString message -gnupg

Write-EncryptedString message -gnupg -recipient 'John Doe'

powershell.exe -command "Invoke-PoshUri ([Environment]::CommandLine -replace '^.*?#{3}(.*)#{3}.*?$' , '$1'); return ###%1###"

After writing my last post I realized that I didn't have a script that would simplify the process of generating event handlers down to a single line task.

I quickly wrote a script that wraps C# method code into a delegate. The script allows delegates of any signature to be created. The result has four parameters, three of witch have default values, and only 17 lines of actual code. This script should be fairly easy to use.

The default values are set to use the EventHandler delegate. I chose this type of delegate because Powershell script blocks can be cast to EventHandler. I wanted to be able to easily generate a compiled delegate and be able to combine it with a script block.

Get-CDelegate.ps1

Here is an example of its use.

PS> $handler = Get-CDelegate 'Console.WriteLine("Hello world!");'
PS> $handler.Invoke($null,$null)
Hello world!

Simple! Right? Think of the compiled delegate as if it were a script block that runs really fast.

You can also make delegates of different types.

PS> $callback = Get-CDelegate 'Console.WriteLine("Hello world!");' -DelegateType AsyncCallback -Signature void, IAsyncResult

Here's the cool part. Combine a script block with an event handler to make a new event hander.

PS> $eh1 = get-cdelegate 'Console.WriteLine("Compiled EventHandler!");'
PS> $eh2 = [eventhandler]{write-host 'ScriptBlock!'}
PS> $eh3 = [delegate]::combine($eh1, $eh2)
PS> $eh3.invoke($null,$null)
Compiled EventHandler!
ScriptBlock!

There is also a using parameter. Add any namespaces that you want to use there. The default is 'System'.

Now, take it, have it, play with it, enjoy it, and remember, the key making this useful is to keep in mind that the result of this script is a reusable function that can do something that is hard much faster than an ordinary script block. Now go find an interesting use for this and post about it!

Update

I expanded the script so that the delegate can receive an object from the script that made it and also be able to remember past invocations. Script blocks store all their context information as variables, but that's not so easy in this case. Here there is no guarantee that there is even a Runspace associated with the thread that invokes the delegate. Now you can provide an initialization object, optional initialization code, and define the types for any values that should remain present between invocations.

PS> $eh = get-cdelegate 'context0++; Console.WriteLine(context0);' -contexttypes int -initobject 50 -initcode 'context0 = (int)init.BaseObject;'
PS> $eh.invoke($null,$null)
51
PS> $eh.invoke($null,$null)
52
PS> $eh.invoke($null,$null)
53
PS> $eh.invoke($null,$null)
54

I have seen this a few times in my Google referrals. People want to know how to how to add events to PresentationFramework controls in Powershell.
I'm sorry to tell you this, but, as of Powershell v1.0, you can't use script blocks generated in Powershell as event handlers in any STA style user interface, including WPF. This has to do with how Powershell currently handles threading. That's why I had to make three really long scripts just to show a single window.
If you really want to be able to add event handlers to WPF controls have a look at my New-CAssembly script. That will make it easier to include compiled code, such as event handlers, into a Powershell script. Then, look at my Library-PresentationInterface script. That will help you pack a custom user interface into a script as XAML.
Alternatively you may look at a few of Team Powershell's recent posts about controlling WPF through Powershell v2.0 CTP 2. They added an STA flag to CTP 2. This helps to resolve some of the threading issues in regards to controlling STA style user interfaces.

As you will see the last WPF and PowerShell example is a little over complicated when used with the currently released version of Library-PresentationInterface, but I will likely update the library at some point and then scripts like this could then be made more concise.

To make the script easier to read I will list the few basic steps taken by the script.

1. Generate a special collection class that can inform any WPF window displaying it when it is updated. When a window displays a normal collection any updates will likely not be noticed. This part may eventually be added to the library.
2. Create two collections and make the first element of the first collection the string "Loading..." and the second element of the first collection the second collection.
3. Display a window to display the content of the collections. The first collection becomes the tag of the window. A TextBlock is bound to the first element of the first collection(i.e. "Loading...") and a ListBox is bound the content of the second collection.
4. Add the numbers 1 to 5 to the second collection pausing one second between each number.
5. Wait for the user to close the window.

I have used a modified version of this script to monitor the log file of an IRC chat room in real time, effectively making the resulting window another chat window(minus the ability to respond). Any amount of information could be added like other chat rooms, RSS feeds, or any other information you can get your hands on, and any filters can be added to that information.

Requirements:

• New-CAssembly
• Library-PresentationInterface