System windows forms dialogresult powershell

PowerShell is an advanced shell with integration of .NET objects. It’s more than just a replacement for the older cmd.exe. It can work with .NET assemblies, process large datasets and even interact with web services.

Because of the .NET assemblies support, it can work with WinForms (or even WPF), making it possible to create scripts with GUIs.

Requirements

This has been tested to work with Windows PowerShell verion 5.1. It’s likely going to work with older versions as well, but it’s not going to work with the new cross-platform PowerShell (there are no WinForms on Linux/macOS). You can check the version with

Get-Host | Select-Object version

Setting up the environment

Before we can start, let’s check a few things.

The first one is the script execution policy. It controls which scripts can be run. By default, Windows blocks execution of all scripts (more on that here). We have to allow it to run local scripts that are not digitally signed. It’s possible to do this this either by going through Windows Settings > Updates & Security > For developers, checking the Change execution policy… checkbox and clicking Apply, or just executing

Set-ExecutionPolicy RemoteSigned

from administrator PowerShell.

Another (less important) thing is the code editor. Even though we could just write the entire script directly in PowerShell, it’s easier to use a full-featured editor with error checking and syntax highlighting. Windows already comes with PowerShell ISE (Integrated Scripting Environment), but you can use Visual Studio Code with the PowerShell extension.

Writing our script

Let’s start!

Importing the assemblies

We have to import both System.Windows.Forms and System.Drawing assemblies. It’s possible to only include the first one but we also need the 2nd to specify control sizes.

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

You can test it by creating a blank form:

$form = New-Object System.Windows.Forms.Form
$form.ShowDialog()

Картинка с сайта: dev.to

Adding controls

Let’s make a «Hello World» form. First, we create a top-level Form object:

$form = New-Object System.Windows.Forms.Form
$form.Text = "Some form"
$form.Size = New-Object System.Drawing.Size(150, 145)
$form.AutoSize = $true

In PowerShell, objects are created using New-Object. You can also pass parameters to constructors, similar to the new keyword in C#. Values are assigned to properties directly. Another difference is using $true instead of just true.

Let’s add a label and a button:

$lbl1 = New-Object System.Windows.Forms.Label
$lbl1.Text = "Hello World!"
$lbl1.Location = New-Object System.Drawing.Point(30, 20);

$btn = New-Object System.Windows.Forms.Button
$btn.Text = "Close"
$btn.location = New-Object System.Drawing.Point(30, 60);
$btn.DialogResult = [System.Windows.Forms.DialogResult]::OK

The $btn.DialogResult line tells the form what to return when the button is clicked. You can use this to figure out whether the user clicked OK or Cancel. We also make $btn the default button and lay controls onto the form:

$form.AcceptButton = $btn
$form.controls.Add($lbl1)
$form.controls.Add($btn)

All that’s left is showing the form itself:

$form.ShowDialog()

Картинка с сайта: dev.to

Event handlers

In our form, $btn is the default OK button which just terminates the form. But we can use non-terminating event handlers as well. For example, let’s make it possible to click on the label:

$lbl1.Add_Click({
    [System.Windows.Forms.MessageBox]::Show("Hey!")
})

You can call functions from event handlers as you normally would.

Visual Styles

Something I’ve noticed with these GUI scripts is that different control styles are used when the script is run from the PowerShell console instead of VSCode. The console uses legacy rendering which falls back to using Windows 95-style controls. We need to enable Visual Styles to fix that:

[System.Windows.Forms.Application]::EnableVisualStyles()

From here on, you can add more controls and event handlers. If you’ve used C#/VB.NET before you can reuse large parts of that knowledge to create nicer and more powerful scripts.

That’s it for now 😉

The full script:

Add-Type -AssemblyName System.Windows.Forms
Add-Type -AssemblyName System.Drawing

[System.Windows.Forms.Application]::EnableVisualStyles()

$form = New-Object System.Windows.Forms.Form
$form.Text = "Some form"
$form.Size = New-Object System.Drawing.Size(150, 145)
$form.AutoSize = $true

$lbl1 = New-Object System.Windows.Forms.Label
$lbl1.Text = "Hello World!"
$lbl1.Location = New-Object System.Drawing.Point(30, 20);

$lbl1.Add_Click({
    [System.Windows.Forms.MessageBox]::Show("Hey!")
})

$btn = New-Object System.Windows.Forms.Button
$btn.Text = "Close"
$btn.location = New-Object System.Drawing.Point(30, 60);
$btn.DialogResult = [System.Windows.Forms.DialogResult]::OK

$form.AcceptButton = $btn
$form.controls.Add($lbl1)
$form.controls.Add($btn)

$Null = $form.ShowDialog()

This article discusses the DialogResult property of buttons, which often confuses beginning PowerShell GUI app designers.

When I first started learning how to write PowerShell GUI applications, I thought of the DialogResult property of buttons as the “evil property.”

Картинка с сайта: info.sapien.com

What else would I think? If the DialogResult property of a button is set to any value other than None, when you click the button, the GUI app closes immediately after running the commands in my event handler.

In this little app, when you click OK, it pipes a Get-Service command to Out-GridView — um, very briefly.

