Tom Yama さん harasawa（原沢信道）です
「非常に喜ばしくかつ、うれしく思っています」、と書かれていますが、あなたにとってに何が喜ばしくて、かつ、うれしいのか、具体的的に教えてください。
また、Windows本体での対応がなぜ必要なのかも、具体的に教えて下さい。
まったく私とは正反対の意見とお見受けしますので、非常に興味があります、新たな発見が期待できそうですので、是非、具体的に教えてください。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
一Windows「ユーザ」として、今回のMSの英断を非常に喜ばしく、かつ、うれしく思っております。
惜しむらくは、.Net Framework2.0「のみ」での対応という点です。
Windows本体での対応も、是非ともご検討願いたいと存じます。
↧
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
ツール作りで一番注意しなければならない事は、ルールを単純にする事です、FormやUserControlではIMEを使わないだろうと考える事は単純でしょうか、この場合は、使うことは正しい事か、正しくない事か判断し、正しくないとすれば、その結果としては、無効にする事は正しい選択です、しかし、日本語以外の文字は入力出来ます、正しくないとすれば、いかなる文字も入れられないが単純なルールとなります、しかし、このような事は無いでしょう、FormやUserControlで英語が入れられて、日本語は入れられない事は、単純なルールとは私には思えません。
私のFormのIME問題で動かなくなったソフトも.NET Framworkとは言いませんが、基幹システムを簡単に開発する事のできるソフト開発用ソフトです、当然プログラムの文法も単純を意識して作っています、単純な文法のソフトは、結果として、自分が思いもつかなかった、使い方をする人が出てきて驚かされます、でも、単純なルールですので、間違った使い方ではないのです、人間の想像力はすごいです。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
あっ、大事なことを忘れていました。
Beta2 の後になって仕様変更したことには、反省しきりです。今後は極力こういうことのないように気をつけます。また、情報発信に関しても、我々の（永遠の？）課題と思います。
重ね重ね、貴重なご意見ありがとうございました。
まとめに入っているみたいになってしまいましたが、ご意見がございます方は引き続きお願いします。
この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
trapemiya 様、皆様
ありがとうございます。私の未熟な文章にもかかわらず、完全に設計の本意を汲み取っていただけたことに感激するとともに、一般的なシナリオに関してご理解いただけたことに感謝いたします。
今から思えば、前回のコメントの中で、UserControl が独自のコントロールを作成するための基本クラスではなく、基本的なコントロールを組み合わせて高機能なコントロールを簡易的に作成するためのコンテナであるという点を明確にしておくべきでした。
しかし、trapemiya 様も皆様も決して現状の仕様に満足ではないと思いますし、私自身も日本人の開発者の一人として、非常に基本的な IME の制御のために Interop を使用しなくてなならないこと、実装上の都合とはいえ開発者の方々の自由度を制限してしまっている現状には決して満足しておりません。将来的には、IME をマネージで完全にコントロールできるようにするのに合わせ、極力互換性を維持しつつ開発者の方々の自由度をあげていきたいと考えておりますが、その設計においても皆様の声なしには使いやすいものには成り得ないと思います。
コンテナでの動作を選択可能にできるかどうかに関しては、引き続き次期バージョンにて検討させていただきます。
今後も、仕様に関する疑問点や問題のご指摘等、お気づきの点がございましたら、どんどんご意見をいただければ幸いです。
NyaRuRu 様、マネージのIMMに関しては、リファレンスのみで恐縮ですが、現状では、WinFX の System.Windows.Input.InputMethod をご覧になっていただくのが良いように思います。
この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。
↧
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
本筋と離れてしまい申し訳ありませんが，
| ディベロッパー製品開発統括部インターナショナルPM - MSFT は書きました: | |
|
このあたりの情報をいただけますか？
ちなみに昔個人的に TSF (Text Serices Framework) のマネージドラッパーを自作したことがあります．マネージドコードでいわゆる IME を作れるところまでは持って行ってますが，時間が無くてそのまま放置気味ですけど．
| trapemiya は書きました: | |
|
世間では余り知られていませんが，TSF という完全 COM な IMM の後継は5年ぐらい前から存在して，Office や Internet Explorer，Richedit Control などがサポートしています．
日本語変換周りで大変なのは，本来テキスト入力を行うコントロール側にも実装が必要なところです．
.NET が使用するエディットボックスなどは，コモンコントロールが IMM API を内部的に処理してくれているからこそ当然のように IME を使用できています．しかし TSF を利用するにはさらに追加実装が必要です．(これについては Windows XP などではコモンコントロール側での対応が可能となっていますが，デフォルトではオフになっています)
例えばゲームなどではコモンコントロールは使用できないので IMM 系の API を使用して IME 入力を受け付けるコードを自前で実装することが行われています．
IMM 関係で一番おすすめできるサンプルコードが DirectX に付属するサンプルコードだったりするのは何とも皮肉な話ですけど．
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
>もともとは，
> ScrollableControl が Canvas に相当すると考えればいいのかもしれません。
そういう方向に統一していくのが良いと思います。これまでは幸か不幸かFormやUserControlで直接日本語が受け取れ、それを利用していた開発者が思いのほか多かったという点で、MSFTさんと開発者側でずれがあったわけですよね。MSFTさんとしてもそういう使い方をしている人はほとんどいないだろうということで、今回問題になっている仕様に決められたんだと思います。
でも、私も、MSFTさんの方針が本来正しいと思いますので、そちらの方向で統一していく方がいいのかなぁ、なんて思ったりします。以下のボタンなんかをおいた場合の問題も出てきますし。
ただ、やっぱり急な（ベータ２からRTM)仕様変更で現状で困っている人がいるわけで、そこら辺りの対策をどうするかですね・・・
>---------------------------------------------
ちょっと上の方の私のコードだけど，
やっぱり，ボタンとか置かれちゃうとうまく動かないのと，
（ボタンのTabStopをfalseにすればいいんですが）
なんとなく怪しげなのとアンマネジドなのを考えると，
>---------------------------------------------
でも、現状ではimm系を使わざるを得ないので、アンマネイジドはしょうがないんですよね。
はやく、マネイジドになればいいなぁ。楽だし。(^^;
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
ちょっと上の方の私のコードだけど，
やっぱり，ボタンとか置かれちゃうとうまく動かないのと，
（ボタンのTabStopをfalseにすればいいんですが）
なんとなく怪しげなのとアンマネジドなのを考えると，
やっぱり，
ScrollableControl をクライアント領域いっぱいに貼り付ける方がいいですね。
それだと，ボタンとか置いても大丈夫ですし。
（ScrollableControl にフォーカスを移せるので）
それにデザイン画面上で ScrollableControl を選択できますね。
初めて知りました。
ちゃんとプロパティが表示できてビックリしました。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
WPF の Window ではどうなる予定なんでしょうか。
IEの画面ライクなわけだから，それは，きっと，強制オフですよね。
だったら，
IMMのマネジド版も出るんだったら，まぁしょうがないかなぁ。
入力状態でなくても，ON にしたいというのは，
UserControl を Container でなく Canvas として使おうとしている
という感じなんじゃないかと思うんだけど。
もともとは，
ScrollableControl が Canvas に相当すると考えればいいのかもしれません。
>----------------------------------------------------------------------------------------
話はそれるんですが...
VBライブラリ名前空間内の変換関数ですが，
参照設定すればいいだけの話なので，
もちろん，今のところそれでいいんだけど，
そのCicero という名前のマネジドIMMが出るのだったら，
・ ひらがな <---> カタカナ 変換
・ 半角ｶﾀｶﾅ <---> 全角カタカナ 変換
・ 半角数字 <---> 全角数字 変換
・ 半角英字 <---> 全角英字 変換
・ 半角記号 <---> 全角記号 変換
なメソッドがあってくれたら，いいのになぁと思いました。
↧
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
>--------------------------------------------
ｱﾝマネージAPI の問題に関しては、Cicero のマネージインターフェースを提供する方向で検討しております。
>--------------------------------------------
なるほど。おっしゃっていることがだいぶわかってきました。
日本語入力を受け付けることを想定していない作りになっているもの、例えばFormやUserControlにとって、ＩＭＥがオンになっていると、確かに一般的には邪魔だと思います。
おっしゃるように、フローティングのＩＭＥ変換ウインドウが表示されてしまうとか、ショートカットキーが使えないといった不具合が発生するでしょう。
そこで、これらを解消するために、ＩＭＥを強制的にオフにするようにしたということですね？
確かに一般的にはFormやUserControlといったコンテナ色が強いコントロールで、直接日本語を受け取る機会は少ないでしょう。日本語入力を受け取るからには、日本語入力を制御しない場合は考えにくい。となると、imm系というアンマネージドな世界に足を踏み込まなければならない。こういう使い方はかなりレアケースではないか？アンマネージドな世界だし。であれば、ＩＭＥを強制的にオフにした方が良いのではないか？
ということで、今回の仕様になったんだと理解しました。このことは、冷静に考えれば、非常に理にかなっていると思います。
Ciceroになってマネージドになれば、日本語入力の制御が.NETの世界だけでできるようになるので（たぶん）、日本語入力を想定していないFormやUserControlでも、日本語入力を直接受け取って制御するアプリの作成を、.NETとして肯定できるようになる。したがって、強制的にＩＭＥをオフにするのはやめて、開発者に制御をまかせようという方向ですね？ ただやっぱり強制的にＩＭＥをオフにするプロパティは必要だと思いますが。
英語圏では何の問題もなくFormやUserControlに直接文字を入力できるので、ＩＭＥを抱えた国の問題なのでしょうが、やはり英語圏と同じように日本語という文字を受け付けるのが良いのかもしれません。
ただ、私の考えも微妙になってきてまして、FormやUserControlでは必要ないのかな？と思ったりもします。これらはやはりコンテナとして使うのが一般的だと思うからです。
代替としてはFormにPanelを貼ったり、ScrollableControlやControlを継承したカスタムコンポーネントを貼るということでしょうか？
でも、やっぱり面倒なので、FormやUserControlはデフォルトでＩＭＥが強制オフで、それを開発者が解除できるのが一番かなぁ。難しいみたいですが・・・
＃勝手に想像している部分もあるので、間違いあればご指摘下さい。
>--------------------------------------------
IMM の呼び出しは無しでもIME がコンテナ上で有効になるだけで有益というシナリオがいまひとつイメージできていません。
>--------------------------------------------
私も一般的には少ないと思います。私は縦書き可能なワープロっぽいものを作成中なのですが、imm系はもちろん使っています。特に変換ウインドウを縦書き用に出すには必須だと思います。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
回避と言う意味では良いのですが.NET Framework上で動くのでWindows上で動くと想定したコーディングは対抗感があります、簡易ツールですのでやはりWindows上ではなく.NET Framework上で動く事が保障され、使用法としても認知され、将来においても問題の出ないツールとしたいです。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
とりあえず上のコードで回避できないのかな？
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
私はhttp://www.mis.janis.or.jp/~harasawa/でも公開していますが、簡易ツールを作っています、簡易ツールですので画面上に複雑な物は無く単なるキャンバスとして使いたいだけです、全てをプログラム側で対応しています、したがって、日本語を含めて全てのキー情報を常時プログラムが無条件で受け取れれば良いだけです、ＤＯＳの時代にはC言語でカーサスライブラリ(すみません間違えました、カーサスライブラリはUNIX用でした、DOS用はエスケープシーケンスです)でキャラクタ画面に表示した物を、Windowsに移植し、今回はＣ＃で再構築しています、DOS時代から.NET Framework２．０ Beta2までは何の問題も無くできました、初期のプログラムから既に１５年も掛けていますので、ここで捨て去るには忍びないです、それほど難しい話ではなく、常時IMEが無条件に有効になっていてくれれば、私のプログラムの場合は良いのです、もちろん、デフォルトでは無効でも構いません、コーディングを付加でもかまいませんので、是非Beta２までの状態のように、「常時IMEが無条件に有効」が実現できる方向で検討をよろしくお願いします。
割り込んでしまってすみません、これが解決しないと、まったく前に進めないので、勘弁して下さい。
↧
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
皆様、ご意見ありがとうございます。
ｱﾝマネージAPI の問題に関しては、Cicero のマネージインターフェースを提供する方向で検討しております。
実装上の制約もありますので、動作変更のお約束はできません（特に選択可能にするのが難しいです）が、かなり要望が多いようなので、次期バージョンではぜひ改善を検討させていただきたいと思います。
そのためには、まず皆様の要望をただしく理解することが大事だと思いますので、お忙しいとは思いますが、もう少しお付き合い願えますでしょうか？
私としては上でも書かせていただきましたが、キチンと日本語に対応したアプリケーションであれば、変換ウィンドウは表示されるべきではないと考えています。その前提にたつと、日本語IMEは状態を見ながら変換する必要があるため、変換ウィンドウを表示せずに日本語入力を受け付けるためには、変換状態をどこかに表示する必要があり、そのためには、IMM を呼び出さざるを得ないと考えています。これが、Cicero (IMM の後継）のマネージ化での対応を重視している理由でもあります。
私が何か大事なシナリオを見落としているのだと思いますが、、IMM の呼び出しは無しでもIME がコンテナ上で有効になるだけで有益というシナリオがいまひとつイメージできていません。
そこで、こういうシナリオで必要になるという例のようなものを1つでも多くいただけると非常に助かります。
よろしくお願いいたします。
この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
IE だと，入力を受け付ける箇所にフォーカスが入っていないと，
IME が ON にならなくなっているので，
それとあわせたのかもしれませんが...。
ただ，アンマネジドAPIを呼び出すと，
Full Trust でないと動かないので，
微妙に具合が悪いですね。特に，UserControl の場合。
Form は IE と動作が一緒の方がいいと思うので，ともかく，
UserControl だけでも，元に戻ってくれると
いいような気がするんだけど。
そういうことは難しいのかなぁ～。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
上の文字化けの件ですが，一から書き直したら，
直りました。
直りました。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
追記: defaultラベル は，編集しました。
↧
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
編集したら，? に化けて，二度と戻らなくなってしまいました。
直書きしているので，default は打ち損ねました。
(一応，テストしました)
デフォルトの状態に戻しているだけです。
でも，これで大丈夫なのか? は不明です。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
なんだか日本語のところが？に化けてて読めないんですが、コードから判断するに、ＩＭＥをデフォルトに戻して、バイパスですね。
なるほど。確かにこうすうるとうまくいきますね。
とりあえずUserControlを継承したコントロールで日本語入力を行うには、対処療法ですが、この手でいけますね。
いつもながらするどいコードを、ありがとうございました。
＃そうだ。細かいですが、最後のdefaultのスペルが違ってます。コンパイルが通りませんでしたよ。(^^; ひょっとして動かさずに書いてるんですか？ すごいなぁ。
↧
UserControlを継承したコントロールではIMEが強制的にOFFになる。
例えば，デフォルトの状態に戻すのだったら
static class Win32
{
// dwFlags for ImmAssociateContextEx
[Flags]
public enum ImmAssociateContextExFlags : uint
{
IACE_CHILDREN = 0x0001,
IACE_DEFAULT = 0x0010,
IACE_IGNORENOCONTEXT = 0x0020
}
[DllImport("Imm32.dll")]
public static extern bool ImmAssociateContextEx(
IntPtr hWnd,
IntPtr hIMC,
ImmAssociateContextExFlags dwFlags);
[DllImport("imm32.dll")]
public static extern IntPtr ImmGetContext(IntPtr hwnd);
[DllImport("imm32.dll")]
public static extern bool ImmSetOpenStatus(IntPtr hIMC, bool flag);
}
のようにしておいて，WndProcをオーバーライドして
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
//#define WM_IME_SETCONTEXT 0x0281
case 0x0281:
bool rc = Win32.ImmAssociateContextEx(
this.Handle,
new IntPtr(0), //<-無視されます//
Win32.ImmAssociateContextExFlags.IACE_DEFAULT);
if (rc)
{
//IntPtr himc = Win32.ImmGetContext(this.Handle);
//rc = Win32.ImmSetOpenStatus(himc, true);
DefWndProc(ref m);
}
else
{
base.WndProc(ref m);
}
break;
default:
base.WndProc(ref m);
break;
}
}
かな。
追記: defaultの綴りを，修正しました。
↧