When working with GUIs you may have noticed that the Form can freeze when running long scripts. Previously I discussed how to make your loops more responsive in this article, but not every long script comes in the form of a loop. If you truly want to make your forms responsive, you will need to move these slow scripts into another thread and in the PowerShell world this means using jobs.

For those of you who aren’t familiar with PowerShell Jobs, they allow you to run scripts while freeing up the console to perform other tasks. In this case it will free up the GUI and allow it to respond to user input.  This article will not cover the ins and outs of jobs and it expects the user has some basic knowledge of the jobs mechanism in PowerShell. For your convenience we will list the cmdlets that are directly related to jobs. Please refer to the MSDN PowerShell Jobs help page for more information.

Job Cmdlets:

Start-Job

Starts a background job on a local computer.

Get-Job

Gets the background jobs that were started in the current session.

Receive-Job

Gets the results of background jobs.

Stop-Job

Stops a background job.

Remove-Job

Deletes a background job.

Wait-Job

Suppresses the command prompt until one or all jobs are complete.

Caveats when using Jobs and Forms

There are two caveats you need to keep in mind when using jobs within a Form.

1. Never access or modify form controls directly from within a job. If you need to update a form control or show progress, use the Receive-Job cmdlet to gather any necessary information from the job first and then update the control from the main script. The form controls do not allow themselves to be accessed from a different thread (i.e., the job).

2. Don’t use Register-ObjectEvent cmdlet. To determine if a job is complete you will need to check the status of the job. If you try to register an event handler for the job’s StateChanged event using Register-ObjectEvent, you find that it will not seem to trigger while the form is displayed, unless you call the [System.Windows.Forms.Application]::DoEvents() method mentioned in the Creating Responsive Loops article.

For example:

Register-ObjectEvent -InputObject $Job -EventName StateChanged `
   -Action {
            Write-Host 'State Changed'
            $form1.WindowState = 'Minimized' #Will not work
            #Handle the events so the message will display
            [System.Windows.Forms.Application]::DoEvents()
           } 

Even with this work around you cannot access the form controls directly. Therefore, you will need to use a Timer control to check the job’s status periodically.

Creating a Form that utilizes Jobs

Now that we covered the caveats, we can now begin to modify our forms so that it can handle jobs.

Version 3.0.3 of PowerShell Studio has a Control Set called “Button – Start Job”. If you look at the control set it inserts  a button and a timer. The timer checks the status of a job that is created when the button is pressed.

Button Click Event:

The button creates a job, starts the timer and uses the tag property of the timer to track it.

$buttonStart_Click={
    #TODO: Set a script block or specify a script path
    $jobScript = {
        for($i = 0; $i -lt 50; $i++){ Start-Sleep -Milliseconds 100 }
        }

    try
    {
        $job = Start-Job -ScriptBlock $jobScript
        #$job = Start-Job -FilePath <script path>

        $buttonStart.Enabled = $false
        $buttonStart.ImageIndex = 0
        $timerCheckJob.Tag = $job
        $timerCheckJob.Start()
    }
    catch [Exception]
    {
        Write-Debug $_
        #Stop the Timer
        $buttonStart.ImageIndex = -1
        $buttonStart.Enabled = $true
        $timerCheckJob.Tag = $null
        $timerCheckJob.Stop()
    }
}

Timer Tick Event:

The Timer checks its Tag property, which contains the job object and checks the job’s State property to see if it is still running. If the job is complete, it stops the timer and enables the button, otherwise it continue to animate the button.

$timerCheckJob_Tick={
    #Check if the process stopped
    if($timerCheckJob.Tag -ne $null)
    {
        if($timerCheckJob.Tag.State -ne 'Running')
        {
            #Stop the Timer
            $buttonStart.ImageIndex = -1
            $buttonStart.Enabled = $true
            $timerCheckJob.Tag = $null
            $timerCheckJob.Stop()
        }
        else
        {
            if($buttonStart.ImageIndex -lt $buttonStart.ImageList.Images.Count - 1)
            {
                $buttonStart.ImageIndex += 1
            }
            else
            {
                $buttonStart.ImageIndex = 0
            }
        }
    }
}

As you can see this works well with a single job and if you need multiple jobs to run at the same time then you have to create multiple timers.

Creating a new Job Tracker Framework

Let’s expand on this idea and create a system that can scale and that only requires a single timer.

First we need a list that the system can use to track the current jobs. It is defined as follows:

$JobTrackerList = New-Object System.Collections.ArrayList

Next I created functions to interface with the JobTracker Framework.

The first function is Add-JobTracker. This function creates and adds a new job to the Job Tracker.  It allows you specify a script block that the job will run and optional script block that will be called when the job is completed and another when the timer performs an update.

function Add-JobTracker
{
    <#
        .SYNOPSIS
            Add a new job to the JobTracker and starts the timer.

        .DESCRIPTION
            Add a new job to the JobTracker and starts the timer.

        .PARAMETER  Name
            The name to assign to the Job

        .PARAMETER  JobScript
            The script block that the Job will be performing.
            Important: Do not access form controls from this script block.

        .PARAMETER ArgumentList
            The arguments to pass to the job

        .PARAMETER  CompleteScript
            The script block that will be called when the job is complete.
            The job is passed as an argument. The Job argument is null when the job fails.

        .PARAMETER  UpdateScript
            The script block that will be called each time the timer ticks.
            The job is passed as an argument. Use this to get the Job's progress.

        .EXAMPLE
            Job-Begin -Name "JobName" `
            -JobScript {
                Param($Argument1)#Pass any arguments using the ArgumentList parameter
                #Important: Do not access form controls from this script block.
                Get-WmiObject Win32_Process -Namespace "root\CIMV2"
            }`
            -CompletedScript {
                Param($Job)
                $results = Receive-Job -Job $Job
            }`
            -UpdateScript {
                Param($Job)
                #$results = Receive-Job -Job $Job -Keep
            }

        .LINK

    #>

    Param(
    [ValidateNotNull()]
    [Parameter(Mandatory=$true)]
    [string]$Name,
    [ValidateNotNull()]
    [Parameter(Mandatory=$true)]
    [ScriptBlock]$JobScript,
    $ArgumentList = $null,
    [ScriptBlock]$CompletedScript,
    [ScriptBlock]$UpdateScript)

    #Start the Job
    $job = Start-Job -Name $Name -ScriptBlock $JobScript -ArgumentList $ArgumentList

    if($job -ne $null)
    {
        #Create a Custom Object to keep track of the Job & Script Blocks
        $psObject = New-Object System.Management.Automation.PSObject

        Add-Member -InputObject $psObject -MemberType 'NoteProperty' -Name Job  -Value $job
        Add-Member -InputObject $psObject -MemberType 'NoteProperty' -Name CompleteScript  -Value $CompletedScript
        Add-Member -InputObject $psObject -MemberType 'NoteProperty' -Name UpdateScript  -Value $UpdateScript

        [void]$JobTrackerList.Add($psObject)    

        #Start the Timer
        if(-not $timerJobTracker.Enabled)
        {
            $timerJobTracker.Start()
        }
    }
    elseif($CompletedScript -ne $null)
    {
        #Failed
        Invoke-Command -ScriptBlock $CompletedScript -ArgumentList $null
    }

}