Your browser does not support HTML5 video.

After banging my head against the wall (and then searching the SAPIEN Information Center), I realized that my app closes immediately because the DialogResult property of the OK button is set to OK.

The app also closes immediately when the DialogResult value is Cancel, Abort, Retry, Ignore, Yes, or No. When the value of the DialogResult property of a button is None, the app works perfectly.

So DialogResult is evil, right?

Картинка с сайта: info.sapien.com

The First Use of DialogResult

I’m new to GUI apps, but the science and art of user experience and computer-based user interfaces is decades old. When I design my PowerShell GUI apps, I’m standing on the shoulders of people who’ve studied user experience as a discipline. I want to learn from them.

And, they’ve learned that uniformity and predictability make buttons usable. If my OK button does the same thing as your OK button, and almost every other OK button, our users learn how the OK button works. If, instead, my OK button opens a box and your OK button finds a file, the user needs more guidance before clicking OK.

You might rely on each developer to do the right thing. It’s easy enough to write a Click event handler for the button that closes the form.

$buttonOK_Click={
    form1.Close()
}

But, it’s much easier to standardize button behavior. That’s what DialogResult tries to do.

$buttonOK.DialogResult = OK

And, if the behavior of OK buttons changed, the .NET folks would only have to change what the OK value does. Developers worldwide wouldn’t have to rewrite the Click event handlers of their buttons.

It reminds me of all of the things we do in PowerShell to create a more predictable experience, including using approved verbs and common parameters. It might frustrate developers at times, but it’s really much better for users.

The Second Use of DialogResult

Actually, the DialogResult values do a lot more than just close the form. Their primary job is to tell a parent form which user action closed its child form.

Here’s the model. You start with a parent form (Main Form). When you click a button (like “Open child form”) on the parent form, the child form opens. When you close the child form, the system returns the DialogResult value of the closing action to the parent form.

(Want to learn how to create a parent and child form? Passing and returning values using forms)

Картинка с сайта: info.sapien.com

In this example, the text on each of the buttons matches its DialogResult value. For example, the Retry button has a DialogResult value of Retry.

>

Картинка с сайта: info.sapien.com

When the user clicks the ‘Retry’ button, the system returns a value of ‘Retry’ to the parent form. The parent form can use the DialogResult value.

For example, here is the Click event handler for the Open child form button. The Call-ChildForm_psf function opens the child form. When the child form closes, the system returns the DialogResult value as output. You can ignore the DialogResult value or you can capture the DialogResult value and use it. For example, this event handler assigns the DialogResult value to the Text property of the RichTextbox, so the value is displayed in the RichTextbox.

$buttonOpenChildForm_Click = {
    $richtextbox1.Text = Call-ChildForm_psf
}

Now, when you click a button that closes the child form, the DialogResult value appears in the RichTextbox.

Your browser does not support HTML5 video.

There are many practical uses of this functionality. For example, this the app reacts differently to each DialogResult value. The button’s Click event handler opens the child form (Call-ChildForm_psf) and saves the DialogResult in the $dr variable. Then, it uses a Switch statement to respond to the DialogResult value in the $dr variable.

$buttonOpenChildForm_Click = {
    do
    {
        $dr = Call-ChildForm_psf
        $retry = $false
 
        switch ($dr)
        {
            OK { $richtextbox1.ForeColor = 'Green'; break; }
            Cancel { $richtextbox1.ForeColor = 'Red'; break; }
            No { $formMain.Close() }
            Retry { $richtextbox1.ForeColor = 'Red'; $retry = $true; break; }
            default { $richtextbox1.ForeColor = 'Black'; break; }
        }
        $richtextbox1.Text = $dr
    }
    while ($retry -eq $true)
}

Here’s the result:

Your browser does not support HTML5 video.

DialogResult in a Message Box

You might not work with parent and child forms, but you can use DialogResult in a message box, too. The MessageBox control is a child of its parent form.

I often use message boxes to display errors to users. For example, in the Click event handler for a Start button, I run a Get-Service command, but if it fails, I use a Try-Catch block to catch errors and display them in a message box. To create the message box, I use the msgbox preset snippet in PowerShell Studio.

$buttonStart = {
    Try {
        Get-Service -ComputerName $textboxCn.Text.Trim() | Out-GridView
    }
    Catch {
        [void][System.Windows.Forms.MessageBox]::Show('Cannot get services from the specified computer', 'Computer name error')
    }
}

Notice that the output type on the MessageBox snippet is [void], which means $null or “nothing.” It’s like piping the output of a command to the Out-Null cmdlet. But, if you don’t void out the output, the system returns the DialogResult value of the control that closed the message box.

In this code, I save the DialogResult output in the $dr variable. Also, I selected an argument list (“overload”) for the Show method that creates a message box with Yes and No buttons that return a DialogResult of Yes and No, respectively. In the Catch block, the error message asks the user if they want to get services on the local machine. If they say ‘Yes’, it runs a Get-Service command locally. Otherwise, it just displays the parent form again.

