PowerShellGet-GUI Part 2

Continuing on from where we left off in our last blog post entitled “PowerShellGet-GUI part 1″, let us examine some of the other features of the PowerShell Get GUI application.

With our list successfully loaded with PowerShell Gallery modules, the user can take several actions:

1. Select a module to inspect it’s properties
2. Select a non-installed module to install it
3. Select an installed module to uninstall it

Case 1

Figure 1

When the user clicks on an item in the list, the listview_ItemSelectionChanged event fires and is handled by our $lvModules_ItemSelectionChanged event handler seen in Figure 1 above. If an item has been selected, we first save the contents of the .Tag property to a local variable, $module. If you remember back to the previous post, when we filled our list we stored the actual module in the .Tag property for later access. See this article for more detailed information about the TAG property.

We then set a “wait” cursor, clear the details pane (top right of UI), then call Get-Member on the module and store the string output to $output. We assign that string output to the .text property of the details pane and return our cursor to the default arrow. We also set several menu options to enabled to create a good UI.

Case 2

A module from the list can be installed by selecting the File->Install Selected Module menu option or by right-clicking the module and selecting Install.

Figure 2

Figure 2 shows the code that is executed when that menu option is selected. First we get the module name and present a verification dialog to the user. If the user clicks OK in the dialog, then we set a wait cursor. Next we call Install-Module with the module name, PSGallery as the repository, and scope it to the current user. The output of these commands is converted to a string and output to the OutPut pane at the bottom of the application. We update our list view which will put a checkmark on the module. Finally, we set our cursor back to the default arrow.

Case 3

An installed module can be uninstalled by electing the File->Uninstall Selected Module menu option or right-clicking on the module and selecting Uninstall.

This is probably our simplest event handler. The code in figure 3 uses Try…Catch to handle any errors. In the Try section, we call Remove-Module using the text found in the first element of the list views .selectedItems array. Since there is only 1 selected item (set by an object property) we know that it will be the “0” item and the text for that selection is the module name. If this fails, then we show the error in the output pane.

Finally

There is a lot more going on in this application than what this post and its predecessor describe. Setting object properties, enabling and disabling menu options, etc. all work together to make a great user interface. There is plenty more that can be done with this app and we invite the community to experiment and make suggestions.

 
Follow @SAPIENTech