I have written a few posts on debugging using the PowerShell ISE lately. If you care to have a look, here are the links to ISE Debugging 101 and ISE Debugging 102. Those blog posts got newcomers to the ISE slightly more comfortable with the idea of debugging and the the specific tools offered in the ISE. I had a few questions and responses to these posts and I thought the best way to encapsulate this information was with a screen cast. I have taken what I covered and expanded it a bit to the realm of modules and how you can use the ISE debugging tools to work with Modules as easily as you can work with scripts and functions.

I hope you find this video helpful. I would love to hear any kind of feedback on the video, positive or negative. All I can say is that it is a bit easier to talk to yourself in front of a computer after a glass of wine   Seriously, feedback is greatly appreciated.

Andy

In my last post I gave a high level overview of how to get started with debugging in PowerShell 2.0, using the new Integrated Scripting Environment. In this installment, we are going to explore some of cmdlets that can be used to manipulate breakpoints.

First,  lets do some discovery. Whenever I am looking for cmdlets to work with something in particular, i use the get-command cmdlet with wildcards to help my search.

So from this it looks like we can get, set, enable, disable, and remove breakpoints. When we are setting breakpoints, you can specify the line and column you want to break on, but that can get really tedious. This is what the ISE does for you automatically when you toggle breakpoints. However, I find it much more useful to break when ever a variable is accessed.

Let’s use a basic function to demonstrate this.We’ll create a function foo and then set a breakpoint for the $c variable.

When we execute this code and call function foo, we get the output below. Notice that $a and $b is set, and that we break when we hit $c. One thing to note, when we specify the variable, we do not use the $ in front of the variable. This is the same as specifying the –outvariable common parameter for other cmdlets.

Last but not least, let’s take a look at how to navigate this “nested” prompt. If you type “?” or “h”, you will get the following information It is interesting that the “nested>” prompt displays this when you hit “?.” Under normal circumstances, the “?” is an alias for where-object, as we can see when we type ? at a normal prompt.

I hope this helps you with debugging your scripts.

I have always found the origin of words to be fascinating.  Apparently, the terms bug and debugging in regards to computers are attributed to Admiral Grace Hopper in the 1940’s.

While she was working on a Mark II Computer at Harvard University, her associates discovered a moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system.

When I first started scripting and writing a little code, the concept of debugging something seemed really hard. However, I have found that with a few simple steps I can debug most of my scripts pretty quickly.

Ninety nine percent of the time, debugging scripts requires being able to watch a variable at some point in a script or a function. Have you ever written a function and thought, “If only I knew what x was before y started messing with it?”

The PowerShell Integrated Scripting Environment makes this pretty easy. You can set a breakpoint on any line in the ISE using the Debug Menu and choosing “Toggle Breakpoint.” or by using the F9 shortcut key.

When you toggle a breakpoint on and then run the script, the script will stop at that point. You should note that at this point, the highlighted line has not been executed yet.

Here’s what it looks like when you hit a breakpoint. You get thrown into a nested prompt where you can poke around and look at any variables you want to. Notice the >>> prompt and notice $b has not yet been set, but $a has.

Now that you are paused right around the line of code you want to check out, you can use the “Step Into” Feature.

This will execute the next line of code in the script (the highlighted line) and then stop.

Now you can see that $b has been set but $c doesn’t have a value yet.

You can continue to step through as much as many lines as you need to until you see something that is not quite right.

This is just the beginning of what we can do in regards to debugging scripts and functions. In the next couple weeks I plan to share more as I learn about debugging and the ISE. Just to whet your appetite, you can run the command get-command –noun psbreakpoint to see what kinds of goodies await!

Currently, there are no default UI options to set the color for the Script Pane, the Command Pane, or the Output Pane. However, these can all be changed using $psISE.

I wrote a few functions to help with this.

function Set-CommandBackPaneColor {
param
(
    [parameter(Mandatory=$true,ValueFromPipeline=$true)]
    $color
)
    $psise.Options.CommandPaneBackground = $color
}

function Set-OutputPaneColor {
param
(
    [parameter(Mandatory=$true,ValueFromPipeline=$true)]
    $color
)
    $psise.Options.OutputPaneBackground = $color
    $psise.Options.OutputPaneTextBackground = $color
}

function Set-ScriptPaneColor {
param
(
    [parameter(Mandatory=$true,ValueFromPipeline=$true)]
    $color
)
    $psise.Options.ScriptPaneBackground = $color
}

Automatically generated with a custom version of Write-CommandBlogPost

Set-OutputPaneColor sets two options, OutputPaneBackground and OutputPaneTextBackground. I have found that I like to have these the same, but you can easily separate them out if you like.