$buttonStart = {
    Try {
        Get-Service -ComputerName $textboxCn.Text.Trim() | Out-GridView
    }
    Catch {
        $dr = [System.Windows.Forms.MessageBox]::Show('Failed. Get services on local computer?', 'Computer name error', 'YesNo')
        if ($dr -eq 'Yes') { Get-Service | Out-GridView }
    }
}

This is just one of many possible uses of DialogResult in a message box.

Fixing DialogResult Errors: Add a button

Most PowerShell Studio users first encounter the DialogResult property when they use the Dialog Style Template.

The Dialog Style Template is awesome because it creates a fixed-size (not resizable) GUI app with no minimize or maximize buttons, so you don’t have to worry about controls floating around on your form when the end-user resizes the box.

Картинка с сайта: info.sapien.com

But, because it follows best-practice standards, the OK button in the Dialog Style Template has a DialogResult value of OK.

Картинка с сайта: info.sapien.com

If you try to re-purpose the OK button by writing an event handler for it, it runs the event handler and then closes immediately — and rather abruptly.

$buttonOK_Click={
    Get-Service | Out-GridView
}

To fix the problem, you can set the DialogResult property of the OK button to None. That fixes your app, but it breaks the best practice expectation of how OK buttons work.

Instead, add a button that doesn’t have an expected purpose (not one of the DialogResult values), like this Start button, and set its DialogResult property to None.

Then, move the feature code to the Click event handler for the Start button. To make sure that I don’t misuse the OK button, I add a comment reminding me about the DialogResult value.

$buttonOK_Click={
    #DialogResult = OK
}
 
$buttonStart_Click={
    Get-Service | Out-GridView
}

Now that I understand DialogResult, I realize that it’s not really evil. It’s helps to enforce best practice standards and I can even use productively. I can’t quite say I love it, but I certainly have a crush on it.

June Blender is a technology evangelist at SAPIEN Technologies, Inc. You can reach her at This email address is being protected from spambots. You need JavaScript enabled to view it. or follow her on Twitter at @juneb_get_help.

Sometimes while a powershell script is running you want to show a MessageBox with a information or warning to the user. In Windows Powershell no Commandlet exists to show a Message Box.

Nevertheless it is possible by using the .NET Windows.Forms.MessageBox class:-).

First of all load the assembly.

# Load assembly
[System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")

To show the messagebox call the static function show(“Message Text”)

$oReturn=[System.Windows.Forms.Messagebox]::Show("This is the Message text")

The function returned a value of enum System.Windows.Forms.DialogResult, that indicates which Button was pressed.
Possible Returncodes, depending on which button was pressed, are:

[system.enum]::getValues($oReturn.GetType())
None
OK
Cancel
Abort
Retry
Ignore
Yes
No

The default Button is the OK Button, there are further 5 combinations, see below.

[system.enum]::getNames([System.Windows.Forms.MessageBoxButtons])|foreach{[console]::Writeline("{0,20} {1,-40:D}",$_,[System.Windows.Forms.MessageBoxButtons]::$_.value__)}
                  OK 0
            OKCancel 1
    AbortRetryIgnore 2
         YesNoCancel 3
               YesNo 4
         RetryCancel 5

An Example, a Message box with an Ok and a Cancel button and a check which button was pressed:

$oReturn=[System.Windows.Forms.MessageBox]::Show("Message Text","Title",[System.Windows.Forms.MessageBoxButtons]::OKCancel)	
switch ($oReturn){
	"OK" {
		write-host "You pressed OK"
		# Enter some code
	} 
	"Cancel" {
		write-host "You pressed Cancel"
		# Enter some code
	} 
}

Some examples

you can also use the number instead of the numeric constants to specify the buttons

[System.Windows.Forms.MessageBox]::Show("Message Text","Title",1)

This oneliner shows all possible Button combinations consecutively

[system.enum]::getValues([System.Windows.Forms.MessageBoxButtons])|foreach {[System.Windows.Forms.MessageBox]::Show("["+$_.GetType()+"]::"+$_.ToString(),"Message box Buttons",$_)}

You can style the message box with an icon, 4 are available

[system.enum]::getNames([System.Windows.Forms.MessageBoxIcon])|foreach{[console]::Writeline("{0,20} {1,-40:D}",$_,[System.Windows.Forms.MessageBoxIcon]::$_.value__)}
                None 0
                Hand 16
               Error 16
                Stop 16
            Question 32
         Exclamation 48
             Warning 48
            Asterisk 64
         Information 64

Example:

[System.Windows.Forms.MessageBox]::Show("Message Text","Title",[System.Windows.Forms.MessageBoxButtons]::OKCancel,[System.Windows.Forms.MessageBoxIcon]::Warning)

Same with numbers instead of numeric constants

[System.Windows.Forms.MessageBox]::Show("Message Text","Title",1,48)

the remaining…

All available icons consecutively

[system.enum]::getValues([System.Windows.Forms.MessageBoxIcon])|foreach {[System.Windows.Forms.Messagebox]::Show("["+$_.GetType()+"]::"+$_.ToString(),"Message box Icons",[System.Windows.Forms.MessageBoxButtons]::OK,$_)}

Michael