Quantcast
Channel: UserControlを継承したコントロールではIMEが強制的にOFFになる。
Viewing all 104 articles
Browse latest View live

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

ご回答ありがとうございます。

>-----------------------------------------------------
これは仕様変更によるものです。2.0 ではキー入力を持つコントロールとキー入力を持たないコントロールに分け、キー入力を持たないコントロールでは、IME が機能しないように変更いたしました。
>-----------------------------------------------------

この仕様変更は、私は少し抵抗があります。もしそのような仕様変更であれば、UserControlが持っているImeModeプロパティはほとんど意味がないものになってしまいます。実際、ImeModeプロパティで、ImeMode.Hiraganaを指定しても無視されます。

日本語キー入力を受け付ける、受け付けないは、開発者に選択させてもよかったのではないでしょうか?

>-----------------------------------------------------
そうするためには、単純にIMEが使える使えないではなく、どうしても、IME(IMM)関連のメッセージに応じたり、メソッドを呼び出す必要が出てきます。残念ながら現状ではこれらの対応を行うためには低レベルなメソッドを呼び出す必要があります。
>-----------------------------------------------------

imm関連のAPIを実際に呼び出していますが、やはり日本語入力モードには移行しません。ただ、これに関しては私の調査が足りないのかもしれません。

>-----------------------------------------------------
キー入力を受け付ける場合は、Contorl や TextBox (BorderStyle=None, BackColor=Control, Multiline=true)等を全面に貼り付けて使用してください。
>-----------------------------------------------------

現状はScrollableControlを継承することにより、カスタムコントロールを作成しています。

#この件に関しては昨日、インシデントを発行しております。


UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

これは仕様変更によるものです。2.0 ではキー入力を持つコントロールとキー入力を持たないコントロールに分け、キー入力を持たないコントロールでは、IME が機能しないように変更いたしました。

キー入力を持たないと言っても、実際にはIMEを通さないキーイベントは挙がります。正確には、言葉として意味のある文字列を入力することを期待するコントロールと、ショートカット等のウィンドウをコントロールするためのキー入力のみを受け付けるコントロールと表現すべきでしょうか。

この変更は、ユーザーからの要望に基づいて行われたものですが、IMEをオフにすることなくショートカットが使用できるようにするためです。また、不必要なIMEウィンドウの表示を抑制するためでもあります。

一方、ご指摘のように、通常は入力を持たないようなコントロール上でもキー入力を受け付けたいというシナリオは確かにあると思います。しかし、単にIMEが機能すればそれで良いという場合は少なく、通常はフローティングのIMEウィンドウを出すことなく、描画も含めて自分自身でコントロールする場合が殆どです。そうするためには、単純にIMEが使える使えないではなく、どうしても、IME(IMM)関連のメッセージに応じたり、メソッドを呼び出す必要が出てきます。残念ながら現状ではこれらの対応を行うためには低レベルなメソッドを呼び出す必要があります。

このようなことを総合的に検討した結果、仕様変更させていただきました。この変更により作業が発生してしまう方には大変申し訳ありませんが、何卒ご理解のほどよろしくお願いいたします。

キー入力を受け付ける場合は、Contorl や TextBox (BorderStyle=None, BackColor=Control, Multiline=true)等を全面に貼り付けて使用してください。

この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

> ↓なんかフッタの表示が変なんですが・・・

シグネチャがおかしいですね。
Table 要素の閉じミスかなぁ、ということで返信テストしてみます。

# 変わらず...

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

>というよりは、ContainerControl 以下のクラス全体が怪しいですね。

あ~、なるほど。そうなんですか・・・orz そこまで調べてませんでした。
もし仕様変更なら、1.1の時のように受け付けるようにしてもらいたいなぁ。
とりあえず私はScrollableControlの継承で今のところ問題ないんですけどね。

#でも仕様変更というより、何かの不具合のような気がしてます。・・・

↓なんかフッタの表示が変なんですが・・・
 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

というよりは、ContainerControl 以下のクラス全体が怪しいですね。
1.1 では受け付けるんですが、2.0 では受け付けないようです。
仕様変更?

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0
UserControlを継承したコントロールにおいてIME(日本語入力)を行うとすると、強制的にIMEがOFFになり、日本語入力ができません。ちなみに、ScrollableControlでは問題ありません。

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

Tom Yama さん harasawa(原沢信道)です

「非常に喜ばしくかつ、うれしく思っています」、と書かれていますが、あなたにとってに何が喜ばしくて、かつ、うれしいのか、具体的的に教えてください。

また、Windows本体での対応がなぜ必要なのかも、具体的に教えて下さい。

まったく私とは正反対の意見とお見受けしますので、非常に興味があります、新たな発見が期待できそうですので、是非、具体的に教えてください。

 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

一Windows「ユーザ」として、今回のMSの英断を非常に喜ばしく、かつ、うれしく思っております。

惜しむらくは、.Net Framework2.0「のみ」での対応という点です。

Windows本体での対応も、是非ともご検討願いたいと存じます。

 


UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

ツール作りで一番注意しなければならない事は、ルールを単純にする事です、FormやUserControlではIMEを使わないだろうと考える事は単純でしょうか、この場合は、使うことは正しい事か、正しくない事か判断し、正しくないとすれば、その結果としては、無効にする事は正しい選択です、しかし、日本語以外の文字は入力出来ます、正しくないとすれば、いかなる文字も入れられないが単純なルールとなります、しかし、このような事は無いでしょう、FormやUserControlで英語が入れられて、日本語は入れられない事は、単純なルールとは私には思えません。

私のFormのIME問題で動かなくなったソフトも.NET Framworkとは言いませんが、基幹システムを簡単に開発する事のできるソフト開発用ソフトです、当然プログラムの文法も単純を意識して作っています、単純な文法のソフトは、結果として、自分が思いもつかなかった、使い方をする人が出てきて驚かされます、でも、単純なルールですので、間違った使い方ではないのです、人間の想像力はすごいです。

 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

あっ、大事なことを忘れていました。

Beta2 の後になって仕様変更したことには、反省しきりです。今後は極力こういうことのないように気をつけます。また、情報発信に関しても、我々の(永遠の?)課題と思います。

重ね重ね、貴重なご意見ありがとうございました。

まとめに入っているみたいになってしまいましたが、ご意見がございます方は引き続きお願いします。

この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。

 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

trapemiya 様、皆様

ありがとうございます。私の未熟な文章にもかかわらず、完全に設計の本意を汲み取っていただけたことに感激するとともに、一般的なシナリオに関してご理解いただけたことに感謝いたします。
今から思えば、前回のコメントの中で、UserControl が独自のコントロールを作成するための基本クラスではなく、基本的なコントロールを組み合わせて高機能なコントロールを簡易的に作成するためのコンテナであるという点を明確にしておくべきでした。

しかし、trapemiya 様も皆様も決して現状の仕様に満足ではないと思いますし、私自身も日本人の開発者の一人として、非常に基本的な IME の制御のために Interop を使用しなくてなならないこと、実装上の都合とはいえ開発者の方々の自由度を制限してしまっている現状には決して満足しておりません。将来的には、IME をマネージで完全にコントロールできるようにするのに合わせ、極力互換性を維持しつつ開発者の方々の自由度をあげていきたいと考えておりますが、その設計においても皆様の声なしには使いやすいものには成り得ないと思います。

コンテナでの動作を選択可能にできるかどうかに関しては、引き続き次期バージョンにて検討させていただきます。

今後も、仕様に関する疑問点や問題のご指摘等、お気づきの点がございましたら、どんどんご意見をいただければ幸いです。

NyaRuRu 様、マネージのIMMに関しては、リファレンスのみで恐縮ですが、現状では、WinFX の System.Windows.Input.InputMethod をご覧になっていただくのが良いように思います。

http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref32/html/P_System_Windows_Input_InputMethod_ImeConversionMode.asp

この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。

 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

本筋と離れてしまい申し訳ありませんが,

 ディベロッパー製品開発統括部インターナショナルPM - MSFT は書きました:

皆様、ご意見ありがとうございます。

これが、Cicero (IMM の後継)のマネージ化での対応を重視している理由でもあります。

このあたりの情報をいただけますか?

ちなみに昔個人的に TSF (Text Serices Framework) のマネージドラッパーを自作したことがあります.マネージドコードでいわゆる IME を作れるところまでは持って行ってますが,時間が無くてそのまま放置気味ですけど.

 trapemiya は書きました:

