Tome's Land of IT

IT Notes from the Powertoe – Tome Tanasovski

Category Archives: GUI

PowerShell Studio 2012 – vNext for Primal Forms

I have just returned from the amazing lineup of PowerShell sessions at the NYC Techstravaganza.  Sapien happened to sponsor the PowerShell track.  This gave us the opportunity to hear what the company has been up to directly from their CEO, Dr. Ferdinand Rios.  I should note, not only did we get updates about their 2012 products, but we were handed USB keychains that were fully loaded with beta software!

The session brought us through the updates that Sapien has made to iPowerShell, their iOS app and PrimalScript.  Both had a whole set of new features, but it was the news about Primal Forms that I thought was worth blogging about.  Here are some of the new features we saw (this is probably not a comprehensive list – it’s just the items that raised my eyebrow during the session):

Primal Forms is now called PowerShell Studio 2012

This makes a lot of sense to me.  It is a name that more appropriately tells what Primal Forms is.  It’s not only a full-fledged winform developing environment for PowerShell, but it’s also a fairly robust integrated scripting environment (ISE).  The only downside is that there is already a codeplex project with this name.  It’s sure to spin up some conflict or debate.

Layout Themes

One thing is clear when working with Primal Forms 2011, you definitely don’t want/use all of the panes that you have open all the time.  When working on forms, you need a whole different layout than you need when you want to just work on a simple script.  Layouts can now be switched rapidly via a control in the bottom left.  These layouts continue to happen automatically, but you can also control them manually.

Font Size Slider

This is a slider that will change the size of the fonts in your script window.  I use this slider all the time in powershell_ise.exe when giving demos.  I’m glad this simple change is now in the app.

Function Explorer

This one is cool.  There is a pane that will allow you to quickly click between events and functions in your projects.  It’s dynamically built.  Obviously, it’s really neat when trudging through the complex structure of a scripted winform, but I am finding that it’s really cool for large modules too.

Change-in-code Indicator

There is an indicator between your code and the line numbers that are triggered during a change to your code.  If you open a script, and then make a change to that script, a yellow indicator shows that this has been changed:

Once you save the file, the indicator turns green:

If you open the script again, the indicator resets to not being there.

Toggle a Cmdlet to and from an alias

Apparently, you could always toggle an entire script to remove all aliases.  I was not aware of this.  Regardless, you can now right click on a cmdlet or alias to toggle between the cmdlet and its aliases.

Cmdlets have a ‘Convert to Alias’ context menu:

Aliases have an ‘Expand to Cmdlet’ context menu.

I should note that as of the beta you can convert to the alias foreach or % in place of Foreach-Object, but you cannot expand it back to a cmdlet.

Tab Completion of .NET Methods

Neat-o feature.  When you enter a method, you get a helper window to tell you the overloaded options.  You can press up and down (or click up and down in the intellisense helper) to select the appropriate parameter set that you plan to use:

Once you have found the right method, you can press tab (like the helper says) to autofill the method’s parameters.  This is really nice with classes that use an enumerator.  It saves you from having to type out the entire class name.  For example, the next image shows that it has typed the entire [System.MidpointRounding] for me.

It goes a bit further too.  As you can see above, a variable name is created and highlighted.  You can immediately start typing another variable or decimal.  Once you are done entering that parameter, you hit tab to go to the next one.  In the case of an enumerator, like the one above, it lets you select the item in the enumerator you would like to use.  This is handled via another intellisense helper that you can quickly move to with the up and down arrows.  It even gives you information about what the item does:

Control Sets

This is the one that matters!  This is the promise of scripted GUIs in my opinion.

You can package sets of common form controls, events, and functions as a control set.  This gives you an easy way to add something to your form that is a complete thing (for lack of a better word) via drag and drop.  For example,

  • You can add text boxes that have validation pre-configured so that it will validate whether or not you have an e-mail address or phone number.
  • You can add charts that automatically pull data from a specific cmdlet.
  • You can add buttons that run background processes or jobs that include status bars and indicators that help the end-user understand what is happening.
  • You can also include a quick textbox that will automatically have a button with an associated file-dialogue box that will populate the textbox.

