Windows Formsの「死の罠」を回避する：ValidatingとValidatedの極限的設計術
多くの開発者が、Windows Formsのバリデーションを「ただのイベント処理」と誤解している。だが、現場で泥をすすり、数百万行のレガシーコードを保守してきた我々にとって、`Validating`と`Validated`は、アプリケーションの堅牢性を左右する「境界防衛戦」そのものだ。
フォーカス移動の制御を誤れば、ユーザーは入力ループの檻に閉じ込められ、最悪の場合、アプリケーションはデッドロックに近い挙動を示す。本稿では、このイベント・ライフサイクルを掌握し、メモリとCPUを無駄にしない「プロフェッショナルの実装」を伝授する。
—
1. イベントの「重み」を理解せよ：Validating vs Validated
まず、根本的な役割分担を再定義しよう。
- Validatingイベント（Cancelable）：
ここでバリデーションを行う。`CancelEventArgs.Cancel = True`を設定することで、フォーカスの移動を物理的に阻止できる。「門番」の役割だ。
- Validatedイベント（Non-Cancelable）：
バリデーションが成功した直後に発火する。データの永続化や、関連するUI要素の更新を行う。「後処理」の役割だ。
【黄金律】：`Validated`イベントでフォーカスを操作してはならない。それは無限ループの引き金を引くようなものだ。フォーカス制御は、必ず`Validating`で完結させること。
—
2. 現場で使える「フォーカス強制定着」実装パターン
ただエラーを出すだけでは素人だ。エラー時にフォーカスを戻しつつ、ユーザーの操作性を損なわないための、保守性の高い設計を示す。
”’
”’
Private Sub txtInput_Validating(sender As Object, e As System.ComponentModel.CancelEventArgs) Handles txtInput.Validating
Dim control As Control = DirectCast(sender, Control)
‘ 空文字チェックなどの論理バリデーション
If String.IsNullOrWhiteSpace(control.Text) Then
‘ エラープロバイダーの活用（UIの標準機能を利用し、メモリを浪費しない）
ErrorProvider1.SetError(control, “値が入力されていません。”)
‘ フォーカスの逸脱を阻止
e.Cancel = True
‘ 注意：ここでMessageBox.Showを乱発するのは避けること。
‘ モーダルダイアログはイベントループを複雑にし、予期せぬフォーカス喪失を招く。
Return
End If
‘ バリデーション成功時、エラーをクリア
ErrorProvider1.SetError(control, “”)
End Sub
—
3. レガシー環境・高負荷環境でのパフォーマンスチューニング
VB.NETのWindows Formsにおいて、UIスレッドをブロックすることは死を意味する。特に、バリデーションの裏でDB照合や外部API連携を行っている場合、以下の知見を導入せよ。
3.1. 非同期検証の罠を避ける
`Validating`イベントは同期処理が前提だ。ここで`Async/Await`を安易に使うと、フォーカス管理のライフサイクルが崩壊する。DB照合が必要な場合は、「入力確定後、Validatedイベントで非同期タスクを発火させ、UIを非活性にする」という階層設計を取れ。
3.2. オブジェクトの明示的解放（Dispose）
大規模フォームでは、`ErrorProvider`や動的に生成したコントロールのメモリリークが致命傷になる。`IDisposable`を正しく実装し、フォームの`Dispose`メソッドを必ずオーバーライドしろ。
Protected Overrides Sub Dispose(disposing As Boolean)
If disposing Then
‘ コンポーネントの明示的解放
If components IsNot Nothing Then
components.Dispose()
End If
‘ ErrorProvider等のUIコンポーネントを確実に解放
If ErrorProvider1 IsNot Nothing Then
ErrorProvider1.Dispose()
End If
End If
MyBase.Dispose(disposing)
End Sub
—
4. 伝説的アーキテクトからの提言：UIは「状態」で制御せよ
最後に一つ。バリデーションをイベントコードの中に埋め込むな。
UIロジックとビジネスルールを分離する「バリデーション・ファサード」を構築せよ。
1. Validatorクラスを作成する: フォームに依存しない純粋なクラスにチェックロジックを退避させる。
2. UI層は呼び出すだけ: `Validating`イベント内では、そのValidatorを呼び出し、結果（Boolean）に基づいてUIを制御するのみにする。
これが徹底できれば、君のコードはVBA上がりの「スパゲッティ・イベント処理」から脱却し、誰が保守しても壊れない、プロフェッショナルのシステムへと昇華する。
Windows Formsは古い？ いや、適切に制御されたイベント駆動は、今なおエンタープライズの現場において最強の武器だ。コードを書くとき、常に「このイベントの先にあるメモリの状態」を想像しろ。それが、エンジニアとしての格を上げる唯一の道である。