The last little tidbit is figuring out how to get a color picker rather than typing in the name of the color. We can accomplish this with a little Winforms action.

function Get-Color {
    $colorDialog = new-object System.Windows.Forms.ColorDialog
    $colorDialog.AllowFullOpen = $false
    [void]$colorDialog.ShowDialog()
    $colorDialog.Color.Name
}

Automatically generated with a custom version of Write-CommandBlogPost

This will return the name of the color that was picked

After clicking on Red, I get the following output

So now we can tie this all together with one final line to add a custom menu to ISE

[void]$psISE.CustomMenu.Submenus.Add("Output Pane Color", {Get-Color | Set-OutputPaneColor},$null)

I just passed in Null because I didn’t want a keyboard shortcut, but you can use one pretty easily.

So now I get the following:

I could set up Menus to set other color options for the script and command panes as well, but I figure that is enough screenshots to make the point.

The other custom commands are from Karl Prosser. I highly recommend you take a look at them as well. Very useful.

So there is one (not so subtle) flaw in the get-color function. It does not always place the color dialog on the top, so sometimes I have to Alt-Tab over to it. There is probably some nifty way with winforms to make it show up on top all the time, but I figured I would get this out there and then work on that little part.

Secondly, not all the colors work right now.

Granted, PowerShell doesn’t always come with all the features you need right out of the box. However, because we have the power of .NET and an awesome scripting language, we can pretty much do whatever we need to do and we don’t have to wait for the PS team to ship V-Next.

The PowerShell team has taken this philosophy into the development of the ISE as well. In a couple previous posts here and here, I have talked about some very basic customizations using the $PSISE variable that comes with the Scripting Integrated Environment.

One thing I love about PS V2 is Advanced Functions. The only bummer is there is a lot of boilerplate text for each one. This sounds like a perfect opportunity for a code snippet. We can add some functions to our $PROFILE in the PowerShell ISE to make this happen.

First of all, we need to open our $profile script. It probably doesn’t exist so you can do the following. Note that the ISE is a PS host and it has its own profile, different than the one for PowerShell.exe that you use in Console.Exe.

new-item -type file -force $profile

Now we can open it in the ISE with the following line

$psise.CurrentOpenedRunspace.OpenedFiles.Add($profile) 

Now that we have the $profile open, we can create a function that will insert some text into the file that is currently being edited.

function Insert-Text
{
param(
    [parameter(Mandatory=$true, ValueFromPipeline=$true]
    [string]
    $text
    )
$currentFilePath = $psise.CurrentOpenedFile.FullPath
$currentFile = $psIse.CurrentOpenedRunspace.OpenedFiles |
               where {$_.FullPath -eq $currentFilePath}
$currentFile.editor.InsertText($text)
}

This function will insert text into the current script at the cursor’s location.

Now we need to write the actual snippet, which can also be a function

function New-FunctionTemplate
{
$f = @"
function Verb-Noun {
param (
    [parameter(Mandatory=$true, ValueFromPipeline=$true)
    [string]
    $p1
)
begin {}
process {}
end {}
}
"@
Insert-Text -text $f
}

The last line uses the Insert-Text function that we just created and inserts the snippet that is stored in the HereString $f.

Now we need to put it together and create a shortcut key and a new custom menu to insert this text.

$psIse.CustomMenu.Submenus.Add("_Function Template", {New-FunctionTemplate}, "Alt+F")

For this particular instance, I chose the name New FunctionTemplate and used Alt F for the keyboard shortcut.

You can add custom menus using $PSISE in the PowerShell Integrated Scripting Environment. Quite simply, you create a custom menu, assign it a scriptblock, and a keyboard shortcut. For example, lets say you wanted Ctrl-D to always run the dir (get-childitem) command.

You can use the CustomMenu class like so.

   1: $psIse.CustomMenu.Submenus.Add("_Dir", {dir}, "Ctrl+D")

In addition to the keyboard shortcut, you also get a menu as well.

Now when you hit Ctrl-D, it will run the dir command. All kinds of cool things are available within the editor with the new object model.

Graphical PowerShell, also known as the PowerShell Scripting Environment (ISE) can be customized using an object model.

There is a variable called $psISE in the ISE.

   1: PS >$psise | gm | select Name

   2:  

   3: Name                                                                           

   4: ----                                                                           

   5: Equals                                                                         

   6: GetHashCode                                                                    

   7: GetType                                                                        

   8: ToString                                                                       

   9: CurrentOpenedFile                                                              

  10: CurrentOpenedRunspace                                                          

  11: CustomMenu                                                                     

  12: OpenedRunspaces                                                                

  13: Options              

In there we have options, customMenus, and a number of other cool things. Here we can change the Scripting Pane color to “black”