Here is a list of the control sets that are in the beta:

I should note that the “TextBox – Validate IP” is one that I created this morning during breakfast.  I was floored by how easy it was to do (with some knowledge of winforms).  Actually, not only easy, but they give you the ability to utilize shared controls between the control sets.  In other words, if you already have an appropriate ErrorProvider object that can serve the validation for your TextBoxes, it will use that object rather than creating a new one if you tell the wizard that it can do so.  I will be blogging a detailed tutorial on how to do this today or tomorrow.

Debugging a Script that uses Remoting

Okay, this is the final feature.  The demo we saw did not show this.  Also, the beta version we received does not yet have it.  However, the promise was made in Ferdinand’s last slide.  When PowerShell Studio 2012 ships sometime in the Spring, it will have a remote debugger.

New-SimpleForm – Holy dynamic GUI Batman!

Just like everyone else in the Windows PowerShell community I found what James Brundage and Joel “Jaykul” Bennett were doing with scripting UIs extremely interesting.  However, I found the whole process cumbersome for some reason.  Perhaps it was due to “meh” documentation.  Perhaps it was due to my brain just not being ready to absorb it.  Perhaps it was due to the fact that I can develop a winform really quickly in something like Primal Forms.  Whatever it was, it just didn’t seem like it was worth my effort.  Even after I watched James give a presentation on scripted GUIs at this year’s Techstravaganza in NYC I saw the potential, but I did not feel compelled to waste any more time with WPK than the few days I gave it when the PowerShell Pack was released.  Recently, the two major players in the scripted UI space joined forces with Doug Finke and developed a new set of cmdlets that took the great elements of each implementation of interfacing with WPF and combined them into one extremely sleek and impressive module.  In my mind this must have played out like this:  Doug Finke, successful enterprise-level developer who focuses on automation in the development space grabbed two mad scientists by the back of their necks and forced them down from the stratosphere where their genius lives to focus them to work in the world with the rest of us.  Perhaps there were chains involved?  Perhaps shock treatment?  Perhaps it didn’t even happen like that and was more like James’s blue ox cut down Jaykul’s apple tree and little red riding Doug couldn’t tell a lie.  We’ll let the myth of the why perpetuate.  What’s important is that I am impressed with their collaborative effort, and I can’t wait to share what I did in only 60 minutes with the new stuff.

If you are not aware of what I’m talking about and these names just sound like nonesense to you welcome to the niche world of scripted UIs.

The Promise of Scripted UIs

The promise is simple.  Dynamically generated user interfaces that adapt to your needs.  I had the rare opportunity to see some of James Brundage’s WPK-based cmdlets that would convert seemingly simple bits of code into beautiful graphics and doo dahs and woo hoos.  He was developing a library of these to help him very rapidly develop based off of these prototypes.  It appears that now that this is within all of our reach.

The ShowUI toolkit

I won’t be going into the introduction of how to use this module.  I’ll leave that to you.  There’s a few places to start though.

  • Download ShowUI from the codeplex site
  • Read the amazing tutorial that Joel “Jaykul” Bennet put up on his site (to be honest – this is as far as I’ve gotten so far).  Actually his other posts on the subject look good too.
  • Watch the videos that James Brundage put together on his site
  • Read the articles that Doug Finke has been posting.  The twitter client looks bad-ass!  He also has a video up.


The one thing you’ll notice when going through the sample code is that everything is written in scriptblocks.  This is the power of the toolkit.  It is based on Ruby Shoes – a toolkit that was created to make UIs for Ruby.  The syntax looks nearly identical.  But that’s a digression.  More importantly is that scriptblocks can easily be dynamic because they are just code.  A while back I posted this article that talks about the world of dynamic scriptblocks in Windows PowerShell.  I took that and realized that I could easily apply it to the sample in Joel’s tutorial that stood out the most to me:  The simple form that displays label/textbox, label/textbox, label/textbox, etc, followed by a button to submit.  The magic was that not only was this being generated, but after hitting submit it returned a hash table that had the values that were entered in the text boxes.  So, I said to myself, “Well I want this dynamic.  I want to pass a random number of fields and have it generate this simple form.  The result is the function below New-SimpleForm.