A custom PSObject is used to keep track of the job and script blocks. Afterwards the PSObject is added to the Job Tracker list. Note: The corresponding job is passed as an argument to the CompletedScript and UpdateScript script blocks. This allows the user to use the Receive-Job cmdlet to access the full or partial results of a job.

Next we created a function called Update-JobTracker, which the timer uses to check the status of all the jobs in the Job Tracker List. If the job is complete, it will then call the job’s corresponding CompletedScript script block. Otherwise if the job is still running, it will then call the corresponding UpdateScript script block. If all the jobs are completed, then the function will stop the timer.

function Update-JobTracker
{
    <#
        .SYNOPSIS
            Checks the status of each job on the list.
    #>

    #Poll the jobs for status updates
    $timerJobTracker.Stop() #Freeze the Timer

    for($index =0; $index -lt $JobTrackerList.Count; $index++)
    {
        $psObject = $JobTrackerList[$index]

        if($psObject -ne $null)
        {
            if($psObject.Job -ne $null)
            {
                if($psObject.Job.State -ne "Running")
                {
                    #Call the Complete Script Block
                    if($psObject.CompleteScript -ne $null)
                    {
                        #$results = Receive-Job -Job $psObject.Job
                        Invoke-Command -ScriptBlock $psObject.CompleteScript -ArgumentList $psObject.Job
                    }

                    $JobTrackerList.RemoveAt($index)
                    Remove-Job -Job $psObject.Job
                    $index-- #Step back so we don't skip a job
                }
                elseif($psObject.UpdateScript -ne $null)
                {
                    #Call the Update Script Block
                    Invoke-Command -ScriptBlock $psObject.UpdateScript -ArgumentList $psObject.Job
                }
            }
        }
        else
        {
            $JobTrackerList.RemoveAt($index)
            $index-- #Step back so we don't skip a job
        }
    }

    if($JobTrackerList.Count -gt 0)
    {
        $timerJobTracker.Start()#Resume the timer    
    }
}

We update the timer tick event to call the update Function from our Timer Tick event:

$timerJobTracker_Tick={
    Update-JobTracker
}

Note: You can modify the Timer’s Interval property to slow  down or speed up the amount of time the timer waits before checking the progress of the pending jobs again.

The final function of our Job Tracker Framework is the Stop-JobTracker function.  This function will stop all pending jobs and remove them from the Job Tracker list. The function will also stop the timer.

Note: You can call the Stop-JobTracker function in response to the user closing the form. This ensures there are no pending jobs running after the fact.

function Stop-JobTracker
{
   <#
        .SYNOPSIS
            Stops and removes all Jobs from the list.
    #>
   #Stop the timer
   $timerJobTracker.Stop()
   
   #Remove all the jobs
   while($JobTrackerList.Count-gt 0)
    {
       $job = $JobTrackerList[0].Job
       $JobTrackerList.RemoveAt(0)
       Stop-Job $job
       Remove-Job $job
    }
}

Now that we have a new framework, we can revise our initial Start Job button’s click event as follows:

$buttonStartJob_Click={

    $buttonStartJob.Enabled = $false    

    #Create a New Job using the Job Tracker
    Add-JobTracker -Name "JobName" `
    -JobScript {
           #--------------------------------------------------
        #TODO: Set a script block
        #Important: Do not access form controls from this script block.

        Param($Argument1)#Pass any arguments using the ArgumentList parameter

        for($i = 0; $i -lt 50; $i++){ Start-Sleep -Milliseconds 100 } 

        #--------------------------------------------------
    }`
    -CompletedScript {
        Param($Job)
        #Enable the Button
        $buttonStartJob.ImageIndex = -1
        $buttonStartJob.Enabled = $true
    }`
    -UpdateScript {
        Param($Job)
        #$results = Receive-Job -Job $Job -Keep
        #Animate the Button
        if($buttonStartJob.ImageIndex -lt $buttonStartJob.ImageList.Images.Count - 1)
        {
            $buttonStartJob.ImageIndex += 1
        }
        else
        {
            $buttonStartJob.ImageIndex = 0
        }
    }
}

All of the script is now contained within a single location. What’s more we can use the Add-JobTracker function to create multiple jobs using various sources as triggers without having to create multiple timers or add any other special considerations.

Displaying Progress with the Job Tracker:

If you want to display partial data or the Job’s progress, you should use the Receive-Job cmdlet during the update script block.

If you want to use a progress bar, you might consider having your job script output the percentage of progress.

For example:

    -JobScript {
        for($i = 0; $i -lt 100; $i++)
        {
            #Do some work
            Start-Sleep -Milliseconds 100
            #Output Progress
            $i + 1
        }
    }

Now you can use the Receive-Job cmdlet to check the last value and use it to set the progress bar.

    -UpdateScript {
        Param($Job)
        $results = Receive-Job -Job $Job | Select-Object -Last 1

        if($results -is [int])
        {
            $progressbar1.Value = $results
        }
    }

And update the CompleteScript scriptblock to show the progress at 100%:

    -CompletedScript {
        Param($Job)
        $progressbar1.Value = 100
        $buttonStartJob.Enabled = $true
    }

If you return results as well as the progress status then you might want to use the Receive-Job’s Keep parameter to ensure the data is all there. You will also need to make sure you ignore the progress information when processing the final results. You can use any number of techniques to differentiate this information. For example, you can use strings that start with “P: ” to determine it is a progress indicator. Of course this also then means you will need to parse and filter this information when receiving job results. The sky is the limit as to how you wish to handle these situations.

Job Tracker Control Set!

The good news is you needn’t worry about copying and pasting the framework in to each of your forms. I created an easy to use Control Set that will insert the framework into your existing form.  In addition, I updated the “Button – Start Job” control set to utilize the new Job Tracker framework. The beauty of it is that it will no longer insert duplicate timers, since it is now handled by the Job Tracker Control Set.

These control sets will be available in the next service release (v3.0.4).

In the mean time you can download the sample Job Progress bar form from our Downloads section.

Technorati Tags: Button, Control Sets, Controls, Form, job, powershell, PowerShell Studio, PrimalForms

Last time we looked at the new code navigator on top of the source code views in PrimalScript 2012. Today we’ll have a look at the other tabs on the new ribbon interface.

There are four additional tabs that are always available:

View

This is the place where you can show or hide all the secondary windows, or things you switched of by accident. Most items are pretty self-explanatory. The Debug console only applies to PowerShell, so don’t expect that to be available when  you are debugging VBScript. ‘Call Stack’, ‘Variables’ and ‘Watch’ become visible automatically when you start debugging, but in case you inadvertently close one, here is where you bring it back.

Project

If the name didn’t give it away, this tab is about projects. If you have never used them, you can just forget about this tab. If you use projects to group files together, develop ASP web sites, create C# or VB.NET components etc. you have seen all this. All the project functionality of the previous PrimalScript versions is concentrated in one place.

Tools

The Tools tab is the home of all the things you should need occasionally, but please let us know if we need to transfer any of this to the Home tab. The wizards are pretty much on par with the 2011 versions and the FTP functionality is also identical. We just moved the items from the 2011 file submenu to it’s own group here to make it more discoverable.
The source control group contains all the items from the old Source control toolbar. Last but not least we have the Database group, which sets the current connection for any SQL files you would like to run directly from within PrimalScript.

Help

Product Help links to the help file, the manual and a default keyboard map. Yes, we know it is still the 2011 manual. It is being worked on and I was promised it would go faster than last time.
Check for updates launches the update checker in the designated interval. As opposed to some other products, we don’t continuously run an agent hogging memory and bandwidth. The check is only run as set by you and then terminates. Of course you can always click “Check for updates” to check right now.
Register product: We really encourage you to do that. It will store your license key on our site and associate it with your login. If you ever loose your hard drive and email archive, you can get the license key and the software right on our site. If you don’t register your key we may not be able to help you especially if you or your company purchased it through a third party.

Some links to our site round out this category. Click on them, pretty self-explanatory.

Additionally, there are three context tabs which only show up when you open and activate HTML or XML files. There is a third kind, which will only open up when you connect to an FTP site.
These are called context tabs because they only become visible when the associated document type is open and has the focus. It reduces clutter in the main user interface for those who never use these functions.

HTML

Whenever you set the focus to an HTML page in text or WYSIYG mode you will see the HTML context tab show up. It contains helpful functions and indicators for this particular file type. If you open a browser window within PrimalScript, e.g. from an MSDN search, you will also get this context tab. As soon as you activate a document where this does not apply to it will be hidden again.

XML

XML are very commonly used as configuration files today and you may encounter them more often than before. PrimalScript contains a special XML editor that makes the structure of these files easier to comprehend. If you want to edit them in plain text mode, you can. If you have to deal with these types of files a lot I suggest you also have a look at PrimalXML 2012. This tab and its groups contain command that apply to the structured XML editor in PrimalScript.

FTP

We do not recommend that you edit files directly on an FTP server. It is always much better to sandbox them locally and upload them when you are done editing. We know however that what is consider a “best practice” does not always correlate to reality. So if you go to the Tools tab on the Ribbon bar and open an FTP site you will see this context tab becoming active. For PrimalScript 20xx users this is really just a reincarnation of the FTP toolbar. The functions are pretty straightforward and should pose no problem for users familiar with FTP.

Technorati Tags: context, ftp, html, PrimalScript 2012, PrimalXML, Ribbon, WYSIWYG, XML

New versions of PrimalScript, PowerShell Studio, PrimalSQL, PrimalXML, PrimalForms and ChangeVue are available. Registered users can download the latest service builds from MySAPIEN.

Release Notes:

2012 Versions:

PrimalScript 2012 v6.5.125

- VBScript debugger fails on 32 bit only machines
- “Search again” renamed to “Repeat last search”
- Encoding displayed for embedded VBScript file in WSF
- Erroneous SaveAs dialog when closing embedded script without saving
- “Toggle outline” not available or functional  on last line of region
- Cursor moves to a wrong place when inserting a multi-line snippet
- Change marker is moving with inserted empty lines
- Opening an embedded file shows all lines marked as changed

PowerShell Studio 2012 v3.0.3

ADD: Pressing F1 in the Properties Pane will now take you to the appropriate MSDN help page.
ADD: Current Line Highlighting (Enable in Options->Editor)
ADD: ToolStrip Control (Toolbar Replacement)
ADD: Pressing Escape in the ToolBox Panel will now select the cursor.
ADD: Get-CheckedNodes Helper Function for TreeViews
ADD: Get-MSChartInstalled Helper Function for Chart
ADD: NotifyIcon Spotlight Article Link
ADD: Speech Snippet which uses .NET to produce speech.
ADD: Option to expand alias and partial parameter names with TAB.
ADD: New Control Set: ElementHost – Host WPF Controls in WinForms!
FIX: File Compare not calling PrimalMerge 2012
FIX: Signing message missing space
UPD: NotifyIcon Helper Function
UPD: MySQL Provider
UPD: Partial Parameters will not color unless there is a unique match
UPD: Control Sets will now include regions for Functions and Events
UPD: RSEE Service Installers

Previous Builds changes:
UPD: Sort-ListViewColum, Add-ListViewItem, Load-ListBox, Load-ComboBox helper functions
UPD: ListView – SortingColumns and ListView Application List ControlSets
FIX: Can’t refresh Cache once a module exported.
FIX: Splitter Exception when Closing and Opening Docking Panels
FIX: Crash issue when hovering over a bad parameter
FIX: Crash Issue when tabbing with PrimalSense List has no selection.
FIX: Console not restarting after typing “exit”
FIX: FuctionExplorer – “failed to compare two elements” error
FIX: Crash issue when using internal Help
FIX: Internal Help no longer use when typing Cmdlets in editor and “Use External Help” is set.
UPD: Partial Parameters will display the complete name when hovering

PrimalSQL 2012 v3.0.1

FIX: Splitter Exception when Closing and Opening Docking Panels
UPD: MySQL Provider

PrimalXML 2012 v3.0.2

FIX: File Compare not calling PrimalMerge 2012

ChangeVue 2012 v2.1.44

- Added current version column to main file list
- Times and dates are now displayed according to current locale.

2011 Versions:

PrimalScript 2011 v6.0.175

Minor fixes and changes

PrimalForms 2011 v2.0.25

FIX: Splitter Exception when Closing and Opening Docking Panels
UPD: MySQL Provider
ADD: Get-CheckedNodes Helper Function for TreeView
ADD: Get-MSChartInstalled Helper Function for Chart
ADD: NotifyIcon Spotlight Article Link
UPD: NotifyIcon Helper Function
ADD: Speech Snippet which uses .NET to produce speech.
ADD: Option to expand aliases on a TAB press.

PrimalSQL 2011 v2.0.19

FIX: Splitter Exception when Closing and Opening Docking Panels
UPD: MySQL Provider

Technorati Tags: 2011, 2012, ChangeVue, PowerShell Studio, PrimalForms, PrimalScript, PrimalSQL, PrimalXML

Last time we told you about some new debugger features in PrimalScript 2012. And you already know all about the new Ribbon user interface this new version sports. One thing that we were really focused about in this version was to make navigating your code easier.

Since there is no “PrimalSense” toolbar anymore the method combo box that enabled you to jump between functions needed to find a new home.

If you load a file into PrimalScript 2012 you will notice the two new combo boxes on top of the edit window:

The right-hand combo box serves as an indicator for the current position as well as a quick way to jump to a specific function:

The left-hand box is a selector for the current scope. If you use only languages without support for classes, like PowerShell, you can skip the rest. But if you use VBScript, JScript, C# or other languages supporting classes then this is for you.

If you have a file with multiple classes you can select the scope on the left and then the function on the right. Just as with functions, the combo box also serves as a location indicator, so you know with just once glance which GetItem function you are currently working on.

Next time we will tell you about the other tabs on the ribbon and what they do.

Technorati Tags: Classes, Functions, JScript, powershell, PrimalScript 2012, scope, VBScript

The “Spotlight on Controls” series focuses on a single WinForms control in PowerShell Studio 2012, details the important Properties, Methods, and Events of the control and demonstrates how to utilize the control. Most of the information about the controls is still applicable to previous versions of PrimalForms.

Last time we took a look at the ListView control. This time we will look at the NotifyIcon control:

NotifyIcon [System.Windows.Forms.NotifyIcon]

Specifies a component that creates an icon in the notification area of the Window’s taskbar.

Default Event: MouseDoubleClick

Why use a NotifyIcon control?

Use the NotifyIcon control, to alert users of special events, such as when a task is completed. Typically this control is used for informational purposes, but it can also be used as a source for user interaction.

Note: When you add a NotifyIcon it will appear at the bottom of the Designer:

Important Properties:

BalloonTipText

This property sets the text associated with the balloon ToolTip. Use this property to display a message in the Balloon Tooltip.

Setting the BalloonTipText in the script editor:

$NotifyIcon.BalloonTipText = "This is the balloon text"

BalloonTipTitle

This property sets the title of the balloon ToolTip.
The title text is displayed above the balloon text.

BalloonTipIcon

This property sets the icon to associate with the balloon Tooltip. In other words, the icon displayed inside the tooltip itself.
Note: The BalloonTipTitle property must be set in order to view the balloon icon.

Values (Default: None):

None
No icon is displayed.

Info
An information icon.

Warning
A warning icon.

Error
An error icon.

Icon

This property sets the icon to display in the system tray.

Important: This property must be set; otherwise the tooltip balloon will not show!

The designer will allow you to browse and select an icon to display when the tooltip is shown.

Click on the browse button in the Property Panel:

Or use the menu in the designer:

Next select the Icon file

Finally the Icon will be displayed in the system tray:

Note: If a “phantom” icon remains in the system tray after closing the form, then it is recommended set the Visible property to False in order to clear the icon before closing form.

ContextMenuStrip

This property sets the shortcut menu to show when the user right-clicks the icon.
Set this property to an existing ContextMenuStrip in order to assign a menu to the system tray icon. See Spotlight on the ContextMenuStrip Control for more details.

Visible

This property indicates whether the icon is visible in the notification area of the taskbar.

Values (Default: True):

True / False

Important Events:

BalloonTipClicked

This event occurs when the balloon tip is clicked. Use this event to react to user clicks in the ToolTip balloon.

$notifyicon1_BalloonTipClicked={
    Write-Host 'The Balloon Tip was Clicked'
}

Clicked & DoubleClicked

These events occur when the system tray icon is clicked. If you need more information such as which mouse button was used, then it is recommended to use the MouseClick events (See below).

MouseClick

This event occurs when a user clicks on the system tray icon.

[System.Windows.Forms.LabelEditEventHandler]

$notifyicon1_MouseClick=[System.Windows.Forms.MouseEventHandler]{
#Event Argument: $_ = [System.Windows.Forms.MouseEventArgs]
    Write-Host "System Tray Icon Mouse Click: $($_.Button) Clicks: $($_.Clicks)"
}

MouseDoubleClick

These events occur when a user double clicks on a system tray icon. This event has the same arguments as the MouseClick event.

$notifyicon1_MouseDoubleClick=[System.Windows.Forms.MouseEventHandler]{
#Event Argument: $_ = [System.Windows.Forms.MouseEventArgs]
    Write-Host "System Tray Icon Mouse Double Click: $($_.Button) Clicks: $($_.Clicks)"
}

Important Methods:

ShowBalloonTip

This method displays a balloon tip in the taskbar for the specified time period.

[void] ShowBalloonTip([int] timeout)

Note: The method uses the properties of the NotifyIcon to display the balloon tip. Therefore they must be set before calling this method.

$NotifyIcon.ShowBalloonTip(0)

[void] ShowBalloonTip([int] timeout, [string] tipTitle, [string] tipText, [ToolTipIcon] tipIcon)

Note: This variation, displays a balloon tip with the specified title, text, and icon in the taskbar for the specified time period. You need not set the NotifyIcon’s properties if you use this method variation.

$NotifyIcon.ShowBalloonTip($Timeout, $BalloonTipTitle, $BalloonTipText, $BalloonTipIcon)

Helper Function:

The following is a helper function that allows you to display the NotifyIcon. The help function also assigns the calling executable’s icon, if the NotifyIcon’s Icon property hasn’t been assigned.

function Show-NotifyIcon
{
<#
    .SYNOPSIS
        Displays a NotifyIcon's balloon tip message in the taskbar's notification area.

    .DESCRIPTION
        Displays a NotifyIcon's a balloon tip message in the taskbar's notification area.

    .PARAMETER NotifyIcon
         The NotifyIcon control that will be displayed.

    .PARAMETER BalloonTipText
         Sets the text to display in the balloon tip.

    .PARAMETER BalloonTipTitle
        Sets the Title to display in the balloon tip.

    .PARAMETER BalloonTipIcon
        The icon to display in the ballon tip.

    .PARAMETER Timeout
        The time the ToolTip Balloon will remain visible in milliseconds.
        Default: 0 - Uses windows default.
#>
     param(
      [Parameter(Mandatory = $true, Position = 0)]
      [ValidateNotNull()]
      [System.Windows.Forms.NotifyIcon]$NotifyIcon,
      [Parameter(Mandatory = $true, Position = 1)]
      [ValidateNotNullOrEmpty()]
      [String]$BalloonTipText,
      [Parameter(Position = 2)]
      [String]$BalloonTipTitle = '',
      [Parameter(Position = 3)]
      [System.Windows.Forms.ToolTipIcon]$BalloonTipIcon = 'None',
      [Parameter(Position = 4)]
      [int]$Timeout = 0
     )

    if($NotifyIcon.Icon -eq $null)
    {
        #Set a Default Icon otherwise the balloon will not show
        $NotifyIcon.Icon = [System.Drawing.Icon]::ExtractAssociatedIcon([System.Windows.Forms.Application]::ExecutablePath)
    }

    $NotifyIcon.ShowBalloonTip($Timeout, $BalloonTipTitle, $BalloonTipText, $BalloonTipIcon)
}

Example Use:

Show-NotifyIcon -NotifyIcon $notifyicon1 -BalloonTipText $textboxText.Text `
 -BalloonTipTitle $textboxTitle.Text -BalloonTipIcon $combobox1.SelectedItem

You can download the NotifyIcon Sample from our Downloads section.

Technorati Tags: Controls, NotifyIcon, powershell, PrimalForms 2011, WinForm

VBScript users have told me on occasion that they are really jealous of one feature of PowerShell: Write-Debug

Depending on the value of $DebugPreference this produces output when needed but makes it easy to silence diagnostic output once a script moves to production.

VBScript and JScript developers have to sprinkle WScript.Echo calls through their code and then go and comment them out before handing the script off. In a large script with hundreds or even thousands of lines that can be a daunting and error prone task. You don’t want to disable real output and not forget any diagnostic output.

In PrimalScript 2012 VBScript and JScript users get help with that. Take a look at the following code:

The ‘TRACE comments are completely harmless and inactive if you just run the script. Execute that script in PrimalScript 2012′s debugger though and the output goes to the Debug pane. Think of it as a WScript.Debug.
You can use the same syntax and expressions you would normally use in a WScript.Echo call.

If you have to diagnose why the output from a SQL query fails after a few hundred records you certainly don’t want to sit there and single step through this or hit a breakpoint in each loop iteration. Add a TRACE statement to output unique field and when the script stops you see the last output and can easily take it from there.

Those of you paying attention have also already spotted the blue dot in the first screenshot and correlated it with the Tracepoint output in the second screenshot.

Tracepoints can be set and removed using Ctrl+F9 and are just as persistent as breakpoints if the file resides on an NTFS partition. So what are they for?

If you have a long running script and you are testing it you need some feedback if the script is actually moving along or is hanging somewhere. You can of course add a trace statement or a write-debug in PowerShell, but why type if you just need confirmation that your script is whizzing by a certain milestone. Adding a tracepoint is a single key combination and doesn’t affect your code at all. Obviously these are only active when your script runs in PrimalScript 2012′s debugger. They are available for VBScript, JScript and Windows PowerShell.

Next time we take a look at some new code navigation tools in PrimalScript 2012.

Technorati Tags: Debugger, JScript, powershell, PrimalScript 2012, Trace, VBScript

Last time we looked at the new script editor features. Now we will take a look at the new Function Explorer as well as other additions.

Function Explorer

The new Function Explorer displays a list of all the functions and events within the current script file:

If you are working within a Project, the available functions declared in other files will also be displayed.

Navigating with the Function Explorer:

Just by a simple double click on the function or event, it will take you directly to the declaration of the function. This becomes invaluable when dealing with scripts with a large number of functions.

Function Explorer Context Menu:

The context menu allows to do the following:

Go to Declaration
Goes to the function’s declaration (same as double clicking on the function name). If the function is in another project file, then it will navigate to that file.

Insert
Inserts a call to the function.

Copy
Copies the whole function definition to the clipboard.

Rename
Renames the function including all references to the function. Within Projects, it will also update references made to the function by other project files. If you rename an event, all the controls that reference the event will also be updated. As you can see this can be a big time saver when dealing with larger scripts.

Before Function Renaming:

After Function Renaming:

Other Additions and Changes:

PowerShell Studio offers many other performance improvement and other numerous minor additions, changes, and keyboard shortcuts that are not listed here. The following is some more prominent miscellaneous additions you will find:

Enhanced Console Input Line

The console now has an enhanced input line that offers the same PrimalSense support as the script editor. You have the option to enable or disable this feature.

Project File Renaming:

When renaming project files, reference functions will be updated accordingly through out the project files.

Before Project File Renaming:

After Project File Renaming:

Explicit Support For PowerShell Remoting:

PowerShell Studio now has explicit support for PowerShell Remoting. Use the “Run Remotely” option under the Run Menu:

Next you will be presented with a dialog to enter the remote credentials:

And finally the script will run on the remote computer.

Note: This feature requires that remoting be enabled on the target system.

Remote Debugging:

PowerShell Studio 2012 also supports Remote Debugging. This feature will be discussed in a separate article.

Tracepoints:

Just like PrimalScript 2012, PowerShell Studio added support for trace points. See the PrimalScript 2012: What’s New? articles for more details.

All in all, you will find that SAPIEN PowerShell Studio 2012 is a major improvement over its predecessor.

Technorati Tags: 2012, powershell, PowerShell Studio, PrimalForms, what's new what's changed

As promised last time we take a look at the new version of the Object Browser in PrimalScript 2012.

As soon as you click on the PowerShell node you will notice two things:

1. It opens a LOT faster. PrimalScript 2012 loads its information from a cache rather than instantiating a slow starting copy of PowerShell. This will actually come in handy in other aspects, which we will cover later.
2. You see a 32 bit and a 64 bit node. While PrimalScript 2011 already supported both platforms in almost every aspect, the PowerShell browser was a strictly 32 bit affair. Not anymore.

Having the platform distinction makes it possible for you to see if the snapin or module is actually available for you. Look closely at the following screenshot:

You will notice that the Applocker module and it’s cmdlets are only available in 64 bit. As before, if you have the Dynamic Help window visible, just selecting an item will show it’s help information:

If you don’t like additional windows docked in your IDE, just right click and select Help…

And the same text opens in the Document Explorer which, if you like, can be just parked on your secondary screen.

You can also use the “Google this…” topic on the context menu to get more information and maybe find samples online.

So that’s it for today. Next time we look at some new debugging features for VBScript/JScript users. There is also a little debugger enhancement for PowerShell users in it, so don’t miss it.

Technorati Tags: 32 bit, 64 bit, Object Explorer, powershell, PrimalScript 2012

Last time we looked at the new Control Sets. Now we will take a look at the new Script Editor features:

Improved Syntax Coloring

PowerShell Studio 2012 now colors cmdlet and functions parameters:

Convert Cmdlet & Aliases

Using the Context Menu or the Keyboard Shortcut you can convert your Cmdlets and Aliases. You can also convert from parameter aliases as well.

Improved PrimalSense

PowerShell Studio’s PrimalSense has also been greatly improved to increase your scripting productivity.

Improved Parameter PrimalSense Support:

Improvements include PrimalSense completion for Enumerators and Special Types:

Enumerator Code Completion:

PrimalSense for Special Types:

PowerShell Studio will now display PrimalSense for special types such as Cursors and Colors:

The improved PrimalSense will also display form control references:

Added Code Completion for Cmdlet and Function Parameters as well:

Parameter PrimalSense for Project Files:

When you define a parameter block in a Project File, they will now be reflected in the PrimalSense.

Code Completion for Methods:

A new feature that will help speed up your scripting is the new method completion.

Automatically insert the method parameters by pressing ‘Tab’:

You can Tab through each parameter and the PrimalSense will appear for the special types. Though you do not need to Tab complete the method parameters to benefit from the improved PrimalSense for special type arguments.

Improved Cmdlet PrimalSense:

PowerShell Studio improves PrimalSense support for various cmdlets such as the Get-WmiObject cmdlet:

As see can you,  PrimalSense for WMI namespaces and Classes are provided.

Script Navigation:

The Script Editor now has a new navigation menu which allows you to quickly navigate within your scripts.

The Navigate menu in the Ribbon offers:

Easy access to Bookmarks
Add/Remove Bookmarks as well as navigate to and between them.

Function Navigate
Go to the next and previous function/event declaration.

Change Navigation
Navigate to modifications made within your script file. Modification are denoted by a yellow and green indicators.

Occurrence Navigation
Navigate between occurrences of either variables, text or even cmdlets within your scripts.

Go to Last Edit Position
Press Ctrl + E and go to the last modification you made in the script.

Function Selection:

Triple click on the line number column of the editor and it will automatically select the whole function.

CmdletBinding Support:

Need to use CmdletBinding with your functions? Our PrimalSense now detects if a function uses CmdletBinding and displays the additional parameters the binding grants you.

Next: Part 5 – The new Function Explorer and other additions.

Technorati Tags: 2012, powershell, PowerShell Studio, PrimalForms, what's new what's changed

We get that question all the time. Before we start, please note that we do not advise to ever put credentials as plain text into any kind of code. Use encrypted strings, store encrypted credentials in files or, if all else fails, prompt. Now, having said that we all know that sometimes schedules and pressure from “above” forces you to do things you normally wouldn’t do. So for the sake of argument we have created a variety of executables which use SUPERADMINUSER and SUPERSTRONGPASSWORD to run a WMI query on SUPERSECRETSERVER.

We used

1. VBScript

   
   

2. PowerShell

   
   

3. C#

   
   

4. C++

   

Obviously all of these won’t run in your environment unless you create a server with that name and add those credentials.
If you want to examine the resulting executable files yourself, go to www.sapien.com/download and look for WMIQueryExecutables.zip in the “Blog Samples” folder.

Now we take all these files and open them in PrimalScript as binary files and look for the user id and password, starting with the C++ version.

And here is your password, easily visible in the binary data:

The spacing with NULL characters comes from the string being stored as unicode, so lets search for that in the C# version:

As you can see, we didn’t have to look far. To make matters worse, if you take a disassembly tool to a .NET exe you don’t even have to read binary data:

Now let’s try the script packages created by PrimalScript:

and

So you see, if you have to, absolutely have to put credentials somewhere, a packaged script is the way to go.
Go ahead, get the binaries and see for yourself. Here is where they are once again: Go to www.sapien.com/download and look for WMIQueryExecutables.zip in the “Blog Samples” folder.

Technorati Tags: c#, disassembler, Encryption, exeutable, password, powershell, Script package, username, VBScript