でも、現状ではimm系を使わざるを得ないので、アンマネイジドはしょうがないんですよね。
はやく、マネイジドになればいいなぁ。楽だし。(^^;

世間では余り知られていませんが,TSF という完全 COM な IMM の後継は5年ぐらい前から存在して,Office や Internet Explorer,Richedit Control などがサポートしています.

日本語変換周りで大変なのは,本来テキスト入力を行うコントロール側にも実装が必要なところです.
.NET が使用するエディットボックスなどは,コモンコントロールが IMM API を内部的に処理してくれているからこそ当然のように IME を使用できています.しかし TSF を利用するにはさらに追加実装が必要です.(これについては Windows XP などではコモンコントロール側での対応が可能となっていますが,デフォルトではオフになっています)

例えばゲームなどではコモンコントロールは使用できないので IMM 系の API を使用して IME 入力を受け付けるコードを自前で実装することが行われています.
IMM 関係で一番おすすめできるサンプルコードが DirectX に付属するサンプルコードだったりするのは何とも皮肉な話ですけど.

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

>もともとは,
> ScrollableControl が Canvas に相当すると考えればいいのかもしれません。

そういう方向に統一していくのが良いと思います。これまでは幸か不幸かFormやUserControlで直接日本語が受け取れ、それを利用していた開発者が思いのほか多かったという点で、MSFTさんと開発者側でずれがあったわけですよね。MSFTさんとしてもそういう使い方をしている人はほとんどいないだろうということで、今回問題になっている仕様に決められたんだと思います。
でも、私も、MSFTさんの方針が本来正しいと思いますので、そちらの方向で統一していく方がいいのかなぁ、なんて思ったりします。以下のボタンなんかをおいた場合の問題も出てきますし。
ただ、やっぱり急な(ベータ2からRTM)仕様変更で現状で困っている人がいるわけで、そこら辺りの対策をどうするかですね・・・

>---------------------------------------------
ちょっと上の方の私のコードだけど,
やっぱり,ボタンとか置かれちゃうとうまく動かないのと,
(ボタンのTabStopをfalseにすればいいんですが)
なんとなく怪しげなのとアンマネジドなのを考えると,
>---------------------------------------------

でも、現状ではimm系を使わざるを得ないので、アンマネイジドはしょうがないんですよね。
はやく、マネイジドになればいいなぁ。楽だし。(^^;

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

ちょっと上の方の私のコードだけど,
やっぱり,ボタンとか置かれちゃうとうまく動かないのと,
(ボタンのTabStopをfalseにすればいいんですが)
なんとなく怪しげなのとアンマネジドなのを考えると,

やっぱり,
ScrollableControl をクライアント領域いっぱいに貼り付ける方がいいですね。
それだと,ボタンとか置いても大丈夫ですし。
(ScrollableControl にフォーカスを移せるので)

それにデザイン画面上で ScrollableControl を選択できますね。
初めて知りました。
ちゃんとプロパティが表示できてビックリしました。

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

WPF の Window ではどうなる予定なんでしょうか。
IEの画面ライクなわけだから,それは,きっと,強制オフですよね。
だったら,
IMMのマネジド版も出るんだったら,まぁしょうがないかなぁ。

入力状態でなくても,ON にしたいというのは,
UserControl を Container でなく Canvas として使おうとしている
という感じなんじゃないかと思うんだけど。
もともとは,
 ScrollableControl が Canvas に相当すると考えればいいのかもしれません。

 

>----------------------------------------------------------------------------------------
話はそれるんですが...

VBライブラリ名前空間内の変換関数ですが,
参照設定すればいいだけの話なので,
もちろん,今のところそれでいいんだけど,
そのCicero という名前のマネジドIMMが出るのだったら,
 ・ ひらがな <---> カタカナ 変換
 ・ 半角カタカナ <---> 全角カタカナ 変換
 ・ 半角数字 <---> 全角数字 変換
 ・ 半角英字 <---> 全角英字 変換
 ・ 半角記号 <---> 全角記号 変換
なメソッドがあってくれたら,いいのになぁと思いました。


UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

>--------------------------------------------
アンマネージAPI の問題に関しては、Cicero のマネージインターフェースを提供する方向で検討しております。
>--------------------------------------------

なるほど。おっしゃっていることがだいぶわかってきました。

日本語入力を受け付けることを想定していない作りになっているもの、例えばFormやUserControlにとって、IMEがオンになっていると、確かに一般的には邪魔だと思います。
おっしゃるように、フローティングのIME変換ウインドウが表示されてしまうとか、ショートカットキーが使えないといった不具合が発生するでしょう。
そこで、これらを解消するために、IMEを強制的にオフにするようにしたということですね?
確かに一般的にはFormやUserControlといったコンテナ色が強いコントロールで、直接日本語を受け取る機会は少ないでしょう。日本語入力を受け取るからには、日本語入力を制御しない場合は考えにくい。となると、imm系というアンマネージドな世界に足を踏み込まなければならない。こういう使い方はかなりレアケースではないか?アンマネージドな世界だし。であれば、IMEを強制的にオフにした方が良いのではないか?
ということで、今回の仕様になったんだと理解しました。このことは、冷静に考えれば、非常に理にかなっていると思います。

Ciceroになってマネージドになれば、日本語入力の制御が.NETの世界だけでできるようになるので(たぶん)、日本語入力を想定していないFormやUserControlでも、日本語入力を直接受け取って制御するアプリの作成を、.NETとして肯定できるようになる。したがって、強制的にIMEをオフにするのはやめて、開発者に制御をまかせようという方向ですね? ただやっぱり強制的にIMEをオフにするプロパティは必要だと思いますが。

英語圏では何の問題もなくFormやUserControlに直接文字を入力できるので、IMEを抱えた国の問題なのでしょうが、やはり英語圏と同じように日本語という文字を受け付けるのが良いのかもしれません。
ただ、私の考えも微妙になってきてまして、FormやUserControlでは必要ないのかな?と思ったりもします。これらはやはりコンテナとして使うのが一般的だと思うからです。
代替としてはFormにPanelを貼ったり、ScrollableControlやControlを継承したカスタムコンポーネントを貼るということでしょうか?
でも、やっぱり面倒なので、FormやUserControlはデフォルトでIMEが強制オフで、それを開発者が解除できるのが一番かなぁ。難しいみたいですが・・・

#勝手に想像している部分もあるので、間違いあればご指摘下さい。

>--------------------------------------------
IMM の呼び出しは無しでもIME がコンテナ上で有効になるだけで有益というシナリオがいまひとつイメージできていません。
>--------------------------------------------

私も一般的には少ないと思います。私は縦書き可能なワープロっぽいものを作成中なのですが、imm系はもちろん使っています。特に変換ウインドウを縦書き用に出すには必須だと思います。

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

回避と言う意味では良いのですが.NET Framework上で動くのでWindows上で動くと想定したコーディングは対抗感があります、簡易ツールですのでやはりWindows上ではなく.NET Framework上で動く事が保障され、使用法としても認知され、将来においても問題の出ないツールとしたいです。

 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0
とりあえず上のコードで回避できないのかな?

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

私はhttp://www.mis.janis.or.jp/~harasawa/でも公開していますが、簡易ツールを作っています、簡易ツールですので画面上に複雑な物は無く単なるキャンバスとして使いたいだけです、全てをプログラム側で対応しています、したがって、日本語を含めて全てのキー情報を常時プログラムが無条件で受け取れれば良いだけです、DOSの時代にはC言語でカーサスライブラリ(すみません間違えました、カーサスライブラリはUNIX用でした、DOS用はエスケープシーケンスです)でキャラクタ画面に表示した物を、Windowsに移植し、今回はC#で再構築しています、DOS時代から.NET Framework2.0 Beta2までは何の問題も無くできました、初期のプログラムから既に15年も掛けていますので、ここで捨て去るには忍びないです、それほど難しい話ではなく、常時IMEが無条件に有効になっていてくれれば、私のプログラムの場合は良いのです、もちろん、デフォルトでは無効でも構いません、コーディングを付加でもかまいませんので、是非Beta2までの状態のように、「常時IMEが無条件に有効」が実現できる方向で検討をよろしくお願いします。

割り込んでしまってすみません、これが解決しないと、まったく前に進めないので、勘弁して下さい。

 

UserControlを継承したコントロールではIMEが強制的にOFFになる。

$
0
0

皆様、ご意見ありがとうございます。

アンマネージAPI の問題に関しては、Cicero のマネージインターフェースを提供する方向で検討しております。

実装上の制約もありますので、動作変更のお約束はできません(特に選択可能にするのが難しいです)が、かなり要望が多いようなので、次期バージョンではぜひ改善を検討させていただきたいと思います。

そのためには、まず皆様の要望をただしく理解することが大事だと思いますので、お忙しいとは思いますが、もう少しお付き合い願えますでしょうか?

私としては上でも書かせていただきましたが、キチンと日本語に対応したアプリケーションであれば、変換ウィンドウは表示されるべきではないと考えています。その前提にたつと、日本語IMEは状態を見ながら変換する必要があるため、変換ウィンドウを表示せずに日本語入力を受け付けるためには、変換状態をどこかに表示する必要があり、そのためには、IMM を呼び出さざるを得ないと考えています。これが、Cicero (IMM の後継)のマネージ化での対応を重視している理由でもあります。

私が何か大事なシナリオを見落としているのだと思いますが、、IMM の呼び出しは無しでもIME がコンテナ上で有効になるだけで有益というシナリオがいまひとつイメージできていません。

そこで、こういうシナリオで必要になるという例のようなものを1つでも多くいただけると非常に助かります。

よろしくお願いいたします。

この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspxをご覧ください。

 

Viewing all 104 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>