Import-Module showui            

function New-SimpleForm {
        [Parameter(Mandatory=$true, ValueFromPipeline=$true)]
        [string]$Name = 'Simple ShowUI Form',
        [int] $MinWidth = 250
    BEGIN {
        $allfields = @()
        $allfields += $Fields
    END {
        $txtblock = ""
        $row = 0
        foreach ($field in $allfields) {
            $boxlabel = $field -replace '\W' ,'_'
            $txtblock += "Label '$field' -row $row `r`n"
            $txtblock += "TextBox -Name '$boxlabel' -Column 1 -Row $row`r`n"
        $txtblock += @" Button "Submit" -IsDefault -On_Click { Get-ParentControl | Set-UIValue -passThru | Close-Control } -Row $row -column 1 "@
        $scriptblock = $ExecutionContext.InvokeCommand.NewScriptBlock($txtblock)
        $onloaded = $ExecutionContext.InvokeCommand.NewScriptBlock("`$$($allfields[0] -replace '\W', '_').Focus()")
        grid -ControlName $Name -Columns Auto,* -Rows ($allfields.count + 1) -MinWidth $MinWidth $scriptblock -show -On_Loaded $onloaded


New-SimpleForm can be called like this:

@("Name", "E-mail", "Date of Birth") | New-SimpleForm

The above will produce this form:

The output will be a hash table that looks like this:

Name                           Value
----                           -----
Name                           Tome Tanasovski
Date_of_Birth                  5/11/1976

Alternatively you could supply the hash table right into a psobject if you prefer:

new-object psobject -Property (@("Name","E-mail","Date of Birth") |New-SimpleForm)

The output of the above looks like this:

Name                         Date_of_Birth                E_mail
----                         -------------                ------
Tome Tanasovski              5/11/1976          

Not bad for only 60 minutes of tinkering. Now I have a utility webform that I can use to retrieve user input extremely quickly. Obviously, validation has to come after the fact, but that’s not so bad. Whew! Feels good to be playing with interesting things!

———————-Update 7/6/2011, 8:55 PM————————–

ShowUI version 1.1 was just released with a cmdlet called Get-Input.  This takes my idea and blows it out of the water!  Check out the video of it here.

PrimalForms 2011 – Sneak Peek

One of the most anticipated releases in the Powershell community this year is the new version of PrimalForms that is due to be released early in 2011. If you have ever needed to create a GUI front-end for a PowerShell script you have definitely seen or tried PrimalForms or the free PrimalForms community edition. While the PowerShellPack released by Microsoft gives you a nice way to work with WPK, it is cumbersome and can be difficult to figure out. Actually, creating any GUI by hand without a visual guide can be an absolute nightmare. PrimalForms takes out all of the manual grunt-work while giving you plenty of bells and whistles.

I was able to see a sneak preview of the 2011 version back in September when the CEO of Sapien, Dr. Ferdinand Rios, stopped by the NYC PowerShell User Group meeting to demo some of the new features. Recently, I was even more fortunate to get my hands on an actual copy of the pre-release binaries. With the blessing of Sapien, I have been given permission to give you my first impressions of this not-yet-ready-for-production product.

With the release of PrimalForms 2011 Sapien has taken a leap; PrimalForms 2011 is more full-fledged scripting environment than the niche utility product the 2009 version was. In addition, it adds some really nice features that will make the form generators really happy.

So, what’s new?

Templates for simple forms

When you click the new button there are a series of template winforms you may choose from. I like this feature. I’m not sure if it will be customizable or not, but it can definitely cut down on time for simple tasks – and let’s face it: when you are creating a GUI for a script it should always be for a simple task – otherwise you should be developing in C#, in my opinion.

Add Events

This is my absolute favorite feature! – It is the reason to upgrade. In 2009 you could double click on an item in your form and you would go to the default event for that item. In 2011 you can right click on any object in your form and choose add Events. This brings up a selector that lets you pick and choose from all of the available events for that object.

Goto Event

Oh man! So cool! Not only can you create events in the GUI, but you can right click on an object and click goto event to see what events you already have created. You can then click on one of those events to go right to the script section that handles the event.

Insert Recent Control

This is a nice little utility feature. It allows you to quickly add form items that you have recently added without having to go back and find them in the toolbox. This is sure to cut down on time when developing a form that creates 20 textboxes for input along with 20 labels to describe them.

WMI Browser

This is another nice one. The WMI browser is very clean. It can even generate a quick GUI query form for a single WMI query via right click -> Generate Query Form. This makes a simple winform that has some buttons and a datagridView. When the ‘Generate’ button is clicked it populates the datagrid with the WMI results.


PrimalForms has a snippet library that you can browse. You can drag snippets from the browser directly into your scripts. You can also create your own snippits and organize them however you desire. Looking at the precanned snippits shows some usual suspects. However, there is one section that caught my eye called vbscript to PowerShell. While I cannot see myself ever using this section of the snippits (I’m sure others will), I did have a lot of fun dragging the various commands to my script to see the methods they employed.


This is nice for the bloggers.  You can copy/paste an html version of the formatted and colored text within your script.  It looks so nice, I may start using it here.  Here’s an example of how it looks:

if ($true) { $hello="Hello World"$hello|Out-File hello.txt }


Just like in Visual Studio you can create a set of scripts bound together as a project.

PowerShell Console

They finally added a console panel – you can now interact with a shell in PowerShell without having to leave Primal Forms. The only problem with their implementation in the early preview is that I cannot run commands in my editor and have them exist in the shell session. In other words, if I set a variable in my script I cannot inspect that variable in the shell. When mentioning this point to Sapien I was told that there is new functionality in PrimalScript 2011 that will also be in PrimalForms. Specifically,

“…the ability to run the script that you are working on in a console of your choice with the push of a button. The console will perpetuate variable values etc, even if you switch to a different console. So you could run in 64bit PS console, switch to 32 bit PS console then switch back and variable state will be what it was. It acts just like you expect the console to act. You can also run the script from PrimalForms and That will be almost like a single instance console which gets reset every time.”

Controlling the Type of Session you are in

Sapien has added some really easy-to-use buttons that can control whether you are running within a 32-bit or 64-bit session. You can also quickly turn STA on and off on the main menu.

The Debugger

Full debugging appears to be in store for us. Unfortunately, this feature does not appear to be complete in my preview copy, but I imagine that it will be similar to the debugging we get in powershell_ise.exe. I assume that they will be using their own debugging engine rather than the built-in PowerShell debugging. It’s understandable why they would do this, but I really like the PowerShell debugger. Regardless of the engine, it will be very nice to be able to troubleshoot winform code directly in PrimalForms.

Data Source Browser

You can now connect to and create data sources via PrimalForms the way you would in Visual Studio. I didn’t get to play with this feature much yet, but it’s on my list of things to do. This may very well be the feature that turns PowerShell users into application developers. I expect to see some blog posts or tutorials dedicated to showing you how to bind winform objects to these data sources in the future.

Source Control

This is a big one!  My copy does not have the providers listed that are available.  Apparently you will only see source control providers that you have installed on your computer.  Unfortunately, I’m running this in a lab that is isolated from source control so I cannot test this out just yet.  If you use source control this is probably the most desirable feature to you in the new product.

Old Feature Revisited

I don’t want to go too crazy talking about things that most people already know about, but since I have been playing with the 2011 version of the product I have found an amazing way of using a feature that is also available in the 2009 product: the help browser. As you type in the script editor there is a help window that will show you the Get-Help for the cmdlet you are working with. A technique I have been playing with on the 2011 version is to undock the help window and put it on another monitor. This is such a cool way to develop that I had to point it out. There are even little clickable sections so that you can quickly go to any section in the help. I have already clicked the parameter section a few times in the two days I have had with the product. I highly suggest playing with this in the 2009 or 2011 version of the product.


This may or may not be an exhaustive list of the new features. These are the new ones that I noticed while playing with the product. Add them to the rich feature set that exists in the 2009 version and I think you can see why everyone is waiting with bated breath for this product to get released.

The new features definitely make PrimalForms more of a scripting environment, but I’m a bit of a snob when it comes to scripting environments. I exclusively use powershell_ise.exe that comes with PowerShell 2.0. There is an argument to be made that it is not really a scripting environment, but maybe that’s what I like about it. I want the quickest and fastest editor I can have when I script. Add debugging support, and I have everything I need – well, missing source control, but almost everything I need. I am inclined to give PrimalForms a shot as the “one ring to rule them all” when it is officially released. Whether that experiment is fruitful for me doesn’t really matter much because the new features will make the generation of winform GUIs a delight to create – That’s reason enough for me to upgrade.

Custom icons in Powershell winforms

Since Ed Wilson has been on a Primal Forms kick (view one of the articles here)…. and since I happened to use Primal Forms community edition for my Scriptomania entry I thought I would share my method for creating a custom icon within a winform using Powershell.  When talking about icons we’re talking about the graphic that sits in the top left corner of a winform:

If you’re using primal forms you can easily add an icon to your winform by creating an ico file, and then browsing to the file within the Window Style->Icon property of the main form:

Doing this will use the ExtractAssociatedIcon() method of System.Drawing.Icon to create the icon from the file.  Here is the code that Primal Forms generates for you:

$form1.Icon = [System.Drawing.Icon]::ExtractAssociatedIcon('C:\Users\ttanasovski\scripts\toenuff.ico')

To make your icon there are a ton of tools out there.  Favicon generator is a great site if you want to quickly draw and export a 16×16 ico file.  This is the perfect size for a simple one-letter winform .ico.  The interface is very clean and simple:

Fine and dandy, but when you’re talking about a script I always feel one of the goals should be extreme portability.

I want to be able to hand some text to my colleague so he/she can use it immediately without having to worry about needing supporting files.  Because of this I had to find a way to generate my icon within Powershell itself.  In the end I found that I could use the System.Drawing.Graphics of a new 16×16 System.Drawing.Bitmap:

$bmp = New-Object System.Drawing.Bitmap(16,16)
$g = [System.Drawing.Graphics]::FromImage($bmp)

Once I had this I could use the numerous graphics methods available to draw my icon.  Take the following example that draws an X:


Once my doodling was completed I could pass the GetHicon() method of Bitmap to the FromHandle static method of System.Drawing.Icon to create the icon:

$ico = [System.Drawing.Icon]::FromHandle($bmp.GetHicon())

Finally, I only needed to set the icon property of the winform to the icon I created:

$form1.Icon = $ico

Here is the final product that creates my winform, draws out my lovely T for Toe/Toenuff/Tome/Terrific, turns it into an icon, and then sets the icon to the form:

function GenerateForm {
    [reflection.assembly]::loadwithpartialname("System.Windows.Forms") | Out-Null
    [reflection.assembly]::loadwithpartialname("System.Drawing") | Out-Null
    $form1 = New-Object System.Windows.Forms.Form
    $InitialFormWindowState = New-Object System.Windows.Forms.FormWindowState
    # Icon generation and loading into form
    $bmp = New-Object System.Drawing.Bitmap(16,16)
    $g = [System.Drawing.Graphics]::FromImage($bmp)
    $ico = [System.Drawing.Icon]::FromHandle($bmp.GetHicon())
    $form1.Icon = $ico
    # End of the icon generation and loading
    $form1.Text = "Icon Form"
    $form1.Name = "form1"
    $form1.DataBindings.DefaultDataSourceUpdateMode = 0
    $System_Drawing_Size = New-Object System.Drawing.Size
    $System_Drawing_Size.Width = 284
    $System_Drawing_Size.Height = 262
    $form1.ClientSize = $System_Drawing_Size
    $InitialFormWindowState = $form1.WindowState
$form1.ShowDialog()| Out-Null
%d bloggers like this: