- - PR -
[VB2005] Validating イベント内で MsgBox を使えないジレンマ
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2007-12-04 17:05
感覚の問題でしょうね。 エラー内容が見えることがユーザーの希望どおりであれば、Coboler チックに StatusBar なり、ErrorProvider + フォーカス移動させないで十分表明できていると思います。 正しい入力でも [OK] [Cancel] が出る場合というのはあくまでフォーカス アウト時の確認であり、Button を押下した時に出るものではありません。 たまたまフォーカス遷移先が Button だっただけであり Click より前に割り込まれフォーカスの移動だけ成立します。 客先要望あってのことなのでお気持ちはわかりますよ。 私もどうしてもダイアログでないとダメというユーザーさんに出会ったことがあります。 ただ Button を押下したことにしろという要望はありませんでした。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||
|
投稿日時: 2007-12-08 17:01
そういえば、クリックはなされていないので、クリックのイベントは発生させられないですね。 クリックは、押し込んだ時ではなく、押し込んで放したときに発生します。 フォームにボタン一つだけ置いて、そのボタンのクリックイベントを実装します。実行して、ボタンを押し込み、マウスポインタをボタンの外に出してから放します。すると、ボタンのクリックイベントは発生しません。 こういうことが起こっているわけですね。 しかし、警告の方は、なるほどなあ、と思いました。 | ||||
|
投稿日時: 2007-12-12 11:23
はい、そういう訳です。
ダイアログを出さずにステータスパネルにエラー(ワーニング)表示だけさせて済ますなんて、よほど出来たユーザーじゃないとトラブリます。 (警告は見やすくしてくれなきゃ見落とすじゃん!と) ベースのフォームの上にダイアログ表示用のユーザーコントロール(Selectable=False にしてフォーカスを受けないよう)をおいて、表示/非表示を切り替えて、いかにもダイアログフォームが出ているように思わせる、ってところが関の山ですかね。 あー、実に美しくない。 | ||||
|
投稿日時: 2007-12-12 13:04
警告の場合は、決定 Button の Click 時に一括確認とかにしますね。 フォーカス遷移でないと許されないのであれば、現状のままが自然だと思います。 いつも思いますが、我々とお客さまではなかなか感覚が違うものですね。 我々は Click は完了していないと理解できますが、お客さまは...
_________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||
|
投稿日時: 2007-12-12 13:15
前面に出て視界を奪ってしまうと、思考が中断します。
なれてくると、「この値は警告が出るけど…」と、わかってやる場合もあります。このとき思考が中断されると、非常にいらつきます。 ちょうど、Vista の昇格プロンプトのようなものです。わかってやっているのに「あなたが実行したものですか？」と聞かれるのは、大変うっとうしいでしょう。 ということで思い出したのですが、変更イベントを捕まえて警告が必要な値かどうかを判断し、TextBox 下に配置したラベルに警告メッセージを表示する、などはどうでしょう？ また、ツールチップに警告を表示するようなアプリケーションがあったように思います。これらなら、思考を中断することなく、警告は伝えられると思います。 | ||||
|
投稿日時: 2007-12-14 11:16
項目入力直後の警告ダイアログに拘っている今のユーザー、自分の周囲だと官公庁系は90％くらいの確率で遭遇しますよ。
思考の停滞や入力の中断といった効率性の問題じゃなくて、ミスを発生させないことが大事。 （それにより入力に時間を要したりするのは仕方ないことと割り切ってしまわれる） ま、確かに要求されることは分からなくもないんですけどね。 成功の数よりも失敗の数で人事評価される世界だと、そういう思考になってしまうみたい。 ブラウザベースだったら onBlur の中で凄いことしなくちゃいけないことになってただろうから、WindowsForm ベースに押し切って正解だったと常々思う。 | ||||
|
投稿日時: 2007-12-14 14:49
#たいしたことでは無いですが、WindowsのGUIの名誉のために。
「ミスを発生させないことが大事」->「項目入力直後の警告」 という論理に同意しているようですが、それは変ですよ。 プログラムで判断できるようなミスは 項目ごとに確認しようが、全体で一括で確認しようが、 得られるデータは変わりませんので、 たいした問題ではありません。 痛いミスは、プログラムで確認できないようなミスです。 #名前の打ち間違いとか。 「項目入力直後の警告」が入っていると、 Jittaさんが言っているように、 操作・思考の中断のせいでミスが増えます。 （統計データも見たことがあります。Scientific Americanかな？） ですから、「ミスを発生させない」ために 「項目入力直後の警告」を実装するなら、それは間違いです。 WindowsのGUIは習熟していなくても操作できることを念頭において設計しています。 入力効率よりもむしろミスを減らす方向、初心者でもわかりやすい方向で 設計しています。 入力効率を重視する場合、 全てのユーザーが十分に習熟しているという前提で運用可能な場合、 特殊な環境・状況の場合は 特殊なGUIの方が有効に機能する場合もあります。 とくに、入力効率を重視する場合は 「項目入力直後の警告」が有効に機能する場合が多くあります。 dBaseなどでよく見かけましたし、 今でも効率重視の場合に採用したりします。 #レジスターなんかもそれに近いですね。 比較的初期にコンピューターを導入した企業・官公庁などでは、 まだ未成熟だった頃の特殊なGUIに慣れていて、 他のGUIを受け付けない/ミスが多くなるユーザーがたまにいます。 「拘っている今のユーザー」の本当の所はわかりませんが、 それに類する話ではないかと思います。 [ メッセージ編集済み 編集者: れい 編集日時 2007-12-14 14:53 ] | ||||
|
投稿日時: 2007-12-15 22:08
う〜ん。私も官公庁系の仕事をしていましたが、失敗は「上司の指導力不足」と、上司の評価が下がるので、上司がも○×△
じゃなくて。 発注者の注文通りに作ったら、現場から「これ、入力しにくいんだけど？」と、言われたのですが。。。しかも、納入して1年以上経ってから。 つうか。社内でももめて、それが原因で鬱になりかけたんだけど。。。 えっと、こんな風に提案します。私の場合、投稿したときと書いたときがずれていることが多いので、上の方に書かれていることはあまり気にしないでください。 → http://blogs.wankuma.com/jitta/archive/2007/12/15/113113.aspx | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。