PowerShell In GUI Blog

PowerShell GUI Box Just In A Few Clicks

Archive for June 2010

How to deal with a ListView control

with 4 comments

As the answer to a question asked on the forum, ‘How to populate a ListView Control from an Array?’, I’d like to publish a funciton used to fill up with data the top-right listview in the Object Browser.

The general use of this funciton was to add row of data (data for several columns) independently whether it was the first row (clean up of a control is required) or not.

The funciton provided also supports highlighting being called in a loop (depends on a loop writer).

#region function fillDetailedListView
function fillDetailedListView
            Creates columns if they are missing and adds a row of data
            This function creates add a row based from a string array. It also optionally clear columns and 
            adds missing columns
        .Parameter ListView
            A reference to a listview control
        .Parameter CleanUp
            An optional flag to clear columns and data before adding a new row
        .Parameter ColumnName
            A string array used as a list of header names
        .Parameter Data
            A string array used as a list of data to be added to a new row
        .Parameter Color
            A flag of the [System.Drawing.SystemColors]::Window type to apply to the newly created row
            fillListView ([ref]$lv) $false (,'Name') (,$key) $null; 
            Author: Alexander Petrovskiy
        [bool]$CleanUp = $false,
        [int]$ImageIndex = $null,
        [string]$NodeKey = ''
    if ($cleanUp) #if clean-up is required
    for ($i = 0; $i -lt $ColumnName.Length; $i++)
    {#check whether the Current column exists or not
        if ( -not ([System.Windows.Forms.ListView] `
        {#add only if it's a new one
                (($header = New-Object System.Windows.Forms.ColumnHeader) `
                    | %{$header.Text = $ColumnName[$i]; 
                        $header.Name = $ColumnName[$i]; 
    if ($Color -eq $null -or `
        $Color.GetType().ToString() -ne 'System.Drawing.SystemColors')
    {#input test of the $Color variable
        $Color = [System.Drawing.SystemColors]::Window;
    #adding items aka rows (an item is a single element of a row,
    #a place where a row and a column are intercrossed
    $listViewItem1 = (($listViewItem = New-Object "System.Windows.Forms.ListViewItem") `
        | %{$listViewItem.Text = $Data[0]; 
            if ($Color -ne [System.Drawing.SystemColors]::Window)
            {#set $Color to all items in the row
                $listViewItem.BackColor = $Color;
                $listViewItem.UseItemStyleForSubItems = $true;
            if ($ImageIndex -ne $null)
            {#if you have an ImageList control in your form
                $listViewItem.ImageIndex = $ImageIndex + 1;
            if ($NodeKey -ne $null -and $NodeKey.Length -gt 0)
                $listViewItem.Tag = $NodeKey;
        #more columns
        for ($i = 1; $i -lt $Data.Length; $i++)
        {#adding data to the row items
            $listViewItem.SubItems.Add((([System.Windows.Forms.ListViewItem`+ListViewSubItem]$subItem = `
                New-Object System.Windows.Forms.ListViewItem`+ListViewSubItem) `
                | %{$subItem.Text = $Data[$i]; 
    #setting AutoREsize property
    if ($Data -ne $null -and $Data.Length -gt 1)
#endregion function fillDetailedListView

#How to use
fillDetailedListView -ListView ([ref]$lvBottom) `
    -CleanUp $false `
    -ColumnName ('Property','Value') `
    -Data ($key,$properties[$key]) `
    -ImageIndex $null `
    -NodeKey $null;

This code sample simply adds a row with items in the columns ‘Property’ and ‘Value’ and doesn’t clean up existing columns.

It’s considered that the ListView you use here called $lvBottom, otherwise you face the following error:
“[ref] cannot be applied to a variable that does not exist.”

A copy of this code snippet has also been posted here: http://powergui.org/thread.jspa?threadID=12497


How to deal with -RoutedEvent parameter in WPK

with 3 comments

After ScriptEditor add-ons having been brought to the World, we were asked by our community enthusiasts about how to handle events.

The problem is that self-contained environments (also known as containers, please refer to about_scopes text file) are not described well. There are in Powershell three more or less contradictory things as follows:

– scopes

– containers that don’t or almost don’t obey the rules of scoping

– three types of variables: user-created, automatic and preference

I’m planning to give an article later this week, but at the moment I’m putting out the immediate example meant to improve the situation.

The story began from a question asked by some guy who created a universal add-on, targeted to work in both powershell_ise and PowerGUI environments. The exact complaint was that ‘my window starts from a command, but in the ise IDE events fired, whereas in the PowerGUI IDE events don’t fire’.

Not planning to spent time right now discussing why MSFT’s containers work better them Quest’s ones, I’d like to grab your attention to the following code sample which is a module, but can also be used as a script:

#Only to be run in the ScriptEditor
if ($host.Name –eq 'PowerGUIScriptEditorHost') {
#region function
function script:Show-TestWindow {
    param($UseGlobal = $false)
    #region event handler
    $global:evt = 
    {    #Declaration of event variables
        #Variant #1
        if ($Event -ne $null) {Write-Host '001' $Event;}
        if ($EventSubscriber -ne $null) {Write-Host '002' $EventSubscriber;}
        if ($Sender -ne $null) {Write-Host '003' $Sender;}
        if ($SourceArgs -ne $null) {Write-Host '004' $SourceArgs;}
        if ($SourceEventArgs -ne $null) {Write-Host '005' $SourceEventArgs;}
        if ($This -ne $null) {write-host '006' $This;}
        if ($global:Event -ne $null) {Write-Host '011 global' $global:Event;}
        if ($global:EventSubscriber -ne $null) 
        {Write-Host '012 global' $global:EventSubscriber;}
        if ($global:Sender -ne $null) 
        {Write-Host '013 global' $global:Sender;}
        if ($global:SourceArgs -ne $null) 
        {Write-Host '014 global' $global:SourceArgs;}
        if ($global:SourceEventArgs -ne $null) 
        {Write-Host '015 global' $global:SourceEventArgs;}
        if ($global:This -ne $null) 
        {Write-Host '016 global' $global:This;}            
        #An additional demonstrable result
        [System.Windows.Forms.MessageBox]::Show("Event fired!");
    #endregion event handler                                        
    #region RoutedEvent hashtable
    [System.Collections.Hashtable]$global:ht = `
        New-Object System.Collections.Hashtable;
    $global:ht.Add("Click", $global:evt);
    #endregion RoutedEvent hashtable    

    #region window
    New-Window -WindowStartupLocation CenterScreen `
        -Width 100 -Height 100 `
        -Show -On_Loaded {
        $global:btnClickMe = $window | Get-ChildControl btnClickMe
        } {
            #region layout
            New-Grid {
                #region button
                New-Button -Name btnClickMe -Margin "20,20,0,0" `
                    -Height 23 -Width 50 `
                    -HorizontalAlignment "Left" `
                    -VerticalAlignment "Top" `
                    -Content "Click Me" `
                    -On_Click $global:evt -RoutedEvent $global:ht
                #endregion button            
            #endregion layout
    #endregion window
#endregion function

    $se = [Quest.PowerGUI.SDK.ScriptEditorFactory]::CurrentInstance
    $cmd1 = New-Object Quest.PowerGUI.SDK.ItemCommand("Hidden", "EventTestLocal")
    #Using a scriptblock
    $cmd1.ScriptBlock = {script:Show-TestWindow $false;};
    #Or using Invoking or Invoked
    #[System.EventHandler]$global:wh = {script:Show-TestWindow; };
    $keys = [System.Windows.Forms.Keys]::Control -bor `

Write-Host "Module WPK.Event.Test loaded";

#We can use this as a script

After turning on the module, you obtain our window by pressing Ctrl+5. Event fires at the moment you click a button providing both command line and messageboxed results.

Please notice the scoping of results printed out into the Console. $This is always global. First, all automatic variables are global. Second, there is a comment in the ‘Writing User Interfaces with WPK’ document shipped with the PowerShellPack. The doc mentioned says that $this, taken in events, ‘is where the event is coming from’.

Why $this is global instead of being script-scoped? Because containers behave slightly differently.

Additional note that I should mention is that you might declare parameters of an event as local (i.e. param($Sender)) or as global ones (that is param($global:Sender)) depending on life cycle of objects you planned.

Written by Alexander Petrovskiy

June 21, 2010 at 9:20 am

A Very Simple Object Browser

with 4 comments

As I again decided to continue writing for the PowerGUI platform, which I’m personally user of, here is one another teaser. This object browser was written while the ScriptEditor object model had been developing and nothing promised that the thing would be living long. However, I used the thing several times after stopping of development, so that I understood it may be needed for somebody else.

I revised what has been done by now and the facts are:

– collecting data from the CurrentDomain, the GAC and from several manually loaded libraries

– displaying public members as well as private.

There are some bugs including broken search across asssemblies.

Features to do list includes

– creating snippets of code for selected definitions

– bookmarks

– rearranging controls and menu

– all other data sources 🙂

Written by Alexander Petrovskiy

June 14, 2010 at 1:34 pm

How difficult to paint a graphical GUI plug-in?

with 2 comments

Got bored with the PowerGUI grid? Nothing new may be added to the such well-known product? How do I understand such a mood!

Being responsible for testing of several Quest’s products, I had not at once thinking to base on the PowerGUI something bright, interesting, new… But poor object model stopped me. Does anybody want to dig into asynchronous operations while writing a script? Even your script is working in the same process as the host application, you definitely can achieve anything in a .NET app, but it’s so unconfortable to touch something in the another thread without proper debugger (as in the AdminConsole).

Below is a typical teaser. By now, the PowerGUI 2.1 has been released, but, supposingly not to be publicly viewed until the TechEd, it hasn’t been published yet.

The new anmazing feature I want to reveal is the some SDK helping you to pluginize the application. Provided as an unfriendly object model, it had been wrapped by enthusiasts, one of them is the your author, me. having shared the ideas and our code with another enthusiast, I realized, that not all ideas of how the product cab be extended were spread across the enthusiasts. Surprisingly, not too many people began writing GUI plug-ins.

So, I’m going to demostrate a screen almost completely occupied with my plug-in. It’ll be called add-in, however I’d prefer something unique like poshlet or something like. The poshlet I mentioned consists of Designer pane, ToolBox with a set of Windows.Forms controls and the property window. All of them use the great Actipro basis. There is the fourth component, that’s totally invisible excepting a menu item. I’ll tell you about the fourth below. Now we can see the plug-in at the moment of custom GUI painting.

Okay, might you say, it’s not new, there are a lot of designers in the numerous IDEs and how can it help me with my scripts? The anwer is that there is a code generator allowing you to run what you painted as soon as it would be, for example, SharpDevelop.

Differently from, for instance, SAPIEN’s free IDE, this poshlet is aimed to create dockable applications in the PowerGUI hosts family.

This is the result of code generation that will be definitely proofread later.

At the end, by pressing F5, we have the window that had been painted a few seconds ago.

At left is the window created dynamically whereas at right is what we painted.

Written by Alexander Petrovskiy

June 3, 2010 at 1:24 am