- - PR -
テキストボックスの入力制限をするには？ (Windows.Forms)
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-05-10 16:21
×コードによるドキュメント(テキスト)に対応
○コードによるドキュメント(テキスト)の変更に対応
そうです。Swing の DocumentFilter が実際そうなっていて、強制的に任意のテキストを設定するときは DocumentFilter を一時的にはずすのです。(数値しか入力させないけど、入力後は、数値をカンマ区切りで表示するとかいうときに DocumentFilter が仇になるのです。)
いえ、DocumentFilterにかなり類似したものを求めていますよ。 DocumentFilter というものを作って既存の TextBox で利用できるようにする、というのは(私には)無理だと思いますので、DocumentFilter に対応した TextBox, ComboBox などのサブクラスを作成しようとしています。(すでに他の機能を持たせた TextBox, ComboBox があるので、これらを DocumentFilter に対応させることになります。) | ||||||||||||||||
|
投稿日時: 2008-05-10 17:07
何だかうまく (?) まとまっているようなので、スレの主旨から少しずれている部分 (工数など) については特に言及しないことにします。
確かに私も TextChanged イベントよりも前の段階 (描画される前の段階で) クライアントからの Char を受け付けたことを示すようなイベントがあると嬉しいと思うことがあります。
2.0 になって ControlContainer.ValidateChildren メソッドというのが追加されていたりと '検証' が強化されてきているわりに、クライアント領域での入力を受け付けたことを察知するような機能は用意されていません。 (あまり詳しいことは、ここでは書けないのですが) このことからいって、どうも用途のない要求だと見なされている 'かも' しれません。 先のような要望は日本国内からだけだと認識しがちですが、CodeProject などを見てもわかるとおり日本以外でも要求自体はあるハズです。 入力段階での弾き出しの中に MaskedTextBox という選択肢が出ていますが、あれは入力制限というよりは書式に沿った定型入力を目的とした制限になっているため、入力制限自体を目的とすると使い勝手が良いとは言えません。 実際、入力スタイルが固定長になるので入力制限だけを目的とできません。 私の場合は郵便番号などの定型入力でしか使ったことがないです。(これも客先によるところが多いのでしょうけど) 3rd パーティ製品も要求されている具体的な仕様は存じませんが、ある程度のカスタマイズが必要だと考えると選択から外れそうです。
.NET もしくは Windows では "サブクラス" だとやや曖昧な単語になります。 ここでのサブクラスというのは、派生クラスのことでしょうか? それとも WindowsMessage を処理するクラス (NativeWindow の派生) のことでしょうか? どちらかわかりませんが、両方とも検討してみると面白いかもしれません。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||||||
|
投稿日時: 2008-05-10 19:14
1日あけてたらすっかり出遅れました。
もうまとまっているようですが、 少し誤解もあるようなので返信だけさせていただきます。
これはおそらく、
このことを指しているのでしょうが、 具体的なAPI仕様やメッセージの種類に関する知識が 必要だと言ったつもりではありませんでしたし、 DocumentFilter のことではなく、純粋に引用した文章に対する返信の意味でした。 今、見返してみたら「(Win32APIやウィンドウメッセージ)」と書かれていますし、 文脈からそう取れそうなのですが、あまりよく読まずに「Windows のこと」という言葉の方に 反応してしまいました。 誤解を招いたようですみません。 たとえば「ウィンドウメッセージって何？」というようなレベルの人でも、 .NET Framework を理解していれば、ある程度のものは作ることができます。 しかし、Windows アプリケーションを作る以上は、 最低限ウィンドウメッセージやメッセージループの概念とか、 WndProc のオーバーライドのような手法くらいは知っているべきだと思っています。 そういうことが言いたかったのです。 私も、フレームワークの機能がもっと充実して ウィンドウメッセージを直接処理するようなコードを書く機会が減ればいいとは思っています。
これに関しては、rain さんのご指摘の通り、私の完全な見落としです。失礼しました。 | ||||||||||||||||
|
投稿日時: 2008-05-10 21:28
今回は、派生クラスを作成して WndProc をオーバーライドしてウィンドウメッセージを処理しようとしていました。 .NET では、superclass(スーパークラス)、subclass(サブクラス) よりも base class(基底クラス)、derived class(派生クラス) と言ったほうが通じやすいということですね。 ついでに世間で、どのように呼ばれているかも見てみました。superclass(スーパークラス)は、base class(基底クラス)、parent class(親クラス) と呼ばれることもあるようです。subclass(サブクラス)は、derived class (派生クラス)、clild class(子クラス)、extended class(拡張クラス)、inherited class(継承クラス) と呼ばれることもあるようです。 | ||||||||||||||||
|
投稿日時: 2008-05-11 00:31
単純な話で言えば、自分と貴方とでは、言語仕様に対して求めるものが大幅に違うという事。 自分の場合、言語に対して一番いらないのは余計なバグな訳だから、ライブラリを充実した結果余計なバグが増えましたという状況に成るのが嫌だと思っている。 となれば、拡張的なライブラリの中身が、基本ライブラリで提供されている関数の組合せで出来ているような物なら、そんなものはサードパーティに任せてしまえばいいと考えている。 プログラムに於いて言えば、拡張ライブラリ等の二次部品は商品たり得るんだから、 自分が痒いところに手が届かないと思っている機能があるのであれば、 それはそのままビジネスチャンスではないのかね？ そういう部分を商売と見ずに、言語側でのサポートを求めていては、 それは単なるユーザープログラマーであって開発者としてのプログラマーではないと自分は思っている まぁ、この業界の流れは ユーザープログラマーの量産による人件費の抑制という流れはあるんだと思っているがな | ||||||||||||||||
|
投稿日時: 2008-05-11 02:22
書いてある内容が、だいぶまともになっているので、もう少し反応しておきます。
そうですね。私もライブラリが無駄に大きくなることで全体としての品質が保てなくなるということについては懸念しています。実際、Java (Swing) などは新しいバージョンで退行バグが出ることが多かったりして、機能拡張する前に既存のコードをブラッシュアップして欲しいと思うことが多々あります。
ここが私と考え方の異なるところですね。サードパーティ製ライブラリや自作ライブラリは、標準ライブラリに比べて利用者が少なくなりがちですから、上記の品質という面ではより不安要素が増えます。 なので、汎用性の高い、基本的な機能についてはマイクロソフトがどんどんとライブラリを拡充させていって欲しいと思っています。これは、サードパーティに比べてマイクロソフトなら品質の高いコードが書けるということではなく、マイクロソフトが標準ライブラリとして用意したものなら、利用者も多くフィードバックによって品質が高まっていく(枯れる)ことが期待できるからです。
そうですね。Visual Basic 6.0 の成功は、Active X というコンポーネントモデルがサードパーティにとってもビジネスメリットが大きかったからだと言われていますし、そのようなデベロッパー向けビジネスを否定するつもりはありません。 ただ、うちの会社はそのようなデベロッパー向けに自社ライブラリを外販しておらず、エンドユーザーにシステムを提供することが主となっています。エンドユーザーが、いつまでも、こちらの言い値でシステムを買ってくれるのなら良いのかもしれませんが、今後、この業界はもっと厳しくなっていくと思っています。 正直なところ、まだまだ IT業界(?)、システムソリューション構築というのは、世間的には「良く分からないすごいもの」と認識されていて、初モノ価格がついているような異常な状態だと思っています。(百貨店で初モノのスイカが100万円で売っているような状態だと思っています。) 大手のSIerでも、人件費をベースに工数見積りを出してシステムを受注しているような状態ですから。これは建築業界をお手本に発展してきたこの業界の歪んだ部分だと思います。こんな開発側に都合のいい状態がいつまでも続くとは思わないほうがいいです。 工数ではなく価値でシステム価格が決まる時代がもうすぐ来ますよ。「延べ工数がこれだけかかるからこのシステムの価格は5,000万円です」ではなく「このシステムを5,000万円で買うと、業務フローの無駄を何パーセント削減して運用コストを年間これだけ下げられます」と工数を提示せずに費用対効果を明示しないとシステムが売れない時代になります。 「現状への不満」を商機と捉えるのは私も同じですが、私の顧客は「TextBox への入力制限」という細かなことに不満を示していません。もっと上位の概念、ビジネスフローのクリティカルパスを短くしたい、それができていない現状に不満を持ちます。ですから、私は「TextBox への入力制限」に対して過大なコストを払いたくはないのです。それで「ないものは作ればよい」という単純な発想に対して疑問を持つのです。 | ||||||||||||||||
|
投稿日時: 2008-05-11 06:43
１点だけ、DocumentFilter見たいなものはマイクロソフトは あえて作っていないと思います。使いにくいGird系、今頃 MaskedEdit系についても言えることですが（あと特にFAX系） DocumentFilterなんぞマイクロソフトの実力から言えば屁でもない事です。 マイクロソフトは常に業界全体を計算して5-10年ぐらいかけて昇華させて 行くのです。そうでないと、InputManもSpread.Netも....GrapCity つぶれてしまうじゃないですか みんなで無駄な物を作り！！、IT業界の延命を。。。。。。！！ ＃未記入さん、そろそろ名前を付けてはどうですか？ ＃あなた以外みんな名前がありますよ。。。 | ||||||||||||||||
|
投稿日時: 2008-05-11 20:16
やっと、話の前提を出してきたか。 元々の顧客の「TextBox への入力制限」がどの程度のものかまだ見えないのだが、 最終的に、不正な文字の使用を禁止できればいいという物であるなら、 そもそも、入力装置からの入力の時点では一切の入力制限はしない方向性で考える。 正直なところ、コントロールのバリデーション時のチェックと、最終的な実行時の整合性チェックの２箇所のチェックのみで十分。 その２箇所チェックで顧客に納得してもらえるならそれ以上の過剰なチェックは行わない。 実際、キー入力を制限したところで、バリデーションと整合性の２箇所のチェックを省略して良い訳でもないし、 キー入力制限はユーザビリティを下げるだけで、メリットが低すぎる。 入力チェックとしては、下策でしかない。 その下策を敢えてやりたいという話だと思っていたんだがね。 前提を後だしにしちゃいけないとは言わんが、前提が有るなら先に提示しといたほうがいいぜ。 この前提もなしに
などと言えば、敵しか作らない。 まともに論を交わしたいなら、前提は周知するのは最低限の礼儀だと思うぞ。 実際、自分もこの前提が有るのは予想は出来たが 貴方が作った土俵はその前提のない 単純に「ないものは作ればよい」なんて言っている人は、システム設計能力の低いバカ という土俵だったから、それに合せて、前提無しの土俵に上がらせてもらった。 敢えて敵を作って何かしたいのだろうと思ったからね。 最後に この業界の顧客（時にはSE）には、 私は「TextBox への入力制限」に対して過大なコスト を説明しても、それでも敢えて作れという人は多いから、 前提を出してもらわないと、それでも敢えて作れを前提に考える人の方が多いんじゃないか？ こういう掲示板だと | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。