入力検証

ダイアログの機能の１つとして、ダイアログによって入力された値の検証機能があり、これは Delphi や Visual C/C++ から移行してきた人間にはとっつきにくいかもしれない機能である。
入力検証機能の実装は、コンテナコントロールの Validate() メソッドと、各入力コントロールの Validating イベントおよび CausesValidation プロパティによって制御される。
ヘルプにしっかりと解説があるのだが、この動きは文章で読んでもわかりにくいかんじがするので、簡単なテストプログラムを作成して実際に試すことをオススメする。

CausesValidation プロパティ

このプロパティは、自分自身が検証機能に参加するかどうかを決定する。
検証機能に参加しないコントロールとは、ファイル名入力における参照ボタンや、ダイアログのキャンセルボタンが相当する。
たとえば、存在するファイル名を入力するダイアログがあり、ファイル名を入力するための TextBox コントロールがあるとすると、この TextBox コントロールは入力検証機能を用いて正しいファイル名を期待するとしよう。
ファイル名を自動的に入力するため、ファイルを開くダイアログを表示する参照ボタン openDlg ボタンを追加した場合、この openDlg ボタンの CausesValidation プロパティが true のまま動作させると、ユーザがファイル名をダイアログで選択するためにボタンを押すと、入力検証機能が働いてしまい TextBox に正しいファイル名が入力されていないと参照ボタンがおせないということになる。
逆に、これが開くボタンであればファイル名は正しい内容である必要があるので、CausesValidation プロパティを true にして検証に参加する必要があるだろう。

Validate メソッド

コンテナとなるコントロールは初期状態として検証済みであることが前提となっている。
ユーザが入力を行うアクティブコントロールの CausesValidation プロパティが true ならば、コンテナはそのコントロールを検証が必要であるとマークしておき、Validate メソッドの呼び出し時に Validating イベントなどを利用して検証を行う。
通常、入力フォーカスの移動などによって Validate メソッドは自動的に呼び出され、コンテナは常に１つだけ未検証状態を許した状態となる。
これは CausesValidation プロパティとあわせて動作し、コントロール c1, c2, c3, c4 の４つがあったとき、c2, c3 の２つのコントロールが CausesValidation = false となっていて検証に参加しない場合、フォーカスが c1 → c2 → c3 → c4 → c1 と移動すると c3 → c4 の時点で c1.OnValidating() が発生し、c4 →c 1 と移動するときに c4.OnValidating() が発生するようになっている。