Struggling to find documentation for PowerShell’s Add_Click method? You’re not alone. Learn why it’s “hidden” and discover three practical solutions to handle button events in your WinForms scripts, from the quick fix to the architect’s approach.

Where Did Microsoft Hide the ‘Add_Click’ Docs? A Senior Engineer’s Guide

I remember it was pushing 10 PM. We had a critical user de-provisioning script that had to run before the nightly backup kicked off on prod-db-01. The script, a simple PowerShell GUI form, was supposed to be a “quick win” for our new junior engineer. Instead, he was stuck. The “Execute” button did nothing. He was frantically searching Get-Help *Click* and coming up empty. He’d been banging his head against the wall for two hours over something that isn’t even technically a PowerShell command. We’ve all been there, lost in a documentation rabbit hole for something that seems like it should be simple. That night, it wasn’t just about fixing the script; it was about explaining the “why.”

The Root of the Problem: You’re Not in Kansas (or PowerShell) Anymore

Here’s the secret that trips everyone up: When you’re building a GUI with System.Windows.Forms in PowerShell, you’re not really writing PowerShell anymore. You’re using PowerShell as a host to manipulate the .NET Framework. The button object you created? It’s a .NET object, specifically a System.Windows.Forms.Button. Its methods and events, like Add_Click, aren’t PowerShell cmdlets. They are .NET event handlers.

This is why Get-Help fails you. You’re looking for PowerShell documentation for a .NET concept. The real docs live on Microsoft’s .NET API reference pages, which can feel like a completely different universe. The Add_Click method is PowerShell’s way of letting you “subscribe” a block of code to the button’s “Click” event.

Solution 1: The Quick and Dirty (But Effective) Fix

This is the one you’ll see in 90% of online examples, and for good reason: it works and it’s easy to read. You simply call the Add_Click() method on your button object and pass it a script block {...} containing the code you want to run.

Let’s say you have a button named $runButton.

# Assume $runButton is a System.Windows.Forms.Button object you already created

$runButton.Add_Click({
    # This code runs when the button is clicked
    Write-Host "Button was clicked! Starting process..."
    $form.Close()
})

Pro Tip: This method is perfectly fine for simple scripts and quick tools. Don’t let anyone tell you it’s “wrong.” If it’s a 50-line script to automate a simple task for the helpdesk, this is the way to go. It’s clean, direct, and gets the job done.

Solution 2: The “Proper PowerShell” Eventing Model

If you want to handle events in a way that feels more integrated with PowerShell’s job and event engine, you can use Register-ObjectEvent. This is more verbose but gives you more control and is fantastic for long-running tasks you might want to manage as a background job.

This approach separates the “what” from the “when.”

# Assume $runButton is a System.Windows.Forms.Button object

# Step 1: Register that we are listening for the 'Click' event
Register-ObjectEvent -InputObject $runButton -EventName "Click" -SourceIdentifier "MyButtonClick"

# Step 2: Create a loop or wait for the event.
# The action happens in the background. You need to fetch the result.
# This is a simplified example. In a real script, you'd have a loop checking for events.
Wait-Event -SourceIdentifier "MyButtonClick"
Write-Host "Event triggered! The button was clicked."
# Clean up the event subscription
Unregister-Event -SourceIdentifier "MyButtonClick"

This is overkill for a simple “OK” button that closes a form, but if that button kicks off a 10-minute server patching process, this model is far superior for managing the job.

Solution 3: The Architect’s “Nuclear” Option (PowerShell Classes)

When your simple GUI tool starts getting more complex, with multiple forms, custom controls, and shared logic, you’re not writing a script anymore; you’re building an application. At this point, wrapping your form logic in a PowerShell Class (available in PS v5 and later) is the cleanest, most maintainable, and most reusable solution.

This is where you abstract the messy form setup away and treat it like a proper object.

# This requires PowerShell 5.0+
Add-Type -AssemblyName System.Windows.Forms

class MyConfirmationDialog {
    # Properties
    [System.Windows.Forms.Form] $Form
    [System.Windows.Forms.Button] $OkButton
    [bool] $Result

    # Constructor
    MyConfirmationDialog() {
        $this.Form = New-Object System.Windows.Forms.Form
        $this.OkButton = New-Object System.Windows.Forms.Button
        $this.OkButton.Text = "OK"
        $this.Form.Controls.Add($this.OkButton)

        # Event handler is a method of the class
        $this.OkButton.Add_Click({ $this.HandleClick() })
    }

    # Method to handle the click
    HandleClick() {
        $this.Result = $true
        $this.Form.Close()
    }

    # Method to show the dialog
    [bool] Show() {
        $this.Form.ShowDialog()
        return $this.Result
    }
}

# --- How you would use it ---
$dialog = [MyConfirmationDialog]::new()
$wasClicked = $dialog.Show()

if ($wasClicked) {
    Write-Host "User clicked OK!"
}

Warning: This is absolutely not for a beginner’s first script. But when your “simple tool” is on version 4 and has been passed between three different engineers, this level of organization will save your sanity. It turns a chaotic script into a predictable, testable component.

So, Which One Should You Use?

My advice is always to match the solution to the problem’s scale.

The next time you’re stuck on something that feels “undocumented” in PowerShell, take a step back and ask: “Am I using a PowerShell cmdlet, or am I playing with a .NET object?” That single question can save you hours of frustration and point you in the right direction. Happy scripting.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions