テキストボックスの入力制限をするには？ (Windows.Forms)

APIはあくまでも部品で自分が目的とする機能はＡＰＩやらなんかのメソッド自分で実装するか。別の方法で要求を実現するものだと思いますが

.NET Framework は Windows の API をできるだけ意識せずにプログラミングできるように作られています。しかし、意識しないとはいえ使っているのですから、理解しておく必要はあるでしょう。理解していなくてもある程度のものは作れますよ。

Swing には明るくありませんが、Swing にだって基本機能だけでできることと、そうでないことがあるでしょう？で、そこを超えたら「インラインアセンブラ」「JNI」のようなものを使うしかなくなるわけで….NET もそうだというだけだと思います。基本機能でカバーしている範囲が違うということでしょう。

さらにこの手の掲示板では必ずしもピンポイントの解答をもらえるわけではありません。

TextBox に DocumentFilter がないという理由だけで、.NET Framework の採用を諦めるのですか？ないものは作ればよいという発想はないのでしょうか？

未記入さんの書き込み (2008-05-10 09:49) より:

近年は高レベルAPIが整備されデベロッパーに優しいイージープログラミングがトレンドかと思っていました。

「ないものは作ればよい」という単純な発想は私にはないですね。趣味だけでやってることではないので。「低レベルインターフェイスを使えばできる」というときに「がんばって作る」以外に「他のアーキテクチャを選定しなおす」「入力値の制限仕様を緩和する」などの選択肢も考えます。今回は「がんばって作る」を選択しましたけど。

単純に「ないものは作ればよい」なんて言っている人は、システム設計能力の低いバカだと思います。

未記入さんの書き込み (2008-05-10 09:49) より:
単純に「ないものは作ればよい」なんて言っている人は、システム設計能力の低いバカだと思います。うちの会社にも「提示された仕様どおりに実現しなくては」と、ものすごい工数をかけて作業している人がいますがバカですね。「この仕様をちょっとこう変更したら簡単に作れるんですが」くらいのこと言えんのかと。

正直、プログラマというかIT技術者に向いてないんじゃね？

高レベルとか低レベルとかの定義をどうするかという問題もあるが、貴方の定義の話で行くなら、言語としての基本実装は低レベルであるべき。と自分は思ってますよ。

低レベルって言うのは逆に言えば、組み合わせる事によって出来る事の幅が広がる状態。
高レベルといって言語側に全てを用意させようとしたら、ちょっとした不満点があるたびにこの要求に合うオブジェクトを用意しろと、いって、大量の重複ライブラリを要求するだけにしかならない。

既存の物で全てを賄いたい、自分では作りたくないって言うなら、

「ないものは作ればよい」という考えがあるからこそ、巨額の金額が投資されてプロジェクトが立ち上がってるわけだ。「ないものは作ればよい」という理由で仕事にありついているのに、言語側で全てを用意しろというなら、それは単なる自己否定じゃないかね？

プログラムを趣味でやってるなら、我侭言い放題でもかまわないが、仕事としてやってるんだろ？

「ないものは作ればよい」を自然と実践できない時点で、プロ失格ただの素人だと思いますよ

ぶさいくろうさんがおっしゃっているのは「WM_PASTEに応答する方法は知っているけど、使いたくない」という意思表示かと。

未記入さんの書き込み (2008-05-10 00:33) より:
そこまで意思表示しないといけませんでしたか。ここの回答者の方々は質問者に対する要求レベルがずいぶんと高いようですね。私に言わせれば、今回の件では、質問の質より、ぶさいくろうさんの回答の質のほうが低いと感じました。

私だったら「よくある質問」「検索結果の上位にピンポイントで回答が出てくる」ようなときくらいしか「○○で検索して」という回答はしません。今回は、検索結果の上位にピンポイントの回答は出てきませんでした。

私の要求レベルが、ぶさいくろうさんには理解できなかったのだと思いますが「Java には

・KeyDown を処理する方法だとクリップボードからのペーストに対応できない。
・TextChanged は発生時点で Text が変更されているので手遅れ。
・MaskedTextBox で対応できるような簡単な入力制限ではない。

やはりそうなりますか…。

未記入さんの書き込み (2008-05-10 09:49) より:
「やはりウィンドウメッセージを使わないといけませんか。」
「期待はずれでした。」
「あきらめてウィンドウメッセージを使います。」

という私の出した結論に何か問題がありましたか？ 私は、これでこのスレはクローズするものと思っていましたが「知っていて聞いていたのならそう書いておけばよかったのに。」という自分の回答の稚拙さを棚に上げて、質問者には高いレベルを要求する発言がありましたので、検索を促すだけの回答のほうが質が低い、私ならそういう回答はしないという考えを述べました。質問するなら最低限のことは書かなくてはいけない、同じように、回答するなら最低限のことは書いたほうがいいと思います。それだけのことです。

実は俺はWM_PASTEやWM_CHARで捉える方法は知らないんじゃないかと思って書いたんだね。
なぜかっていうと。

とあったのでそういう意味でも「知っていたなら」と書いた。

DocumentFilterみたいなものを作るのなら根本的にいちからコントロールを作って自分で描画するようなコントロールでないと結局WM頼りになりかねないと思われる。（といってもベースがControlなだけでWMレベルのものがもとからあったりするんだけど）

unibonさんの書き込み (2008-05-10 15:28) より:
しかし、そういう回答をする回答者が、自分を棚に上げて質問者を責めれば、それは不公平だと感じます。

未記入さんの書き込み (2008-05-10 15:40) より:
.NET Framework で WndProc をオーバーライドできてウィンドウメッセージを扱えるということは知っていました。ですが、どのメッセージを捉えなければいけないかなど、具体的にどうするかという知識は持っていませんでした。WM_PASTE は VB6.0 で利用したことがある程度です。

この程度の認識なので「がんばってウィンドウメッセージを弄べば実現できないことはないだろう、という認識は持っていました。」ということを後になって書きました。

最初の質問時点で書くとしたら「ウィンドウメッセージ使えば実現できなくはないと思いますが」と前置きしたほうがベターだったとは思います。ただ、ここまで冗長な説明記述を質問者に要求するのは、いかがなものかと(いまだに)思っています。

そして、いま実装をはじめようとしていて、いろいろと調べたり実験したりしています。コードによるドキュメント(テキスト)に対応するには、WM_CHAR, WM_PASTE だけでなく、WM_SETTEXT も拾わないといけないのか？ WM_CHAR は拾わなくても KeyDown でいけるのか？とか調べている最中です。

さすがにそこまでやるのは(私には)無理です。それはキャレットや文字反転色などの表示も自分で描画するってことでしょう？ そこまでやろうとすると、Swing や WPF のようなライトウェイトコンポーネントフレームワークを自作するようなイバラの道のように思えますので、今回は TextBox のサブクラスで実現できるか模索してみます。