Windows Formsにおける「バリデーションの罠」を回避せよ：Validating/Validatedイベントの極限設計論
業務アプリケーションの開発において、入力値の妥当性検証（バリデーション）は避けて通れない工程だ。しかし、多くの開発者がここで「初歩的な、しかし致命的な設計ミス」を犯している。
ユーザーが入力欄からフォーカスを外した瞬間に、不適切なデータがデータベースに流し込まれる。あるいは逆に、エラーを修正しようとしているユーザーが、バリデーションのループに陥って画面から脱出できなくなる。
「なぜかフォーカスが移動しない」「キャンセルボタンを押しても画面が閉じない」――こうした現象は、単なるバグではない。Windows Formsのイベントライフサイクルと、オブジェクトの制御権に関する理解不足が生んだ「設計の欠陥」である。
本稿では、プロフェッショナルとして、堅牢でユーザーフレンドリーなバリデーション設計の極意を伝授する。
1. 致命的な誤解：`Leave`イベントで検証してはいけない理由
まず、多くのジュニアエンジニアが陥る罠から指摘しておこう。彼らは入力検証に `Leave` イベントや `LostFocus` イベントを使用する。
結論から言えば、それは「素人」の仕事だ。
`Leave` イベントは、単に「コントロールがフォーカスを失ったこと」を通知するだけのイベントだ。ここでの検証は、以下の問題を引き起こす。
1. 検証失敗時の制御不能: `Leave` イベント内でエラーを検知しても、フォーカスを元のコントロールに引き戻す（フォーカスを奪い返す）制御が非常に困難であり、UIの挙動が不安定になる。
2. 「検証」と「確定」の混同: `Leave` には「検証に成功した後に実行すべき処理」を記述する仕組みがない。
WinFormsには、このために設計された専用の武器がある。それが `Validating` と `Validated` だ。
2. 掌握すべきライフサイクル：`Validating` vs `Validated`
プロフェッショナルは、この二つのイベントの「役割の分離」を徹底する。
`Validating` イベント：門番（Gatekeeper）
フォーカスが移動しようとした瞬間に割り込み、「その移動を許可するか否か」を決定するフェーズだ。
ここで最も重要なのは、`e.Cancel = True` という命令だ。これを発行することで、「入力内容が不正であるため、フォーカス移動を拒否する」という強力な制御が可能になる。
`Validated` イベント：承認（Successor）
`Validating` イベントによって「検証がパスした」ことが確定した後にのみ呼び出される。
ここでは、検証結果に基づいた派生処理（例：入力されたIDに基づいてマスターデータを検索し、ラベルに表示するなど）を行う。
設計の鉄則：
- `Validating` には 「状態の判定」 だけを書け。
- `Validated` には 「判定後の副作用（データの連動）」 を書け。
3. 実務における「地獄のループ」と回避策
ここからが、設計の真髄だ。
`Validating` で `e.Cancel = True` を多用すると、ある「地獄」が発生する。それは、「ユーザーがエラーを修正したくても、画面を閉じたくても、バリデーションに阻まれて閉じられない」という現象だ。
例えば、ユーザーが「キャンセル」ボタンを押したとする。しかし、入力欄が未入力で `Validating` が `e.Cancel = True` を返すと、フォーカスはキャンセルボタンに移らず、ユーザーは画面に閉じ込められる。これはユーザー体験（UX）における最悪の設計だ。
これを解決するには、「バリデーションをバイパスするフラグ」を設計に組み込まなければならない。
4. プロダクション・レディな実装モデル
以下に、実務でそのまま利用できる、堅牢なバリデーション設計のテンプレートを示す。ここでは `ErrorProvider` コンポーネントを活用し、視覚的にも分かりやすく、かつ「キャンセル時の脱出」を考慮した設計を行っている。
''' <summary>
''' 堅牢なバリデーション設計を実装したフォームの例
''' </summary>
Public Class SecureValidationForm
' ErrorProviderは、エラー箇所を視覚的に示すための標準的なコンポーネント
Private WithEvents errorProvider As ErrorProvider
' バリデーションを強制的にスキップするためのフラグ
' これがないと、エラー時に「閉じる」「キャンセル」ができなくなる
Private _isBypassingValidation As Boolean = False
Public Sub New()
InitializeComponent()
' コンストラクタで初期化
errorProvider = New ErrorProvider()
errorProvider.BlinkStyle = ErrorBlinkStyle.NeverBlink
End Sub
''' <summary>
''' 入力欄のValidatingイベント
''' </summary>
''' <param name="sender">イベントの発生源</param>
''' <param name="e">イベント引数</param>
Private Sub txtInput_Validating(sender As Object, e As System.ComponentModel.CancelEventArgs) Handles txtInput.Validating
' キャンセル操作中（画面を閉じようとしている時）は検証をスキップする
If _isBypassingValidation Then Exit Sub
Dim inputControl = DirectCast(sender, TextBox)
Dim errorMessage As String = String.Empty
' --- 検証ロジックの開始 ---
' 実務では、ここでDB照合や複雑な正規表現チェックを行う
If String.IsNullOrWhiteSpace(inputControl.Text) Then
errorMessage = "値は必須入力です。"
ElseIf inputControl.Text.Length < 5 Then
errorMessage = "5文字以上で入力してください。"
End If
' --- 検証ロジックの終了 ---
If Not String.IsNullOrEmpty(errorMessage) Then
' 検証失敗：フォーカス移動を阻止し、エラーアイコンを表示
e.Cancel = True
errorProvider.SetError(inputControl, errorMessage)
Else
' 検証成功：エラーをクリア
errorProvider.SetError(inputControl, String.Empty)
End If
End Sub
''' <summary>
''' 入力欄のValidatedイベント
''' </summary>
Private Sub txtInput_Validated(sender As Object, e As EventArgs) Handles txtInput.Validated
' 検証がパスした後にのみ、派生的な処理（DB検索など）を行う
' ここに重い処理を書く場合は、非同期処理を検討すること
Console.WriteLine("Validation Passed. Proceeding to secondary logic...")
End Sub
''' <summary>
''' 保存ボタンのクリックイベント
''' </summary>
Private Sub btnSave_Click(sender As Object, e As EventArgs) Handles btnSave.Click
' フォーム全体のバリデーションを強制的に実行させる手法
' ValidateChildren() は、全コントロールのValidatingイベントを順次呼び出す
If Me.ValidateChildren() Then
' 全てのコントロールがバリデーションを通過した場合のみ保存を実行
MessageBox.Show("データを保存しました。", "Success", MessageBoxButtons.OK, MessageBoxIcon.Information)
Else
MessageBox.Show("入力内容に不備があります。", "Validation Error", MessageBoxButtons.OK, MessageBoxIcon.Warning)
End If
End Sub
''' <summary>
''' キャンセルボタンのクリックイベント
''' </summary>
Private Sub btnCancel_Click(sender As Object, e As EventArgs) Handles btnCancel.Click
' 【重要】バリデーションをバイパスして画面を閉じる
_isBypassingValidation = True
Me.Close()
End Sub
End Class5. アーキテクトからの最終助言
この設計をマスターするために、以下の3点を脳に刻んでおけ。
1. `ValidateChildren()` を使いこなせ:
ボタンクリック時に、個々のコントロールの検証をバラバラに書くのは愚かだ。`Me.ValidateChildren()` を呼び出すことで、フォーム全体の整合性を一括でチェックできる。これが「正しい設計順序」の入り口だ。
2. DB連携は「検証」と「実行」を分ける:
`Validating` イベント内で、直接 `UPDATE` 文を発行したり、巨大なトランザクションを開始したりしてはいけない。`Validating` はあくまで「現在の状態が正しいか」を判定する場所だ。重い処理は、`ValidateChildren()` が `True` を返した後の、ビジネスロジック層で行え。
3. UX（ユーザー体験）を忘れるな:
どんなに完璧なバリデーションでも、ユーザーを画面に閉じ込めるものは「バグ」と同じだ。`_isBypassingValidation` のようなフラグ管理は、技術的なテクニックではなく、ユーザーへの敬意である。
これらの原則を守ることで、君が作るアプリケーションは、単なる「動くツール」から、プロフェッショナルが信頼する「堅牢なシステム」へと昇華するはずだ。
