- - PR -
「トラブルは水際で防げ〜入力時のチェックとエラー処理」について
1
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-11-24 22:01
こんにちは、Jittaです。「VB 2005超入門」の、第4回、「トラブルは水際で防げ〜入力時のチェックとエラー処理」で、お伺いします。
本当ですか?本当に Form の CausesValidation を False にすると、[×] ボタンで終了しますか? この件、ベータ テスターとして評価しているときに遭遇し、「Form.CausesValidation を False にしても、[×]ボタンで終了しない」と、バグ報告を上げています。マイクロソフトからの回答は「仕様」です。 → https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=93750 製品版では、疑うことなくマイクロソフトから提示された「FormClosing イベントをハンドルして、e.Cancel = false としてください」を行ったため、試していませんが、仕様が変更になっているのでしょうか。 また、CausesValidation = False の、副作用について、説明が必要でしょう。 ここで、Cancel ボタンのイベントハンドラを NOP とします。商品コードに不正なコードを入力し、キャンセル ボタンをクリックします。当然、Validating イベントは発生しません。次に、OK ボタンをクリックします。OK ボタンのクリックイベントが発生します。 CausesValidation = false としたコントロールにフォーカスが移動することによって実行するアクションで、本来 Validating イベントが発生しなければならないアクションがとれないのなら、問題はありません。 (菊地さんのブログがわかりやすい→ http://www.ailight.jp/blog/kazuk/archive/2006/11/23/13348.aspx )
納得できません。例外が発生するためにかかるコストは(小さくないというより)大きく、発生する場合としない場合で、体感速度にかなり差が出ます。もちろん、何かエラーがあるから時間がかかっていると思わせる効果はありますが、.NET Framework では例外は極力利用しない方向でコーディングすることが推奨されています。 → MSDN を、キーワード「例外, 使用方法のガイドライン」で検索
もっとも、「通常のエラー、予期されるエラー、または正常な制御フロー」の範囲については、十人十色なのですが。 「出来る限り高速化したい場合には注意が必要」ではなく、「出来る限り、ユーザ入力に対する判断をする場面で例外を使用しないように、設計しよう」ではないでしょうか。 また、例外情報に含めるメッセージは開発者向けとし、エンド ユーザに見せるメッセージは、例外の種類を判断して別途作成することが望ましいと思います。 _________________ | ||||||||||||
|
投稿日時: 2006-11-24 22:20
おぉ! @IT自ら釣りとはw いくらなんでも、この程度の内容で間違うわけないよねw | ||||||||||||
|
投稿日時: 2006-11-24 22:27
ん?
仮定か。。。 で、やってみたのですが、
これは確認できませんでした。つか、フォーカスを受け取らないところにフォーカスが移動する、というのが、解せない。。。 _________________ |
1