> 私の趣味では、確かに便利ですが、引き渡しが複数ある場合
> は、面倒な気も致します。
面倒というより、ユーザーの入力を検証して、結果 NG だった
らユーザーに再入力を促すというケースでは、クロスページポ
ストバックは少なくとも使うメリットはないと思いますが。
入力画面でユーザーが入力し、終わったらクロスページポスト
バックを使って別のページにデータを渡し、そこで検証して結
果 NG だったらまた入力画面に戻り、エラーメッセージを表示
して・・・というようにしますか？ 普通にポストバックして
同一ページで検証するのとどちらが良いですか？
> 『 「同一ページ上の複数のデーター入力フォーム」では、
> 必ず、ValidationGroupプロパティにより、検証作業をグルー
> ピングしておく必要がある。』と鉄則がございます。
質問者の方が最初の質問で書かれた例のような場合はその必要
はいはずです。
> Page.IsValid プロパティは、RequiredFieldValidatorでは
> 効果がありません。
> ・・・中略・・・
> ボタンハンドラー内に、if(Page.ISValid == false)return;
> と書いても問題は無いのですがここまで到達しません。
そんなことはないはずですが。クライアント側で検証結果 NG
だとポストバックがかからないだけです。クライアント側で結
果 OK となるとポストバックがかかります。ポストバックがか
かると、サーバー側でも検証されます（ここまで到達します）。
ブラウザの JavaScript が無効になっているとどうなるでしょ
うか？ そういうこともあるので、クライアント側の検証はお
まけ程度に考えておくべきだと思います。
> しかし、CoustamValidatorを作成した場合は、サーバー側の
> CoustamValidatorイベントハンドラーで、args.IsValid=false
> と設定しますと、ボタンハンドラー内の、
> if(Page.ISValid == false)return；を使用します。
正確にはちょっと違うと思いますが。
CoustamValidator の場合は、クライアント側の検証スクリプト
が自動生成されないので、即ポストバックがかかってサーバー側
での検証が始まります。
検証結果が NG の場合 args.IsValid=false に設定（デフォルト
は true）すると Page.IsValid が false になるということのは
ずです。
なお、クライアント側の検証スクリプトは、自動生成はされない
ものの、自分で作って ClientValidationFunction に設定するこ
とができます。そうしておけば、RequiredFieldValidator と同
じ動き（まずクライアント側で検証、結果 OK でポストバックが
かかってサーバー側でも検証）をします。
