ErrorProviderを極めよ：Windows Formsにおける堅牢かつエレガントな入力検証アーキテクチャ
レガシーシステムの保全、そして現場の泥臭い要件とモダンなUIの融合。我々が向き合うWindows Formsアプリケーションにおいて、入力検証（バリデーション）は永遠の課題である。
「保存ボタンを押すまでエラーに気づかない」
「メッセージボックスが連続してポップアップし、ユーザーをイライラさせる」
「どのコントロールに不備があるのか視覚的にわかりにくい」
これらを解決するのが `ErrorProvider` コンポーネントだ。しかし、IDEのデザイナに配置してプロパティをポチポチ触るだけでは、現場の複雑な業務ロジックには耐えられない。本稿では、`ErrorProvider` の内部挙動とイベント駆動のライフサイクルを完全に掌握し、メモリリークを排除しながらスマートなリアルタイム検証と一括チェックを両立する実践的アーキテクチャを解説する。
—
1. ErrorProviderの根本的メカニズムとライフサイクルの真実
`ErrorProvider` は、一見すると軽量なコンポーネントに見えるが、内部では対象コントロールとの間でメッセージフックやウィンドウプロシージャのサブクラス化を行っている。ここで最も恐ろしいのは、不適切なインスタンス管理とイベントハンドラのデタッチ忘れによるメモリリークだ。
特にMDIフォームや動的に生成・破棄されるユーザーコントロール上で運用する場合、`ErrorProvider` が参照を保持し続けた結果、GC（ガベージコレクタ）がコントロールを回収できなくなる現象が頻発する。
これを防ぐための鉄則は以下の通りだ：
1. `ErrorProvider` はフォームのライフサイクルと完全に同期させる（原則として `Form` クラスのメンバ変数として定義）。
2. コントロールを動的に破棄する際は、必ず `ErrorProvider.SetError(control, String.Empty)` を明示的に呼び出して関連付けを解除する。
—
2. 実装：リアルタイム検証と一括チェックの完全統合クラス
単にイベントを乱立させるのではなく、バリデーションロジックを一元管理する「バリデーション・オーケストレーター」の概念を導入する。
以下のコードは、VB.NETによる堅牢な実装例である。リアルタイムの `Validating` イベントによる即時フィードバックと、送信前の網羅的チェック（一括検証）を美しく調和させている。
Imports System.Windows.Forms
Imports System.Drawing
Public Class CustomerForm
Inherits Form
‘ UIコンポーネントの宣言
Private WithEvents txtCustomerName As New TextBox()
Private WithEvents txtPostalCode As New TextBox()
Private WithEvents btnSubmit As New Button()
‘ ErrorProviderのインスタンス（フォームのライフサイクルに依存）
Private ReadOnly m_ErrorProvider As New ErrorProvider()
Public Sub New()
MyBase.New()
Me.InitializeComponentCustom()
Me.InitializeValidatorSettings()
End Sub
”’
”’
Private Sub InitializeComponentCustom()
Me.Width = 500
Me.Height = 300
Me.Text = “顧客情報入力”
‘ 顧客名テキストボックス
txtCustomerName.Location = New Point(30, 30)
txtCustomerName.Width = 300
Me.Controls.Add(txtCustomerName)
‘ 郵便番号テキストボックス
txtPostalCode.Location = New Point(30, 80)
txtPostalCode.Width = 150
Me.Controls.Add(txtPostalCode)
‘ 送信ボタン
btnSubmit.Location = New Point(30, 140)
btnSubmit.Text = “登録実行”
Me.Controls.Add(btnSubmit)
End Sub
”’
”’
Private Sub InitializeValidatorSettings()
With m_ErrorProvider
.BlinkStyle = ErrorBlinkStyle.AlwaysBlink
.BlinkRate = 250 ‘ 点滅間隔（ミリ秒）
End With
‘ デザイナを使用せず、コード側でValidatingイベントをフック
AddHandler txtCustomerName.Validating, AddressOf ValidateCustomerName
AddHandler txtPostalCode.Validating, AddressOf ValidatePostalCode
End Sub
”’
”’
Private Sub ValidateCustomerName(sender As Object, e As System.ComponentModel.CancelEventArgs)
Dim ctrl As TextBox = DirectCast(sender, TextBox)
If String.IsNullOrWhiteSpace(ctrl.Text) Then
m_ErrorProvider.SetError(ctrl, “顧客名は必須入力です。”)
‘ 必要に応じてフォーカスを維持する場合は e.Cancel = True とするが、
‘ ユーザーの離脱を妨げるUX上のハラスメントにならないよう注意が必要
ElseIf ctrl.Text.Length > 50 Then
m_ErrorProvider.SetError(ctrl, “顧客名は50文字以内で入力してください。”)
Else
‘ エラーなしの場合はクリア
m_ErrorProvider.SetError(ctrl, String.Empty)
End If
End Sub
”’
”’
Private Sub ValidatePostalCode(sender As Object, e As System.ComponentModel.CancelEventArgs)
Dim ctrl As TextBox = DirectCast(sender, TextBox)
Dim postalPattern As String = “^\d{3}-\d{4}$”
If String.IsNullOrWhiteSpace(ctrl.Text) Then
m_ErrorProvider.SetError(ctrl, “郵便番号は必須です。（例: 100-0001）”)
ElseIf Not System.Text.RegularExpressions.Regex.IsMatch(ctrl.Text, postalPattern) Then
m_ErrorProvider.SetError(ctrl, “郵便番号の形式が不正です（XXX-XXXX形式）。”)
Else
m_ErrorProvider.SetError(ctrl, String.Empty)
End If
End Sub
”’
”’
Private Function ValidateAllControls() As Boolean
‘ 強制的に全コントロールのValidatingイベントを走らせる、
‘ または各検証ロジックをシーケンシャルに評価する
‘ 1. 個別メソッドを直接評価（確実な一括チェック）
Dim dummyArgs As New System.ComponentModel.CancelEventArgs()
ValidateCustomerName(txtCustomerName, dummyArgs)
ValidatePostalCode(txtPostalCode, dummyArgs)
‘ 2. ErrorProviderにエラーメッセージが残っていないか走査
If Not String.IsNullOrEmpty(m_ErrorProvider.GetError(txtCustomerName)) OrElse
Not String.IsNullOrEmpty(m_ErrorProvider.GetError(txtPostalCode)) Then
Return False
End If
Return True
End Function
”’
”’
Private Sub btnSubmit_Click(sender As Object, e As EventArgs) Handles btnSubmit.Click
‘ 送信前の一括チェック
If Not ValidateAllControls() Then
MessageBox.Show(“入力内容に不備があります。エラー表示を確認してください。”, “検証エラー”, MessageBoxButtons.OK, MessageBoxIcon.Warning)
‘ 最初のエラー箇所へフォーカスを誘導するプロフェッショナルな配慮
If Not String.IsNullOrEmpty(m_ErrorProvider.GetError(txtCustomerName)) Then
txtCustomerName.Focus()
ElseIf Not String.IsNullOrEmpty(m_ErrorProvider.GetError(txtPostalCode)) Then
txtPostalCode.Focus()
End If
Return
End If
‘ — 業務ロジック（DB登録等）の実行 —
MessageBox.Show(“検証を通過しました。データを登録します。”, “成功”, MessageBoxButtons.OK, MessageBoxIcon.Information)
End Sub
”’
”’
Protected Overrides Sub Dispose(disposing As Boolean)
If disposing Then
‘ 明示的なイベントデタッチとErrorProviderの解放
RemoveHandler txtCustomerName.Validating, AddressOf ValidateCustomerName
RemoveHandler txtPostalCode.Validating, AddressOf ValidatePostalCode
If m_ErrorProvider IsNot Nothing Then
m_ErrorProvider.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
End Class
—
3. シニアエンジニアが押さえるべきアーキテクチャの極意
ユーザーエクスペリエンス（UX）とイベントの罠
Windows Formsの `Validating` イベントは、コントロールがフォーカスを失う（LostFocusの直前）に発生する。ここで注意すべきは、ユーザーがエラー状態のまま「キャンセル」ボタンや「閉じる」ボタンを押下した場合の挙動だ。
`CausesValidation = False` プロパティをキャンセル系ボタンに設定し忘れると、エラーが解消されるまでフォームが閉じられないという「ユーザー拘禁状態」を引き起こす。システム管理系ツールで最も忌むべきバグの一つである。
パフォーマンスとシステム間連携
大規模なデータグリッド（`DataGridView`）や数十個の入力項目を持つマスターメンテナンス画面において、すべてのコントロールで動的バリデーションを行うと、UIスレッドが重畳するイベント処理で圧迫される。
シニアアーキテクトとして、以下の対策を標準化すべきである：
- 遅延評価（Debounce）の導入: テキスト変更時（`TextChanged`）に直接バリデーションを走らせず、タイマーを挟んで入力が落ち着いたタイミングで評価する。
- ビジネスロジック層の分離: `ErrorProvider` が依存する検証ルール（正規表現やマスタ存在チェックなど）は、UI層にハードコーディングせず、共有クラスライブラリ（DLL）またはドメイン層として切り離す。これにより、WPFやWeb APIへの移行時にも検証ロジックを100%再利用可能となる。
総括
`ErrorProvider` は単なる「赤くて小さなアイコンを表示するおまけ機能」ではない。正しく設計されたライフサイクル管理と一括評価の仕組みと融合させることで、レガシーなWindows Formsアプリケーションを、モダンで洗練されたエンタープライズ水準のUIへと昇華させる強力な武器となる。
コードの隅々にまで意図を持たせよ。メモリの1バイト、イベントの1パルスに至るまで支配してこそ、真のプロフェッショナルである。
