|
念のための確認ですが、WebアプリではなくWindowsアプリについての質問ということでよいですね？
■No30709 (水虫中 さん) に返信
> (char)e.KeyData
このコードは意味的に正しくありません。
e.KeyCodeはKeys列挙型で、押されたキーのキーコードがセットされます。文字コードではありません。
e.KeyDataもKeys列挙型ですが、こちらは通常のキーだけでなく、修飾キー(Shift、Ctrl、Alt)が押されている場合は、
修飾キーのキーコードも加算された(正確には論理和をとった)値がセットされます。
e.KeyCodeもe.KeyDataも意味的に文字ではありませんので、charにキャストするのは意味がありません。
キーコードの内部値の整数のうち2バイト分をcharにキャストした結果になります。
> で入力文字はカンマ,にするとなぜかR四分の三という文字列が入りカンマと一致しません。
"1/4"を表現した文字ではありませんか？
私のところで試したところそのような結果になりました。
(188は16進数では00BCで、UNICODEの文字コード表で調べた結果とも一致しています)
> カンマが入力されたときの処理を切り分けたいのですがR四分の三と＝＝で結ばれるものは何なんでしょうか。
> または別方法で結び付けられるのでしょうか。基本的にはe.KeyDataで処理をしている為それを使いたいです。
説明にないのですが、何のイベントで処理されているのですか？
状況からするとKeyDown/KeyUpイベントのどちらかだと思いますが、
「,」という文字が入力されたかどうかで処理をしたいのであれば、
KeyDown/KeyUpイベントではなくKeyPressイベントでe.KeyCharを見て判断してください。
「,」という文字が入力されたかでなく、あくまで「,」キーが押されたかどうかを判断したいのであれば、
e.KeyCode == Keys.Oemcomma
の比較をすればよいです。
(e.KeyDataを使ってもよいですが、こちらを使う場合は、単純に==で比較するのではダメで、&演算子でビット演算をしてください)
> あとe.KeyCodeですと188が返ってくるので切り分けは出来ますがe.KeyDataで試したいということがあります、
上記の説明で書いたことと重複しますが、188というマジックナンバーではなく、Keys列挙型のOemcommaを使いましょう。
> もう一つご質問ですがなぜカンマで188になるのかがわかりません。アスキーコードでは44が返ってくるはずなんです
ASCIIコードではなくキーコードだからです。
|