- - PR -
テキストボックスの入力制限をするには？ (Windows.Forms)
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-11 22:33
どうせ話はまとまらないと思いますが…。
入力制限の種類を明示していないのは、これから決まるからだけでなく、まだ洗い出しができていないからです。また、現時点で入力制限の方法について顧客の明確な要求があるわけでもないです。 いままでフロントエンドを Java (Swing) で作ってきましたが、今後は .NET でのフロントエンド開発も受託していきます。当然、リプレースのタイミングで Java (Swing) から .NET に変更になる案件も出てきます。このようなことを想定すると、可能な限り Java (Swing) と .NET の操作性を合わせられるようにしておきたいのです。(もちろん、途方もないコストがかかるようなら .NET では入力仕様を変えるということも考えますよ。) .NET になることで入力チェックが Validating のタイミングまで遅れる、ということになると既存顧客に対する説明が必要になるだけでなく、社内の設計メンバーもこの入力チェックタイミングの変更が既存のシステム設計と矛盾しないかどうかを検証していかなくてはなりません。このようなことを考えた結果、ウィンドウメッセージを使ってでも入力制限の仕組みを作っておいたほうがいいという結論を私は出しました。
なぜ、あなたが そのような判断をするのですか？ あなたは「ないものは作ればよい」と考えているのではありませんでしたか？ あなたが何を主張したいのか、まったく分からなくなりました。入力制限の仕様を緩和することで「作らない」という選択もありうる、ということを私が言ったときに、あなたは「ないものは作ればよい」というのがビジネスチャンスであり、それができないのはプロ失格だと主張されていませんでしたか？入力制限をしない方向で考えなおしたら、あなたの大好きな開発工数を上積みできなくなりますよ。それでいいんですか？ 実際のところ、「ないものは作ればよい」という発想は行動指針としては、まったく役に立たないんです。常にメリットとデメリットを評価して「作る」か「作らない」かを決めたほうがいいんです。「ないものは作ればよい」という単純な発想しかできない輩は、常に「作る」を選択しようとするからバカだと言っているんです。
下策ですか…。きっと、私が作るシステムとあなたが作るシステムはまったく異なるものになるのでしょうね。 ふたつ異議を唱えておきます。 まず、ひとつめ。「キー入力制限はユーザビリティを下げるだけ」とのことですが、キー入力が制限されていることでユーザビリティが上がることも多々あると思います。たとえば数字を入力するところに英字が入る必要はないでしょう。Validating のタイミングで「数字だけにしてね！」って言われるくらいなら、最初から数字しか入らないほうが私はユーザビリティが高いと思っています。 ふたつめ。たしかに入力制限をおこなっても、Validating でのチェックを省略することはできません。でも、それでいいんです。入力制限をしておけば、Validating での検査ロジックを軽減できて見通しが良くなりますから。数字しか入力できなければ Validating では値が数値であることを前提にして検査ロジックを書くことができます。さらに言えば、私は Validating 自体をいくつかの工程に分けられるように仕組みを盛り込もうとしています。検査コードはいくつかに分かれていたほうがコードがすっきりすることもあるんですよ。
意味が分かりません。敵とはどういうことですか？あなたが書き込みをしているのは、私を敵視しているからということですか？ そうであるのなら、これ以上、あなたの相手をするのはやめておきましょう。私は考え方の異なるあなたに対して、私の考えを説明し伝えようと努力してきたつもりです。ですが、あなたが「敵」という概念でものを考えている以上、私の言葉があなたに届くとは思えませんから。 | ||||||||||||||||
|
投稿日時: 2008-05-12 02:09
本気でこんな事考えているのであれば、単なる素人としか評価できんね。 Validatingってのは検証ロジックを作りこむ場所。 たとえ入力で数字のみと規制していたとしても、その規制が本当に正しく働いているのかをこの場所で検証しなければいけない。 まぁ、顧客の限られた狭いアプリでそこまで気を使う必要が無いのかも知れないが、 クラッキング手法等での不正データの入力がされる可能性をはなっから無視してValidatingの手を抜いていいものではない。 また、ユーザビリティの話をすれば、コピペ入力やＩＭＥ辞書登録を利用した変換入力をしたいと思う人間は少なからずいる。 その視点を考えた時に入力時規制はユーザビリティを損ないやすい。 せいぜいＩＭＥモードの自動設定程度にしておくのがユーザビリティとしては好まれやすいという事。 自分のスタンスは強い要望があるならば、下策であろうが実装する。（一応下策である説明はするが、強い要望がある場合、それでも実装となることの方が多い） 強い要望がないならば、ユーザビリティが下がる等の合理性の悪い追加コストは盛り込まない。 実装したいのですがという話の時点で、強い要望があると判断しているだけの事だ | ||||||||||||||||
|
投稿日時: 2008-05-12 14:27
仕組みが用意されていないのは、その仕組みを必要とする人が少ないからでしょうね。
常識的に考えて。 数字を許可しないフィールドを考えた場合でも、入力制限をかけられるよりは、処理実行前に入力文字種チェックをしてくれたほうがありがたいです。 入力制限をかけられるとキーボードが壊れたのか心配になりますから。 また、実行前のチェックならエラーメッセージを表示することができますので、何が悪いのかを知ることもできます。
これ、パッケージソフトの世界では、すでにこうなっていますよね。 ただ、受注開発の世界だと、工数を無視することは有り得ないですね。 工数を下回る価格で受注すると赤字になるので、受注するバカはいないでしょう。 発注する側もバカではないので、同じ価値があるなら安くできるところに発注するから、結局は値引き合戦になります。 まあ、マイクロソフトみたいに、競合相手がいなければ、いくらでも言い値で売れると思いますけど。 | ||||||||||||||||
|
投稿日時: 2008-05-12 16:21
私も現在のプロジェクトでTextBoxを拡張した入力制限をしています。
入力できる文字は、数値、英字などデフォルトで用意したルールと、正規表現で制御できるようにしています。 OTAKE氏が言うように「入力制限をかけられるとキーボードが壊れたのか心配になりますから。」 というお客様の指摘があり、禁止文字を入力した場合、 System.Windows.Forms.Help.ShowPopup()メソッドで 「○は入力できません。」みたいなポップアップを表示するようにしてます。 お客様の反応はまぁまぁです。 あと、カタカナは全て半角で入力って要件があり、全角カタカナを入力すると強制的に半角カタカナに変換するなど、トリッキー機能も実装しています。 自分的には微妙と思いましたが、お客様は気に入っているようですね。。。 | ||||||||||||||||
|
投稿日時: 2008-05-12 22:40
ああ、なるほど。 私はケータイからここに投稿するため、ケータイの辞書には「メアド」から変換できるよう登録しているのですが、「メンバーID」が IME-OFF に設定されていれば、AN しか入力できなくなり、変換して入力はできないわけですね。 ケータイは関係ないかもしれませんが、メールアドレスは2回入力させるところが多く、打ち間違えたときのことを考えると、Windows で同じような使い方をしている人がいると考えてもいいと思います。 WORD など、自動で IME モードを切り替えるアプリに対して、「勝手に変えるなよ」と思うときがありますが、そういうのと同じですね。だから一部のアプリには、「IME モードを自動で切り替える」というオプションがあったりするのかな。 とはいえ、そういう風にして欲しい、そうなっていて当然と考える人、そうしてあった方が使いやすい人もいるので、両方が選べる様になっていればいいのかもしれませんね。 | ||||||||||||||||
|
投稿日時: 2008-05-13 15:48
通りすがりかつ全く話は逸れるんですが、よかったら教えてください。
ここでいうクラッキング手法等とは、具体的にはどういうことが考えられるんでしょうか？ WEBであれば、POSTデータ書き換える？など方法はあるんでしょうが、 ローカルでWindowsフォームからMSDE等のDBに書き込みに行くようなアプリでも可能なんですか？ 全然関係ない話ですいません･･･ | ||||||||||||||||
|
投稿日時: 2008-05-13 16:29
よくある話だと、メモリ書き換えて本来あり得ない動作をさせる、というのはありますね。 それだとクライアント側のValidatingだけでは回避されてしまう可能性もありますが。 | ||||||||||||||||
|
投稿日時: 2008-05-13 17:15
最後に ValidateChildren していればですが、SetWindowText とか SendMessage とかは防げますね。 Validating イベント自体は避けられますので、各々の Validating イベントよりか本処理直前でのチェックこそが必須ですね。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。