トップ回答者
.NET Framework2.0から普通のForm表示でIMEが機能しません

質問
-
.NET Framework2.0 Beta2までは普通のForm表示でもIMEが機能していましたが、正式版になってから、普通の状態ではIMEが機能しません、TextBox等を貼り付けると機能するので完全に機能しない訳ではありません、普通のFormでIMEを機能させる方法があれば教えて下さい。
また、1.0や1.1用でコンパイルした物でも.NET Framework2.0のみのインストールでは機能しなくなってしまいます、ただし、NET Framework1.1もインストールしてあると同じプログラムでも1.0と1.1は機能し2.0では機能しません。
回答
-
> 追加すべきコーディングを教えて頂けると助かります。
単純に、ScrollableControl を継承した カスタムコントロールを 追加したプログラムは、以下のようになります。
参考にしてください。
using System;
using System.Windows.Forms;
using System.Drawing;class form : Form
{
MyCtrl myCtrl = null;
form()
{
myCtrl = new MyCtrl();
myCtrl.Dock = DockStyle.Fill;
myCtrl.KeyPress += new KeyPressEventHandler(key_press);
this.Controls.Add(myCtrl);
}
void key_press(object i_o, KeyPressEventArgs i_e)
{ string s = i_e.KeyChar.ToString(); myCtrl.SetString(s); }
static void Main()
{ Application.Run(new form()); }
}
class MyCtrl : ScrollableControl
{
string s = "";
Font f_o; SolidBrush b_o;
public MyCtrl()
{
f_o = new Font("MS Gothic", 12);
b_o = new SolidBrush(Color.Black);
}
public void SetString(string str)
{
s = str; this.Invalidate();
}
protected override void OnPaint(PaintEventArgs e)
{ e.Graphics.DrawString(s, f_o, b_o, 0, 0); }
} -
皆様
仕様変更により大変なご迷惑をお掛けして申し訳ありません。IME のサポートに関しては多様なご意見があり、今回の変更も他の要望に対応するための苦渋の決断ではあったのですが、このような事態になったという事実を真摯に受け止め、今後は仕様変更に関する早めの情報提供を徹底するよう心がけて参ります。
harasawa 様、V2.0 では、ScrollableControl に PreviewKeyDown というイベントがございます。こちらでは、TAB や矢印キーのイベントも取得できると思います。お試しください。harasawa 様の問題解決になればよいのですが、V2.0 から追加されたイベントになりますので、その辺りが心配です。
さて、今後の対応ですが、皆様いろいろなご意見をありがとうございます。非常に参考になります。
ただ、個人的には、単に On / Off の選択を可能にするだけでは不十分なのではないかと感じています。それは、On にした場合には依然変換ウィンドウが左上にでることになり、Windows フォームが、それを制御するすべを持っていないためです。もちろん、それでも構わないという場合があることはこのスレッドで十分認識いたしましたが、フレームワークを提供する側の立場としては、やはり、「変換ウィンドウが左上に出るのは構わない」という前提で仕様を決めることはいささか消極的に思えます。また、子コントロールを配置するための ContainerControl に対してコントロールを置かない場合にこそ効果のある機能を盛り込むということにも若干の抵抗があります。そこで、Windows フォームの継承関係を考慮した上で、総合的な視点から対応を検討していく必要があるように思います。
重ね重ね、仕様変更によりご迷惑をおかけし、申し訳ありませんでした。
今後ともよろしくお願いいたします。この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspx をご覧ください。
すべての返信
-
中さん 回答ありがとうございました。
普通のFormを表示した状態で文字入力は可能ですので、日本語を含む文字を入力するプログラムを開発しましたが、2.0で日本語が入力出来なくなってしまい困っています。
このソフトはインターネットhttp://www.mis.janis.or.jp/~harasawa/でも公開しています。
.Net Framework2.0は1.1も1.0も動くようになっていますので、1.1と1.0をインストールしないでテストした結果、全てのバージョンでIMEが機能しない現象が出ましたのであえて付け加えました。
どちらにしても、確実にIMEが機能した状態で立ち上げられる方法を探しています。
-
下記に簡単なプログラムを作りましたので、確認下さい。
文字入力は
KeyPress +=new KeyPressEventHandler(key_press);
で可能です。*******************************
using System;
using System.Windows.Forms;
using System.Drawing;
class form:Form
{string s=" ";
Font f_o;SolidBrush b_o;
form()
{KeyPress +=new KeyPressEventHandler(key_press);
f_o=new Font("MS Gothic",12);
b_o=new SolidBrush(Color.Black);}
void key_press(object i_o,KeyPressEventArgs i_e)
{s=i_e.KeyChar.ToString();Refresh();}
protected override void OnPaint(PaintEventArgs e)
{e.Graphics.DrawString(s,f_o,b_o,0,0);}
static void Main()
{Application.Run(new form());}}
******************************* -
ContainerControl 以下がそうなっているのに派生している話題かな?
UserControlを継承したコントロールではIMEが強制的にOFFになる
http://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=264330&SiteID=7 -
imm系のAPIは使っているのですが、やはりUserControlを継承している場合だと日本語入力ができないんです。既にご存知かもしれませんが、私はScrollableControlを継承することで回避しました。Controlを継承しても大丈夫だったと思います。
とりあえず私はそれで開発を先に進めていますので、なぜUserControlを継承すると日本語入力ができなくなるのかもう調べていませんが、何か回避する方法があるかもしれません。
でも、じゃんぬさんが紹介しているように、この件に関して数日前にこの掲示板に書き込んだのですが、未だマイクロソフトの方からもレスがつかないので、ちょっと難しいのかもしれません。
ただ、UserControlを継承したクラスで日本語入力が可能になったとしても、私は使うかどうかわかりません。今のところScrollableControlの継承で充分間に合っているからです。 -
> 追加すべきコーディングを教えて頂けると助かります。
単純に、ScrollableControl を継承した カスタムコントロールを 追加したプログラムは、以下のようになります。
参考にしてください。
using System;
using System.Windows.Forms;
using System.Drawing;class form : Form
{
MyCtrl myCtrl = null;
form()
{
myCtrl = new MyCtrl();
myCtrl.Dock = DockStyle.Fill;
myCtrl.KeyPress += new KeyPressEventHandler(key_press);
this.Controls.Add(myCtrl);
}
void key_press(object i_o, KeyPressEventArgs i_e)
{ string s = i_e.KeyChar.ToString(); myCtrl.SetString(s); }
static void Main()
{ Application.Run(new form()); }
}
class MyCtrl : ScrollableControl
{
string s = "";
Font f_o; SolidBrush b_o;
public MyCtrl()
{
f_o = new Font("MS Gothic", 12);
b_o = new SolidBrush(Color.Black);
}
public void SetString(string str)
{
s = str; this.Invalidate();
}
protected override void OnPaint(PaintEventArgs e)
{ e.Graphics.DrawString(s, f_o, b_o, 0, 0); }
} -
仕様変更されました。シナリオとして、Form やコンテナで直接キーボードのイベントを取得することよりも、無意味にIME のウィンドウが出てしまうという声に対応することを重視した結果です。ご理解ください。
trapemiya さんのご提案のように、Control から継承したコントロールを全面にドッキングして使用するのが良いでしょう。Windows フォームアプリケーションのデザインとしてもその方が自然に思います。
この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspx をご覧ください。
-
k_kazuさん 中さん trapemiyaさん じゃんぬねっとさん そしてディベロッパー製品開発統括部インターナショナルPM - MSFT さん 本当にありがとうございました。
何しろ、3年近くかけて作っているソフトですので、結構大きな構造をしていますので、どのくらいかかるか分かりませんが、今日から修正作業に取り掛かります。
脱線ですが、開発中のソフトは基幹システムが簡単に開発できる、超簡易言語ソフトです、SQL言語をベースにシステムを開発しますが、プログラムの生産性が200倍あります、本当の話ですと言っても20倍はSQLの実力で残りの10倍がこのソフトの実力です、Cで開発したものは既に会社で本稼動していますが、C#版を自前で開発中です、http://www.mis.janis.or.jp/~harasawa/でダウンロードできますのでよろしければ評価してみてください。Ver1であれば.NET Framework1.1とMSDE2000のインストールで日本語も入力できます、Ver2は当然ですが日本語は入力できません。
-
稍丼さんの方法でうまくいけます。
http://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=264330&SiteID=7その方法で私(^^;がharasawaさんのコードを修正するとこんな感じになります。
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using System.Runtime.InteropServices;
namespace test2005
{
public partial class testIme : Form
{
[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);
string s = " ";
Font f_o; SolidBrush b_o;
public testIme()
{
InitializeComponent();
KeyPress +=new KeyPressEventHandler(key_press);
f_o=new Font("MS Gothic",12);
b_o=new SolidBrush(Color.Black);
}
void key_press(object i_o, KeyPressEventArgs i_e)
{
s = i_e.KeyChar.ToString(); Refresh();
}
protected override void OnPaint(PaintEventArgs e)
{
e.Graphics.DrawString(s, f_o, b_o, 0, 0);
}
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
//#define WM_IME_SETCONTEXT 0x0281
case 0x0281:
bool rc = ImmAssociateContextEx(
this.Handle,
new IntPtr(0), // 無視されます。
ImmAssociateContextExFlags.IACE_DEFAULT);
if (rc)
{
DefWndProc(ref m);
}
else
{
base.WndProc(ref m);
}
break;
default:
base.WndProc(ref m);
break;
}
}
}
}
-
trapemiya さん ありがとうございました。
動作確認で若干手直しで動きました、せっかく作っていただきましたが、開発中のソフト、Microsoftさんには悪いですが、将来はlinuxでも対応予定ですので、組み込みは躊躇しています。
今まで簡単に出来たことがこんなにも難しい話となってしましました、回答していただいた人には感謝していますが、何処かがおかしいと感じています、IMEは英語圏では無い問題ですので、このようになっているのでしょう。
今までは出来たいたので、そんなに難しい事ではないと思います、弱い人間のニーズを握り潰さないで、IMEを有効のままで起動出来る事を簡単なコーディングを付加する方向で良いので仕様として追加してほしいと感じています。
-
ScrollableControl を
UserControl のクライアント領域に広げるとすると...で考えてみると。public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
}
}
partial class UserControl1
{
/// <summary>
/// 必要なデザイナ変数です。
/// </summary>
private System.ComponentModel.IContainer components = null;
/// <summary>
/// 使用中のリソースをすべてクリーンアップします。
/// </summary>
/// <param name="disposing">マネージ リソースが破棄される場合 true、破棄されない場合は false です。</param>
protected override void Dispose(bool disposing)
{
if (disposing && (components != null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#region コンポーネント デザイナで生成されたコード
/// <summary>
/// デザイナ サポートに必要なメソッドです。このメソッドの内容を
/// コード エディタで変更しないでください。
/// </summary>
private void InitializeComponent()
{
this.canvas1 = new System.Windows.Forms.ScrollableControl();
this.SuspendLayout();
//
// canvas1
//
this.canvas1.Dock = System.Windows.Forms.DockStyle.Fill;
this.canvas1.Location = new System.Drawing.Point(0, 0);
this.canvas1.Name = "canvas1";
this.canvas1.Size = new System.Drawing.Size(150, 150);
this.canvas1.TabIndex = 0;
//
// UserControl1
//
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 12F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.Controls.Add(this.canvas1);
this.Name = "UserControl1";
this.ResumeLayout(false);
}
#endregion
private System.Windows.Forms.ScrollableControl canvas1;
}
となりますよね。
で,こっからが面倒かもしれませんね...
ScrollableControl も継承したものに置き換えるのかなぁ。 -
稍丼 さん プログラム例ありがとうございました。
現時点では内容を完全に理解できていませんので、少し時間をかけて、どのようにすべきか考えて見ます、どうも、私のように単純になることが良いと考えている人間には、進むに連れて複雑になって行く話はついて行けません、私としては単純にFORM画面上でIMEが動けばそれで良いと考えているのですが、この考えはおかしなことなのでしょうか、IMEが有効であれは入力中の日本語がどこに表示されようと一行にかまわなく、日本語やTab、矢印キーを含めて全ての文字が常にプログラムに受け取れればよいのです、このような単純な機能を簡単に実現したいとの考え方は、どこかが間違っているのでしょうか。
-
私の作っているソフトは基本設計から既に15年かかっています、また、C#でも既に3年をかけています、つまり、このソフトは私の人生の集大成のようなソフトで、そこへの思いは非常にい大きな物があります、そのソフトが.NET Framworkでは受け入れがたい特殊なソフトであると判断されれば、この、3年間は無かったものとして.NET Frameworkからはいさぎよく身を引く覚悟をしております、解決する方法はただひとつ、.NET Framework開発者が私の主張が正しいと判断し、.NET Framworkで私のソフトをBeta2まで出来たように簡単に実現可能にしていただいた時だけです、私のソフトが何処に問題があって、なぜ簡単に動かす事を認めてくれないのか、その点を是非ご指摘をお願いします。
この問題を、今の.NET Framwork2.0で何とかクリアーしてとしても、次のバージョンでどう逆立ちしても動かなくなる可能性は否定できません、このソフトはこれでおしまいでは無いので、こうなると、更に無駄な時間の浪費となってしまいますので、その点をご理解下さい。
私のお願いは難しい話ではなく、件名のように普通のForm表示でBeta2まで出来ていたように、単にIMEが機能できる仕様を付加していただければ良いだけの話です。
-
アンマネジドAPIを使いたくない場合で,
単純に,確定文字 を取得するだけでいいのならば,
例えば,
ScrollableControl を継承して,
MyCanvas というクラスを作成して,
WinProcをオーバーライドして,
・WM_CHAR
のというメッセージ捕らえて,Unicode文字を取得します。元のコードを生かす感じにすると...
public class MyCanvas : ScrollableControl
{
string s = String.Empty;
Font f_o;
SolidBrush b_o;
public MyCanvas()
{
f_o = new Font("MS Gothic", 12);
b_o = new SolidBrush(Color.Black);
}
public void AddString(string str)
{
s += str;
this.Invalidate();
}
public void ClearString()
{
s = String.Empty;
}
protected override void OnPaint(PaintEventArgs e)
{
e.Graphics.DrawString(s, f_o, b_o, 0, 0);
}
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
// WM_CHAR
case 0x0102:
this.AddString(System.Convert.ToChar(m.WParam.ToInt32()).ToString());
base.WndProc(ref m);
break;
default:
base.WndProc(ref m);
break;
}
}
}のようになります。
で,ちょっと前のコードで,
UserControl のクライアント領域に,
ScrollableControl をいっぱいに広げるコードの
ScrollableControl のところを MyCanvas に換えると...public partial class UserControl1 : UserControl
{
public UserControl1()
{
InitializeComponent();
}
}
partial class UserControl1
{
/// <summary>
/// 必要なデザイナ変数です。
/// </summary>
private System.ComponentModel.IContainer components = null;
/// <summary>
/// 使用中のリソースをすべてクリーンアップします。
/// </summary>
/// <param name="disposing">マネージ リソースが破棄される場合 true、破棄されない場合は false です。</param>
protected override void Dispose(bool disposing)
{
if (disposing && (components != null))
{
components.Dispose();
}
base.Dispose(disposing);
}
#region コンポーネント デザイナで生成されたコード
/// <summary>
/// デザイナ サポートに必要なメソッドです。このメソッドの内容を
/// コード エディタで変更しないでください。
/// </summary>
private void InitializeComponent()
{
this.canvas1 = new MyCanvas();
this.SuspendLayout();
//
// canvas1
//
this.canvas1.Dock = System.Windows.Forms.DockStyle.Fill;
this.canvas1.Location = new System.Drawing.Point(0, 0);
this.canvas1.Name = "canvas1";
this.canvas1.Size = new System.Drawing.Size(150, 150);
this.canvas1.TabIndex = 0;
//
// UserControl1
//
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 12F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.Controls.Add(this.canvas1);
this.Name = "UserControl1";
this.ResumeLayout(false);
}
#endregion
private MyCanvas canvas1;
}になります。
UserControl のクライアント領域に,文字が描画されると思います。
(注: IME が ON の時もOFF の時も同様にWM_CHARで処理しています。) -
harasawa は書きました: 動作確認で若干手直しで動きました、せっかく作っていただきましたが、開発中のソフト、Microsoftさんには悪いですが、将来はlinuxでも対応予定ですので、組み込みは躊躇しています。
IME 周りまで含めた WinForms の完全な再現性が Linux で実現されることを期待して,ということですか?
個人的にはそういう可能性はかなり難しい・時間がかかる話だと思いますが,その「将来」がいつ頃になるか情報ソースを何かお持ちですか?もしそんな日が当面来ないようであれば P/Invoke コードを拒否する理由としてはちょっと弱いような気がします.(別の理由を否定するわけではありません)
「弱い人間のニーズを握り潰さない」からこその P/Invoke という見方もあるかもしれません.WinForms は (パフォーマンス等の理由で) Win32 の影響を大きく受けすぎているので,移植性を考えるなら本来 WinForms 依存部分はコードを分離しておくべきところだと思います.
ここが問題となること自体が何処かがおかしいと感じます. -
稍丼 さん お手数をおかけしてすみません。
内容が理解できないですが、とりあえず、書いていただいた内容で、私の作っているプログラムにコーディングをしてみました、少し前にも書きましたがScrollableControlの継承でIMEが有効のままとなりましたが、Tabキー、4個の矢印キーが受け取れませんでした、今回の例そのままでは、更にファンクションキーも受け取れない模様ですが、WndProcでは全てを受け取っているので、手を加えれば技術的には可能と判断します、ただし、私のソフトを完全にするには大幅な手直しが必要のようです、その前に、今回のコーディングの意味を完全に理解してからと考えています、個人的には単純が一番と考えていますので、すでにかなりのストレスを感じています、開発中のソフトC#で既に3年掛けていますので、じっくり時間をかけて、自分の心のゆとりが戻ってきてから、再開したいと考えています。
一番望む事はやはり.Net Framwork2.0のBeta2までのように簡単(単純)に実現できるようになる事です。
-
NyaRuRu さん 原沢です
現在開発中のソフトはIME関連コーディングは一切書かれていません、したがって、何一つ拒否するものはありません、今を拒否しているのではなく、Beta2までと同じ状態も可能にして頂きたいだけです。
linuxでの.NET Framework互換ツールのMono Project
http://www.mono-project.com/Main_Page
で開発中のツールはWindowsOS環境でも動くものを作っています、現MONO-1.1.13.4では、幸か不幸かFormでIMEは機能します、つまり、日本語に関しては.Net Framwork2.0 Beta2までの動きとまったく同じ動きをします(多分互換レベルが.NET Framework1.0か1.1を想定しているからだと思います)、なお、linux上での日本語の動きについては、現在開発中のソフトはlinuxを想定してません、次のバージョンで対応予定ですので、動作実験はしてありません(.NET Framwork完全互換と言っても、OSの基本機能は尊重する、たとえば、Windowsはドライブ名があるがLinixは全て/から始まるので、現ソフトがそのままでは当然linux上では動きません)、Windowsと同じ動きをするとすれば多分linuxでも問題ないとは思っていますが、Form完全互換は1.1ではなく1.2との事ですので1.2が出てから開始しようと考えています。
将来.NET Framework2.0完全互換になると、この問題が引っかかるようになりますので、今が正念場と認識しています。
-
TAB, ENTER, ESCAPE, Left Arrow, Right Arrow, Up Arrow, Down Arrow や F1~F12等は,ProcessDialogKeys をオーバーライドします。
public class MyCanvas : ScrollableControl
{
string s = String.Empty;
Font f_o;
SolidBrush b_o;
public MyCanvas()
{
f_o = new Font("MS Gothic", 12);
b_o = new SolidBrush(Color.Black);
}
public void AddString(string str)
{
s += str;
this.Invalidate();
}
public void ClearString()
{
s = String.Empty;
}
public void ProcessSpecialKey(Keys keyData)
{
// ここでは,確認のため文字で出力。
// 本当は,場合分けして,処理です。
this.AddString(keyData.ToString());
}
protected override void OnPaint(PaintEventArgs e)
{
e.Graphics.DrawString(s, f_o, b_o, 0, 0);
}
protected override bool ProcessDialogKey(Keys keyData)
{
switch (keyData)
{
case Keys.Up:
case Keys.Down:
case Keys.Right:
case Keys.Left:
case Keys.Tab:
case Keys.Return:
case Keys.Escape:
case Keys.F1:
case Keys.F2:
case Keys.F3:
case Keys.F4:
case Keys.F5:
case Keys.F6:
case Keys.F7:
case Keys.F8:
case Keys.F9:
case Keys.F10:
case Keys.F11:
case Keys.F12:
this.ProcessSpecialKey(keyData);
return true;
default:
return base.ProcessDialogKey(keyData);
}
}
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
// WM_CHAR
case 0x0102:
this.AddString(System.Convert.ToChar(m.WParam.ToInt32()).ToString());
base.WndProc(ref m);
break;
default:
base.WndProc(ref m);
break;
}
}
}となります。
-
-
ディベロッパー製品開発統括部インターナショナルPM - MSFT さん 原沢です
今回変更された理由をhttp://forums.microsoft.com/msdn-ja/ShowPost.aspx?PostID=264330&SiteID=7に書かれていることも含めて、更に、皆様の意見も含めて、再度詳細に検討してみました、私の頭は単純なことしか理解できない、単純な構造ですので、やはり、結論は単純になってしまいますが、論理のすり替えではなく、あくまでも自分が理解できるまで、単純にしただけですので、すり替えがあると判断された場合は、ご指摘下さい。
「Form上ではショートカットを利用する場合、IMEが問題を起こすので、Form上ではIMEを禁止した」
この文章は皆様には先入観や思い込みがあり、もっともと思われる人と、おかしいと思う人もいると考えます、そこで、先入観も思い込みも無い別の事例に置き換えて見ます、Formを道路、ショートカットを氷、IMEを革靴と見立てました
「道路上では氷が張っている場合、革靴で歩くと滑ってけがをする問題を起こすので、道路上では革靴で歩く事を禁止した」
(氷の上を革靴のような下が平らな靴で歩いた事が無い人に説明すれば、足が滑ってしまって、ほぼ100%転んで非常に危険な状態になります、くれぐれも御注意下さい)
(論理のすり変えは無いと判断しますが、あるとする方は反論をお願いします)
このような法律を作ろうとしたら、あなたは賛成ですか、反対ですか、私は反対です。
純粋に何も知らないとして、再度考えてみてください、Formではキーボードの情報は何の制約も無く常に受け取れます、日本語も何の問題も無く受け取れる事が、正常な考え方と思います、ただし、当然ですが、シュートカット(すみませんがシュートカットがどのような状況で問題なのかは理解できていません)のような問題も発生しますので、それに対処する必要はあります、だからと言って、本来の形を崩す事は避けるべき事と考えます、これが、基本ソフトを提供する側が一番注意しなければならない点です。
-
とりあえずどうしてもこの(あなたにとっての)障害を回避したいというのであれば、インシデント発行を行いましょう。
Microsoftの方のコメントにも必ずついているように、このようなコミュニティの場での発言は一個人の見解の超えるものは提供されません。
#次期バージョンで検討しますも同じくとは思いませんが。(^^
http://support.microsoft.com/select/?target=assistance
解決になるかどうかはわかりませんが・・・
-
中さん 原沢です
ご忠告ありがとうございました、実を言いますと、過去に置いて、別の問題で依頼しましたが、電話で回答してくれた日本の技術者は、私の言っていることは最もで、問題と思いますとの回答をいただきましたが、それでも最終的には、米国本社側の技術者が問題なしとの事で、解決してはもらえませんでした、この時は非常にショックを受けました、それでも何とか解決しました。
ツール開発は人間がしている以上は、開発者の基本的な考え方が大きく左右します、技術者の基本的な考え方を今回の例を上げて述べていますので、ご理解下さい、今回の問題は、皆様の御協力により、解決方法を伝授いただきました、ただし、完成はしていません、なぜならば、今回の事件のショックが前回よりも大きすぎて、再開する気力が今は全く無いからです、.NET FramworkとC#の将来を更に良き方向にして頂きたい意味をこめて、私のような被害者を1人でも出さない事を願って書いていますので、その点誤解の無いようお願いします。
ただ、2度あることは3度あると言いますので、C#(.NET Framework)の理想と、私の描いている理想に既に大きな開きが有るのではないかと感じています。
-
harasawa は書きました: ツール開発は人間がしている以上は、開発者の基本的な考え方が大きく左右します、技術者の基本的な考え方を今回の例を上げて述べていますので、ご理解下さい、今回の問題は、皆様の御協力により、解決方法を伝授いただきました、ただし、完成はしていません、なぜならば、今回の事件のショックが前回よりも大きすぎて、再開する気力が今は全く無いからです、.NET FramworkとC#の将来を更に良き方向にして頂きたい意味をこめて、私のような被害者を1人でも出さない事を願って書いていますので、その点誤解の無いようお願いします。
harasawaさんは,以前感じられた「.NET Framework を使えば IME について何も知らなくても日本語入力が可能」ということが今回裏切られるような形になったためご立腹なのだと推察いたしましたが,私は IME について違う印象を持っています.
私の場合はゲーム開発などで IME について苦労した経験があるのですが,その経験では IME は「詳細を知らなくても簡単に使える」という印象は受けませんでした.
IME に求められる機能の複雑さに由来する本質的な難しさというのは .NET Framework の時代でも常に WinForms の背後に存在して,以前 hirasawa さんが感じておられた「簡単」「シンプル」は実はかなり危ういバランスの上に実現されていたものだと思います.
今現在 IME について私は .NET Framework に理想を期待はしていません.
シンプルにすべきという主張はもっともだと思いますが,IME については「そもそもこれはシンプルにはならない」というのが私の経験上の印象です.確かに,WinForms の動作を以前のように戻すだけであれば簡単かと思います.
しかし,その以前の状態も私にはまだまだ不十分に見えます.
例えば変換候補ウィンドウが表示される位置の制御はできましたか?多くの Windows ユーザは,カーソル (キャレット) の位置に変換ウィンドウが表示されることに慣れています.
以前の WinForms の動作では,変換ウィンドウが表示されていたのは常にウィンドウの端ではありませんでしたか?
MS-DOS 時代はよく目にしましたが,Windows アプリケーションとしてその位置は不自然なので,それを何とかしたいという要望は少なくとも私ならまっさきに挙げると思います.
しかし,今の WinForms は Win32 レベルでのキャレットの概念を消化し切れていないので,この点からも Win32 API 抜きで IME とうまく協調するのは困難が予想されます.harasawaさんの言われる「以前の動作モードも選択できるようにするだけ」が (harasawa さんにとっては) 簡単な解決法ということには同意しますが,その古いモードが理想的だと主張されるのは個人的には同意できません.
確かに簡単に以前の動作に戻す選択肢があっても悪くないとは思いますが,「以前のモードがどう素晴らしかったか」に説明を割かれる必要はあまりないと思います.
harasawaさんの求める使い方と WinForms の以前の状態がたまたまマッチしていたということを何度も説明されているように見えます.そのあたりの理想論を抜きで,単に「互換モードがあれば旧バージョンのコードの移植が楽だから用意して欲しい」というシンプルな理由であれば,私も応援はできると思います.
-
NyaRuRu さん 原沢です
ご意見ありがとうございます、私の主張するところと、少しだけ違っているので、反論するつもりはありませんが、説明します、デスクトップ上でIMEは無効になりますか、マイコンピュータ上ではIMEは無効になりますか、どちらもなりません、多分MIcrosoftの論理で行けば、将来は無効になるのでしょう、ただし、今は無効になりません、これは別として、私の言っていることはIMEが問題を起こすことは、当然対応しなければなりませんが、それ以前に、Formが英語を何の制約も無く受け入れるのであれば、当然日本語も受け入れる事は当たり前と言っています、IMEが問題を起こす場合には、IMEを無効にするように出来る事も何も否定はしません(早い話が無効にする事と、有効にする事の両方が出来ればそれが全てです)、私にとっては例外と見ている無効を重視し、私に取っては本来の姿の、有効は自分で対応しろと言うのは、いささか不合理な話です、また、個人攻撃になるので、あまり言いたくは無いですが、ツール提供者の責任において、何の問題なく動いていたソフトを、明確な理由も無く動かなくしてしまう事は絶対にやってはならない事と考えます。
三年かかって作ったソフトが1夜にして動かなった経験がありますか、その時の、落胆がどれほど大きなものか分かりますか、しかも、原因が自分の納得できる内容でなかった時に、更にその落胆は計り知れないほど大きな物になります。
-
>Formを道路、ショートカットを氷、IMEを革靴と見立てました
MSFTさんはFormを道路と考えていなかったんだと思います。Formを道路として使っている人が多かったようなので、その対応に苦慮されているのだと思います。
Formは単なる土地で、その上にPanelなどを配置して、それを道路として使うことを想定されていたのだと思います。
結局、ここのずれをどうするのかということなんですね・・・Formで強制的にIMEのオンオフを切り替えることが難しい以上、IMEをオフ固定にするのは理解できます。なぜならそのようにしても、Panelを貼るなどしてIMEをオンで使う逃げ道が残されるからです。現状の仕様としては私もこれに賛成です。
しかし、以前のFormを道路として使っていたコードとの互換性はなくなります。ここをどうするかだと思います。
以上のことは文面からもharasawaさんは理解されているだろうと想像できます。これを踏まえた上で現実的に先へ進む提案ですが、Formを継承しているのをやめて、Panelを継承するようにしてみたらいかがでしょうか?
harasawaさんがどのようなコードを書かれているのかわからないのですが、Formの継承からPanelの継承へ変更する作業は、文字列置換が主であり、そんなに大変なことではないような気がします。一度チャレンジしてみられたらいかがでしょうか? 感覚で言っていますので、ひょっとすると大変な作業量かもしれませんし、簡単にはいかないかもしれません。もし、そうであればごめんなさい。 -
harasawa は書きました: 前にも書きましたがNET Framework2.0のみがインストールされた状態では1.0で作ったプログラムも1.1で作ったプログラムも動くのに、IMEが有効になりません、踏んだり蹴ったりです、1.1で作ったソフトもさかのぼって対応しなければ完璧になりません、相当につらい物があります、また、このソフトは、基本ソフトですので、当然2.0にも対応したいし、更に次のバージョンにも対応したいと考えています。
.NET Framework 2.0 のみがインストールされた状態で .NET Framework 1.1 用に作ったプログラムが完璧に動くことを期待するかどうかの違いでしょうかね.私は期待しませんけど.
.NET Framework 1.1がインストールされていれば .NET Framework 1.1 用のアプリケーションは .NET Framework 1.1 を使用してそのまま動きます.
そうやって互換性を崩さずにフレームワークのバージョンを上げていくよ,というメッセージを Microsoft は何年も前から発信し続けています.もし私が .NET 1.1 で作ったソフトも遡って対応するとしたら,むしろ .NET 2.0 で動こうとしたら警告するように修正するかと思います.
-
trapemiya さん harasawaです
本当に貴重なご意見ありがとうございます、せっかくformは道路でなく、土地だからIMEを無効にするのはやむをえない、との、ご意見を頂きましたので、その意見をもとに、私の言いたい事を、説明させていただきます。多分、土地のほうが道路より広いので、やむなしとの、意見と考えます、それでは土地より広い所は当然IMEは無効になる必要があります、form(土地)より広いデスクトップ(村としましょう)はあなたの主張では当然無効になるべきです、私のパソコンのデスクトップはIMEは無効になりません、私のパソコンは多分壊れているんのでしょう。
-
NyaRuRu さん harasawaです
斬新なご意見ありがとうございます、この件に関してはあなたへの意見と言うより、Microsoftへの思いがありますので、披露させていただきます。
当然ですが.NET Framwoek1.1しかない時に作っているプログラムは2.0でどう動くかは誰にも分かりません、その時に、まだ出てもいないソフトで問題なく動く対策をしておく必要があるなどと言う言い分は、どう考えても私には理解できません、人間は必ず間違いを起こします、その人間に注意しろ、注意をしなかったのはお前の責任だと言う発想は、私にはまったく理解不能です、1.1で作ったソフトが、別仕様で動いても良いと言うコーディングを陽に指定しない限り1.1が2.0で何の警告も無く2.0の仕様で動く事はナンセンスです。
(NyaRuRu さんが説明された事を前提として意見を述べていますので、前提が間違っている場合は、ごめんなさい)
-
harasawa は書きました: 仰ることはもっともだと思いますが,「未知のバージョンで動く対策をしておく必要がある」と言った憶えはありません.そう取られても仕方ない文章であったのならばお詫びします.
もし完全な互換性を求めるなら,大事なのは「問題なく動く対策をしておく」のではなく,「未知のバージョンでは動かないようにしておく」ということかと思います.その設定についても以前から公開されています.このあたりの記事を読まれたことはありませんか?
.NET Framework の side-by-side 実行
デフォルトで警告無しに動くという仕様が問題となる場面は確かに何度か見たことがありますね.
(追記)
当初 harasawa さんは「.Net Framework2.0は1.1も1.0も動くようになっていますので」と書かれていましたが,このあたりからどうも違和感があります.
Microsoft が .NET 1.0/1.1 のアプリケーションが .NET 2.0 のみの環境で旧バージョンと全く同じ動作をすると主張した文章を私は見たことがないのですが,動作させてみると警告無しに動いたので当然 100% の互換性があるんだ (あるべきだ) と思われたということでしょうか?100% 完全に動作しないかもしれないという警告がデフォルトで表示されるべきだというのであれば,私も特に反論は無いです.
-
>多分、土地のほうが道路より広いので、やむなしとの、意見と考えます
>・・・(途中略)・・・
>それでは土地より広い所は当然IMEは無効になる必要があります私の言い方が悪かったかもしれません。広い方がIMEが無効になるという意味で土地という比喩を出してきたわけではありません。
私は、Formでは本質的にIMEがオンになるべきではないとは言っていません。以下の理由により、現状ではIMEがオンになるべきではないと私は思っています。.NET Framework 2.0はパッケージソフトです。誰に対しても共通仕様であり、個人ごとにカスタマイズ可能なものではありません。パッケージソフトである以上、仕様を1種類に決めなければなりません。仕様としてはまず、そもそもFormでIMEがオンになれる必要があるのか?、それとも無いのか?ということになると思います。これについての議論はいろいろとあると思いますし、今回の件とは直接的な関係はありませんので、あやふやなままにしておきます。
では、仕様決定に入ります。次の3つからの選択になるでしょう。1. FormでユーザーがIMEをオンにできるようにする。
2. FormでユーザーがIMEをオンにできないようにする。
3. FormでユーザーがIMEをオンにできるようにするかどうかは、開発者が設定できる。1.はFormをキャンバス代わりに使っている方には必要なことです。2.はFormでショートカットキーを定義している人に必要なことです。3.は残念ながら実現できませんので、1.か2.ということになります。
1.は他の方法で逃げることができます。しかし、2.は逃げることはできません。また、2.で困っている人の割合が多いでしょう(と思います)。
結果として、パッケージの仕様としては2.を選択するのがベストだと考えます。
ここで誤解してほしくないのは、本質的に、FormでIMEをオンにできないようにするべきだと言っているわけではありません(あやふやにすると前述しました)。
FormでIMEをオンにできないようにするべきかどうかは私にもわかりません。わからない以上、3.を選択するのがベストなのですが、残念ながらできません。なので、現状を総合的に考慮すると、消去法的に2.がベストな選択であると言っているまでです。
ただ、今回の仕様変更の選択は正しいと言っても、その手続き、過程には問題があったと思います。そうは言っても、harasawaさんが怒る気持ちはわかります。怒って当然だとも思いますし、言うべきことは言うべきだと思います。ただ、今回のFormに関する仕様変更を喜んで迎えている人も多いと思います。
人はそれぞれ意見があります。異なっているのも当然です。でも、もし、harasawaさんが前に進むことができたら、皆が幸せになれるなぁと思います。
とりあえず自分のできることを試してみませんか?そういう意味でPanelを継承してみたらいかがでしょう?と提案しました。
その結果、とても無理だ。3年もかけたのにもうダメだと、おっしゃられるのなら、元の仕様に戻せというのは、決して間違った主張ではないと私は思います。harasawaさんは今までそのやり方でやってきたのですから、harasawaさんがババを引くのは納得できない思いもあります。生意気なことを言ってお気を悪くされたかもしれませんが、決して悪気はこれっぽっちもありません。うまく表現できない部分も多々あります。正直、マイクロソフトさん、harasawaさん、双方とも正しいと思います。だからこそ難しい問題ですし、少しでも歩み寄ってみなさんが幸せになれたらなぁと思うしだいです。
また、生意気なことを言いましたね。 これだけの文章ですが、1時間半もかけて推敲しながら書いた努力に免じて許してください。(^^;
-
harasawa は書きました: NyaRuRu さん 原沢です
デスクトップ上でIMEは無効になりますか、マイコンピュータ上ではIMEは無効になりますか、どちらもなりません、多分MIcrosoftの論理で行けば、将来は無効になるのでしょう、ただし、今は無効になりません、
確かに無効になりませんね.
しかし,私は常に無効になるべきだと主張しているのではありまあせん.前にも書きましたが,IME を有効に出来るかどうかを選択可能にして欲しいという要望を Microsoft に出すのであれば,私もむしろ同調するとも書いたはずです.私が問題にしているのは,例えばデスクトップやマイコンピュータで IME 入力するときの変換候補ウィンドウの位置です.harasawa さんはあの位置で満足なのですか? 私は大いに不満なのですが.
harasawa さんにとっては問題は単に IME を有効に出来れば解決するのかもしれませんが,私の問題は解決しません.
何故なら Win32 API の頃は変換ウィンドウの位置なども自由に変更できたからです.
単に日本語が受け入れられるというだけの機能を「本来の姿」と言われても,私が困ります.
「IMEが有効であれは入力中の日本語がどこに表示されようと一行にかまわなく」では困る人が居ることも忘れないでください.harasawa さんが言われる「本来の姿」は .NET 1.0/1.1 で実現されていたのかもしれませんが,それは私にとっての「本来の姿」ではありません.
従って,「前の姿に戻す設定を加えるべきだ」という主張には同意できても,「本来の姿に戻せる設定を加えるべきだ」という主張に対しては違う見方になってしまうということです.
私の望む「本来の姿」は harasawa さんの望むものよりも複雑で使いにくいものかもしれませんけど. -
色々の意見を頂きありがとう御座います。
惜しむらくは、私の意見に賛成の方は何方もいないと言う事です、なぜかと自問自答していますが、根本的に何かが違うのではないかとの事で、もう一度色々考えて見ましたが、やはり結論は2.0 Beta2までが正しいと言うものでした、また反論を頂く事を覚悟ですが、書きます。
通常のプログラムはFormを継承した状態から始めます、つまり、これが最初の状態です、この状態からどのようなプログラムでも作れる事が一番大事です、どのようなプログラムでも作れるためには、この状態で、どのような操作も制限無く受け入れられなければできません、当然その中にはIMEが有効である事も含まれます、このように、初期状態で全ての操作を受け入れられる基本機能はプラットフォームとしては絶対条件であると言う事です。今回問題にされている、IMEが有効では困ると言う人のためには、この基本をベースに陽にIMEを無効にするコーディングが付加されるべきものであると考えます。
少し気になっていますが、表示回数が1500回を超えています、これは、私と同じ問題をかかえている人が居るという事でしょうか、居るようでしたら、是非、賛成の意見を下さい。
-
>----------------------------------------------------
今回問題にされている、IMEが有効では困ると言う人のためには、この基本をベースに陽にIMEを無効にするコーディングが付加されるべきものであると考えます。
>----------------------------------------------------私もそう思います。それが一番の解決方法だと思います。ここまではharasawaさんの意見に賛成です。しかし、その解決方法はかなり難しいというMSFTさんの書き込みがありました。それを踏まえた上で、元の仕様に戻すのか戻さないのか?の選択です。私も悩むところですが、何とか既存のプログラムを改造することによって乗り切れるのであれば、それが一番だと思います。元に戻せ派も、戻すな派も幸せになれるからです。(元に戻せ派の方にとっては全く余計な工数ですが・・・)
しかし、その改造が大変なのであれば、私はとりあえず元に戻せ派になると思います。結局、私の意見は、今回の仕様変更で苦しんでいる方の苦しみ程度で変わってきます。高飛車な言い方かもしれませんが、本心です。苦しんでいる方にこういう言い方しかできなくて、ごめんなさい。
-
おがわみつぎです。
はじめまして、原沢さん。
また、MVP 各位、毎度!提案をするために出てきました。
#私は門外漢なんでね。(^-^;)さて、議論として、「Form でユーザーがIMEをオンにできるようにしてほしい」ということですが、trapemiya さんの提案にあるように、「FormでユーザーがIMEをオンにできるようにするかどうかは、開発者が設定できる」ように、皆さんでリクエストをあげませんか?
ただ、これには問題があって、われわれ MVP が声を上げたとしても、保証されるわけではないですし、ほとんどの場合が次期バージョン以降でという話になります。
MVP Wish を使っても、要望が通りそうにないということなら、ちょっと極悪な方法として、ビル・ゲイツ氏、スティーブ・バルマー氏に直接メール(当然英文)をする方法もありますが。急いで対応してほしいという話であれば、自分のコードの改修をして、当座しのいでください。急ぎで製品のデザインを変更する(DCR)ことは、実質不可能なので、気長に待ってもらうしかありません。
近いうち( 4 月下旬)に Japan MVP Summit が行われますので、日本の MVP にある程度話をすることは可能で、賛同が得られれば行動を起こしたいと思いますが、いかがでしょう?
-
おがわさん、ありがとうございます。おがわさんが相手だと、緊張します。。。(^^;
>trapemiya さんの提案にあるように、「FormでユーザーがIMEをオンにできるように
>するかどうかは、開発者が設定できる」ように、皆さんでリクエストをあげませんか?とりあえず既存のコードを救うためには、そのようにすることが一番だと思いますが、はたして新規で開発を始める場合には、直接Formで日本語を受け取るようなプログラムを作るだろうか?と思います。通常、日本語を受け取るようにするためには、imm系のAPIをいじくることになり、変換ウインドウが頻繁に更新リージョンを作成するために発生するWM_PAINTの処理をしなければならないなど、思った以上に面倒なことになります。
であれば、コードの再利用性を考えてせめてPanelクラスに実装したり、コンポーネント化するのが普通だと思うのです。Formに書いてしまうと、後で再利用しにくくなってしまいます。Formが最後の器であるからです。ですので、FormにIMEのオンオフを固定するプロパティを追加したとしても、はたしてどれほどの需要があるのかわかりません。ひょっとすると、ほとんどの場合オフで使うようになるかもしれないと思ったりします。この辺りは、私もみなさんの意見を聞きたいところです。
さて、今回、UserControlも同様に強制的にIMEがオフになるように仕様変更されました。確かにUserControlはコンテナ色が強いのですが、コンポーネントであり、直接日本語を受けてキャンバスのように文字を描きたいという要求があるような気がします。私は、UserCotrolには、IMEのオンオフを固定するプロパティがあっても良い気がします。ただ、ControlやScrollableControlを継承すれば済む話だと言われれば、それまでなんですけどね。(^^; この辺りも、みなさんどう思われているのでしょうか?
-
おがわみつぎ は書きました: さて、議論として、「Form でユーザーがIMEをオンにできるようにしてほしい」ということですが、trapemiya さんの提案にあるように、「FormでユーザーがIMEをオンにできるようにするかどうかは、開発者が設定できる」ように、皆さんでリクエストをあげませんか?
私もそのリクエストには賛成で,そう書いたつもりだったのですが,それでも harasawa さんは「賛成の方は何方もいない」と言われていて,何が落としどころなのかよく分からない状態です.
何を書いても反論と思われているならこれ以上書くことは無いですけど.いずれにせよ今月末から2ヶ月ほど海外出張に行かなくてはいけなくて,余り時間の余裕もないので,私はこの件からは身を引きたいと思います.
Wish に加われなくて残念ですが,どちらかというと WinFX の Cicero の方に興味がありますし,私はそちらのレビューに移る予定です.ではでは.
-
おがわみつぎ さん そして返信頂いた皆さん harasawaです
おがわみつぎさんへ
はじめまして。
提案いただいてありがとうございます、私も賛同します、行動を起こしていただければ幸いです、よろしくお願いします。
返信頂いた皆さんへ
50件近い返信となってきました、また、提案を頂いた事でも有り、この辺でまとめとしたいと思いいます、当初はこれほどの長丁場になるとは正直思いませんでしたし、皆さんの真剣なメッセージがこれほどいただけるとは思いませんでした、本当にありがとうございました。
現時点ではコーディング例を頂きましたので2.0でも今までと同じ状態には出来るところまでは来ていると思います、ただ、相当手直しが必要のようですので、完成時期は不明です。
IMEを無効にすべきの意見の中で、Formで日本語を入れるプログラムは無いとの趣旨の発言を頂きましたが、これが一番きつい意見でした、なぜならば、それを必要としている所に問題の本質があったからです、私のプログラムがどのような物か確認する事は可能です、私のURL http://www.mis.janis.or.jp/~harasawa/からダウンロードできます、圧縮状態ですが426KBしかありませんのでCドライブにダウンロードしマイコンピューター上で実行しc:\setupI2wフォルダー内のSETUP_JA.BATを起動してみてください、この画面はインストール画面ですが、今回困っているプログラムその物です、画面は飾り気のまったく無いものですが、簡易プログラムで動いております、この簡易プログラムは基幹システムを開発、運用するのに十分な機能を持っています。
最後に、すみませんが、私の主張をさせて頂きます。
.NET Framworkのような基本となるプログラムは、全ての操作を制限する事無く受け入れるべきと主張します、当然、IMEに関してもディスクトップがそうであるように、制限されるべきでは無いと主張します、したがって、.NET Framwoek2.0から普通のFormでIMEが機能しない、仕様変更は間違いであると主張します。
-
ちょっとお願いです。
主義主張をされるのはかまいませんが、もっと建設的な発言でお願いします。
何でも制限されないという話だと、セキュリティの話ではどうなるんでしょう?
「セキュリティ上の脆弱性があるためにできなくなりました。」という話だとしたら、どうでしょう?
この場合は、どうすることもできないと思います。
この手の話は、Windows XP Service Pack 2 の時に大いに話題になりました。
それでも主張できますか?
時と場合によっては、互換性を犠牲にしなければならないときがあります。
今回は IME に問題があるので、犠牲にしなければならないと MS が判断したということになります。
IME については、次期バージョン( Windows Vista )で、実装を変えるという話もあります。
そのあたりを考えての判断かもしれません。
ですので、開発者でしたら、互換性を犠牲にしなければいけない局面があるということを、ご理解いただけると思いますが。
今回の IME の件は、制限ではなく、仕様変更による互換性の問題です。
ですので、互換性を維持するために、 Form で IME を ON に開発者が設定できるように Wish しますが、回避策が提示されている以上、現製品に反映されることは、ほぼありえないでしょう。(今までの経験上)
改善するとしたら、次期 .NET Framework 以降での話になると思います。 -
おがわみつぎ さん harasawaです
返信ありがとうございます、一応終わりとしましたが、再度返信を頂きましたので、書きます。
理想論としてこう有るべきと主張させていただいていますので、当然現実的には難しい場合も有ると考えます、IMEに関しては、将来は別として、現OSでの状況を調査してみました、前回も書きましたが、デスクトップ、マイコンピュータ、OutlookExpress等全く利用価値の無いと思われるソフト内でもIMEは有効になっています、その意味で有効である事の方が自然と考えています、当然セキュリティ等の重大問題で、互換を損なう非互換は、私も喜んで受け入れます、ただし、今回は仕様変更といわれますが、私のソフトに取っては1.1までさかのぼって完全に非互換となってしまっています、当然重大な問題で非互換にされてのであれば、私も、十分納得できます、今回の仕様変更で、非互換にしなければならないほどの重大問題があったとすれば、それを明確に提示して頂きたかったです。
回避策が提示されていると言いますが、私のプログラムでは、完全に作り変えに等しい状況ですので、完全に非互換となっています、その前に、非互換とは今まで動いてたプログラムの挙動が変わることですので、仕様変更ではなくどう見ても非互換です。
それから、揚げ足を取るつもりはありませんが、「何でも制限しない」とは書いていません、「全ての操作を制限することなく受け入れる」です、つまり、キーボードやマウスから行える操作は、基本的には全てを受け入れる事が原則ではないでしょうかと言う意味で言っていますので、かなり建設的な意見のつもりです。
-
中さん harasawaです
すいません、ちょっと直せば良いとのコーディング例あるようであれば提供いただければありがたいです、現在はScrollableControlを継承し、さらにWndProcの呼び出しで解決しようとしています、ここまででも相当直しましたが、さらに、マウスとキー情報の受け取り部分の作り直しとなりますので、結構大変です、別の提案としてFormをやめてPanelでと言われたのでやってみたとこScrollableControlを継承した時点とほぼ同じエラーが出ましたが、このエラーForm側の機能を使っている部分ですので、そこから先に進めませんでした。
また終わりにならなくなってしまったようですが、私の本音の事を言いますと、.Net FramwarkはIMEが有効であるべきと考えています、これを前面に出すと水掛け論で最初からになってしまいますので、ぐっと我慢して反論をしてほしくない意味も込めて、主張として書かせていただきました。
1.1に関しても2.0だけをインストールされてしまうと、やはりIMEが有効にならないため日本語が入れられません、1.1もインストールして下さいと注意書きは入れましたが、前にも書きましたが人間は必ずミスをしますので、注意だけでは、無理と考えています、そうだとすれば、プログラム提供者の責任としては、2.0で1.1が動く場合でも、日本語を入れられるように1.1も修正するとの私の決意表明の意味です。
-
Wishする予定の提案ですが,
WinForm の Formにのみオプションを付けるというのは,
一貫した理由が見つからないので,絶対に通らないと思われるので,
オプションを付けるのなら,IME にオプションをつける
の形式にするような提案の方がいいような気がします。
Systemが(Systemのメッセージキューから取り出した)
メッセージをPOSTする先のメッセージキューの(スレッドの)選定は,
一般のウィンドウでは,1. キーボード フォーカス があるコントロール(を作成したスレッドのキュー(のスレッド))に対して
2. どこにもキーボードフォーカスがあたっているコントロールがない場合は,
アクティブウィンドウ(を作成したスレッドのキュー(のスレッド))に対してになります。
(背景: ユーザーが入力する情報は,各コントロールやウィンドウに直接渡るのではなく,
一旦,Systemのメッセージキューに入り,
その後に,その各コントロールやウィンドウを作成したスレッドのメッセージキューに入ります。
2. があるのは,基本的には,システムメッセージや,メニューへのメッセージのためです)今回の件は,2. に相当するのだけど,
キーボード フォーカス(or インプット フォーカス)がない場合に,
POSTされるアクティブウィンドウのクライアント領域に,
IME の コンポジション・ウィンドウ を表示するかしないかは,
本来は,IME を利用しているユーザー側が決定することがらです。インプットフォーカスを持っているコントロールは,
コンポジションウィンドウを表示するかしないかは,
勝手にやれていいけれど,
インプットフォーカスがない場合は,
アプリケーション側の意図に関係なく,
そのままアクティブウィンドウにメッセージが投げられます。
この時に,アクティブウィンドウで,IMEを利用するかしないかは,
アプリケーション側でなく,ユーザー側に判断させるものでしょう。
(もしくは,セキュリティ・ゾーン に応じての方がさらにベストです)なので,
アクティブ・ウィンドウが,インプットフォーカスを持たない場合,
コンポジション・ウィンドウ(composition window)を
アクティブウィンドウのクライアントエリアの左上隅に表示するか,
IME を OFF にしてしまうかは,
IME のオプション設定で設定可能にすべきもののような気がします。「アクティブ・ウィンドウが,インプットフォーカスを持たない場合,
IME を OFF にする」
を選択したユーザーは,
エクスプローラ,IE,WinFormのForm,
WPF の Window 及び NavigationWindow で,
IME が OFF になり,「アクティブ・ウィンドウが,インプットフォーカスを持たない場合,
IME の コンポジションウィンドウを
アクティブウィンドウのクライアントエリア左上隅に表示する」
を選択したユーザーは,
エクスプローラ,IE,WinFormのForm,
WPF の Window 及び NavigationWindow で,
アクティブウィンドウのクライアントエリアの左上隅に表示されるのようになるのがいいんじゃないかと思います。
※ Vista からは,
概存のウィンドウ/コントロールとWPFのウィンドウ/コントロールを
ちゃんぽんにして表示できる技術もあるので,
一貫していないと,たぶん却下になります。 -
稍丼さん harasawaです
どうも完全に終わりに出来なくてすみません、私にはそこまでの知識はありませんので、書き込み、ありがとうございました。
最後に主張として書かして頂きましたが、これは、私の本心で書いている事です、今でもそうあるべきだと考えています、そうなると、確かに.NET FramworkでオフしたものをFormでオンするといった提案は首尾一貫していませんが、結果としてオンならば、私にとっては結果オーライですので、提案していただく事には賛成ですとお願いしました。
せっかく私のために動いていただくと提案していただきましたので、そちらを尊重させていただきました。
-
>オプションを付けるのなら,
>
> IME にオプションをつける
>
>の形式にするような提案の方がいいような気がします。
>
>・・・(途中略)・・・
>
>キーボード フォーカス(or インプット フォーカス)がない場合に,
>POSTされるアクティブウィンドウのクライアント領域に,
>IME の コンポジション・ウィンドウ を表示するかしないかは,
>本来は,IME を利用しているユーザー側が決定することがらです。ちょっと私は考えが違います。
もし、このようにしてしまうと、エンドユーザーはアプリケーションによってIMEの設定を意識して切り替えることになります。であれば、アプリケーションによってエンドユーザーがIMEのオンオフを切り替えることと本質的に変わりません。つまり、エンドユーザーの操作に期待してアプリケーションが作成されていることになります。例えばあるフォームに4つのテキストボックスが並んでいるとします。順に、全角、半角、全角、半角の入力を期待します。この時、テキストボックスのImeModeプロパティを設定しなければ、エンドユーザーによるIMEの切り替えに期待することになります。しかし、アプリケーションとしては、ImeModeプロパティを設定し、エンドユーザーにIMEの切り替えを意識させない方が、ユーザビリティは良いでしょう。
もっと言えば、半角入力を期待しているテキストボックスでは、間違ってもIMEがオンにならないようにした方が良いでしょう。(全角を貼り付けられる可能性は置いといて)今回問題となっているのは、この例のテキストボックスで言えば、IMEが間違ってもオンにならない設定に固定されてしまったということです。私としてはImeMode列挙体に、OffAlwaysみたいなものが追加されるのが良いんじゃないかと何となく思ってます。
しつこいですが、あくまでFormにこういうものがいるというようになった場合です。私の中では本当に要るのか要らないのか、結論が出ていません。この件に関し、どれぐらいのニーズがあるかわからないからです。簡単に改修可能であれば私もプッシュしますが、難しい(できるが工数がかかる?)と言われれば、どれだけのニーズがあるかわからない状態では積極的にプッシュできません。この件に関する代替案(PanelやControlの継承)がないわけでもないですし、代替案の方が本来正当で、今回の件がイレギュラーと判断される可能性がないわけでもないですし・・・。#まぁ、でもImeMode列挙体に、OffAlwaysみたいなものが追加されると、みんなが幸せになれるかなぁと思っています。MSFTさんも大変かもしれませんが、その先にはきっと幸せがあるんじゃないかと思います。(^^;
-
数年前を境に,
IE では,インプット・フォーカスが無い場合は,
IME が 強制OFF になるようになりました。それまでは,
インプット・フォーカスが無い場合,
画面のどこかに,コンポジション・ウィンドウが表示されていたと思います。で,この変更が,
単にユーザーエクスペリエンス向上のためのものなのか
それとも,なんらかのセキュリティ的な面からの変更なのか
は,私にはわからないんですが,
もしセキュリティ的な面からだとしたらと考えて見ます。そう考えてみて思いあたるところは...
ClickOnce は,ノータッチ デプロイメントと違って,
CASの設定を変更しなくても,デジタル証明書なしで,
最初から,インターネットゾーンで,実行できます。
(もちろん,最初に,インストールしていいか?の例の確認が入りますが)だとしたら,
インプット・フォーカスがどこにもない場合は,
IE の時の動作と同じように,強制的にOFFになった方がいいでしょう。もし可能にするのなら,
ユーザー側から解除しないといけないというような選択肢になります。もちろん,
単なるユーザーエクスペリエンス向上のために
IE での仕様変更が起こったのならば,
アプリケーション側から制御できるのは別に問題はないということになります。話を戻してみると,
アプリケーション側が,Form で,IME を OFF すれば,
今回の仕様変更と同じ効果になりますよね?
それをわざわざ強制的にOFFにしたというのは,
セキュリティ的になにか厄除けというかそういう側面もあるんじゃないかと...思うんです。
ClickOnceの(ベータ2より後での)思い切った仕様にあわせて,
厄除けだと思って,余計な動作はしないようにしておいたとか。
自分で確認したわけではないんですが,
確か,ベータ2までは,デジタル証明書での署名が必要だったような...
掲示板の質問でそんなようなやりとりもあったような気もするし,
私も,「テスト証明書」使って,ClickOnceのテストをしてたような...インプット・フォーカスが無い時に,
アクティブ・ウィンドウに対して,
Ctrl+o とかがメッセージされるのは,役に立つけど,
Ctrl+開 とかとは,そもそもメッセージできないので,
OFFにしても問題はないと考えたのももちろんあったのだとは思います。あと,
書いててあまり自信はないんですが,
というか,まったくの認識違いなのもしれませんが,
私が思うには,
インプット・フォーカスが無い時に,
POSTするキューがないから,
アクティブ・ウィンドウ(のキューが)が選ばれている
ということを裏返すと,
アクティブウィンドウに,メッセージが入ってきているのは,
Alt+... や Ctrl+... のPOST先として選ばれているということ
なんじゃないかと思います。 -
>それをわざわざ強制的にOFFにしたというのは,
>セキュリティ的になにか厄除けというかそういう側面もあるんじゃないかと...思うんです。
セキュリティに関しては私は考慮していませんでした。ただ、もしセキュリティ的に何かあるとしても、それが何なのかは私にはわかりません。あるのかも知れませんが、MSFTさんは今のところセキュリティ面に触れられていないようです。
もし今回の仕様変更がセキュリティを考慮してのことであれば、おっしゃるようにその仕様に従うしかないでしょう。
しかし、単にユーザーエクスペリエンス向上のためであるなら、議論の余地は残されていると思います。
ただ普通に考えれば、
>インプット・フォーカスがどこにもない場合は,
>IE の時の動作と同じように,強制的にOFFになった方がいいでしょう。
私もそう思います。Windowsの操作性の統一から言っても、キャレットがない場合にIMEがONになるのは違和感があります。本来はこれでいい気がします。OffAlwaysとか新設せずに。ただ、これではharasawaさんが納得しないでしょうが。(^^;
でも、UserControlはIMEが強制OFFになるようになり、ScrollableControlはそうはならなかった。これはキャレット(インプットフォーカス)とは別の判断が働いたということでしょう。この判断は、コンテナ色の強さから来ていると感じています。また、キャレット(インプットフォーカス)のある無しはアプリケーション側で制御するものであり、プログラマがキャレットをHideした時に、忘れずにIMEをOFFするようにプログラムしなければならず、それが煩わしいと思われる判断も働いたのではないでしょうか?つまり、キャレットのあるなしで、IMEの強制OFFを制御するのは破綻するのではないかと・・・
そういうわけで、結果的にコンテナ色の強いFormやUserControlなどが強制的にIMEがOFFになるようになったのだと思います。もし、セキュリティ面が理由であれば、ScrollableControlもそのように仕様変更されたのではないでしょうか?
>Form でオプション可能にするのだったら,
> OffAlways でなく OnAlways なのでは???。
Formで日本語入力を許さない場合は絶対にどんな時でも許さないのであり、許す場合はオンでもオフでもどちらでもいいと思っているのではないか?と思ったので、OffAlwaysにしてみました。つまり、今回の強制IMEオフをプログラマが選択できるようにする道を残すような感じになっています。稚拙な英語なので、良い表現があれば提案下さい。(^^; -
> コンテナ色の強さから来ていると
だとすると,ユーザーエクスペリエンスからかぁ...。
でも,だとしたら,
Form の ImeMode プロパティのデフォルト値を
NoControl から Off に変更するだけで良かった筈なので,
この仕様変更は必要なかったもの
ということになるような...。だったら,Wish は,
Form の ImeMode プロパティのデフォルト値を
NoControl から Off に変更することで対応して,
実行時にIMEを強制Offするのは,やめて欲しいがいいかなぁ。そもそもオプションは必要ないような気がします。
これなら相当ハードルが低いような。追記: .NET アプリは,デフォルト値はデータとして持っていないので,
ちょうどいい落としどころのような気がしてきました。 -
皆さん 活発なご意見ありがとうございます、これほど活発ですと、私の意見も言うべきと判断しましたので、再度意見として述べます。
まず、今回の変更理由はMSFTさんが前の方に書かれています、つまり
「シナリオとして、Form やコンテナで直接キーボードのイベントを取得することよりも、無意味にIME のウィンドウが出てしまうという声に対応することを重視した結果です。」です。
現OSではデスクトップでもマイコンピュータでもOutlookExprssでも無意味にIMEのウインドウが出ます、これは何を意味しているのでしょうか、また、無意味にと言われますが、私にとっては意味ある事ですので、そこの認識の違いが今回の最大の問題のようです。
一方.NET FrameworkのSide-By-Side実行では(一応1.0と1,1の関係ですが2.0にも当てはまる事として書きます、あてはまらないない場合はごめんなさい)「互換性の解除は、変更が及ぼす影響を詳しく分析した上で、もっとも深刻な場合にのみ行われるべきです。この手段は、特にセキュリティ関連の問題や既存の機能に重大な欠陥を解決するための最後の手段としてのみ行うものとし、API の一貫性や外観を向上したり、他の妥当な手段で解決できる不具合などを修正するために行われるべきではありません。」
つまり、互換を損なう修正は最後の手段で行うべき事で、単に重視した結果行うべきではないと考えます。
「マイクロソフトは、互換性が重大な影響を及ぼすケースを発見した場合は、変更を文書にして公表し、可能な対策を提供します。」
互換性に重大な影響を及ぼすケースが発見されましたが、変更を文書にして公開し、可能な対策を提供してくれたのでしょうか。
それが「trapemiya さんのご提案のように、Control から継承したコントロールを全面にドッキングして使用するのが良いでしょう。Windows フォームアプリケーションのデザインとしてもその方が自然に思います。」なのでしょうか。
とは言ってもこの文章も1.0と1.1の話しで1.1と2.0は単なる仕様変更といわれれは仕方がないですが、希望としては出来る限り互換は取ってほしいものです。
何とか対応すべくScrollableControlを継承しましたが、Form側しかない機能は当然エラーとなってしまいました、このエラーを全て解消しても、今度は両方にある機能はエラーにならないで誤動作します、その分を分かった範囲ですがForm側に移しながらテストしましたが、こちらも、分かっている範囲ですが、Tabと矢印キー4個が全く受け入れられません、それでWndProcの使用の意見を頂きましたが、そうすると今度は受け側のコーディングの修正となり、単に継承すれば良いレベルの話では全くありません、既に数十箇所の大幅修正となってしまっており、結構大変な状況です。
現時点では、私でも簡単に修正可能な対策を提供してほしいとの思いはまだ強いです。
ScrollableControlの継承のみでWndProcを使わなくて、もっと簡単(あまり修正しなくても良い)にTabキー、矢印キーを受けられる方法が有ると、とりあえずは嬉しいのです。
ただ、一言言わせ頂くと、やはりIMEが有効で立ち上がる機能があれば、私のようなソフトも含め、多様なプログラムが作れるので、.NET Framworkの利用価値が上がると信じています。
-
# また,文字化けしたので書き直しています。
どうも,WndProcをオーバーライドすると,
WPFでは,WndProc自体がないようなので,
具合が悪いので,
ProcessDialogKey,OnKeyPreview, OnKeyPress で,
処理するコードに変えてみました。ScrollableControlを継承して
--------------------------------------------------------------------------------------------
using System;
using System.Drawing;
using System.Windows.Forms;
class MyCanvas : System.Windows.Forms.ScrollableControl
{
string s = String.Empty;
Font f_o;
SolidBrush b_o;
public MyCanvas()
{
f_o = new Font("MS Gothic", 12);
b_o = new SolidBrush(Color.Black);
}
protected override bool ProcessDialogKey(Keys keyData)
{
switch (keyData)
{
// プレビューしたいキーを指定
case Keys.Return:
case Keys.Escape:
case Keys.Up:
case Keys.Down:
case Keys.Left:
case Keys.Right:
case Keys.PageUp:
case Keys.PageDown:
case Keys.Home:
case Keys.End:
case Keys.Tab:
case Keys.Delete:
case Keys.Back:
case Keys.Insert:
case Keys.F1:
case Keys.F2:
case Keys.F3:
case Keys.F4:
case Keys.F5:
case Keys.F6:
case Keys.F7:
case Keys.F8:
case Keys.F9:
case Keys.F10:
case Keys.F11:
case Keys.F12:
return true;
default:
return base.ProcessDialogKey(keyData);
}
}
protected override void OnPreviewKeyDown(PreviewKeyDownEventArgs e)
{
switch (e.KeyData)
{
// ProcessDialogKeyでtrueとしたもの
case Keys.Return:
case Keys.Escape:
case Keys.Up:
case Keys.Down:
case Keys.Left:
case Keys.Right:
case Keys.PageUp:
case Keys.PageDown:
case Keys.Home:
case Keys.End:
case Keys.Tab:
case Keys.Delete:
case Keys.Back:
case Keys.Insert:
case Keys.F1:
case Keys.F2:
case Keys.F3:
case Keys.F4:
case Keys.F5:
case Keys.F6:
case Keys.F7:
case Keys.F8:
case Keys.F9:
case Keys.F10:
case Keys.F11:
case Keys.F12:
// 確認のため,ここでは文字として出力
this.AddString("(" + e.KeyData.ToString() +
" OnPreviewKeyDown)\n");
break;
default:
base.OnPreviewKeyDown(e);
break;
}
}
protected override void OnKeyPress(KeyPressEventArgs e)
{
// 文字は,ここで処理。
this.AddString("(" + e.KeyChar.ToString() + " OnKeyPress)\n");
e.Handled = true; // <-- 必要
//base.OnKeyPress(e);
}
// 例えば,の表示です。
public void AddString(string str)
{
s += str;
this.Invalidate();
}
protected override void OnPaint(PaintEventArgs e)
{
e.Graphics.DrawString(s, f_o, b_o, 0, 0);
}
}
のようにしておいて,
一旦,ビルドすると,フォームをデザインビューで開くと,
ツールボックスに表示されるので,
フォームへドラッグ&ドロップして,
そのDockプロパティをFillして,OKでしょう。たぶん。
(簡単な確認はしています) -
> こうしてもユーザーが漢字キーを押してIMEをオンにできてしまうので
OffAlways の意味がわかりました。
スタイルシートの style="ime-mode:disabled" とかにあわせて
Disabled がいいかも。今の Off が inactive に相当するので,
2.0からの強制Off は,Disabled に相当でしょう。でも,Disable は,すでにあるんですよね。う~ん。
だったら,
FormのImeModeプロパティの規定値をNoControlからDisableにする
かなぁ...。
(ひょっとして,IMEが入っていないWindowsだと,
NoControl以外だとエラーになってしまうとか,
今頃(ベータ2以降)からデフォルト値は変更できないと,却下されたとかかなぁ~) -
皆様
仕様変更により大変なご迷惑をお掛けして申し訳ありません。IME のサポートに関しては多様なご意見があり、今回の変更も他の要望に対応するための苦渋の決断ではあったのですが、このような事態になったという事実を真摯に受け止め、今後は仕様変更に関する早めの情報提供を徹底するよう心がけて参ります。
harasawa 様、V2.0 では、ScrollableControl に PreviewKeyDown というイベントがございます。こちらでは、TAB や矢印キーのイベントも取得できると思います。お試しください。harasawa 様の問題解決になればよいのですが、V2.0 から追加されたイベントになりますので、その辺りが心配です。
さて、今後の対応ですが、皆様いろいろなご意見をありがとうございます。非常に参考になります。
ただ、個人的には、単に On / Off の選択を可能にするだけでは不十分なのではないかと感じています。それは、On にした場合には依然変換ウィンドウが左上にでることになり、Windows フォームが、それを制御するすべを持っていないためです。もちろん、それでも構わないという場合があることはこのスレッドで十分認識いたしましたが、フレームワークを提供する側の立場としては、やはり、「変換ウィンドウが左上に出るのは構わない」という前提で仕様を決めることはいささか消極的に思えます。また、子コントロールを配置するための ContainerControl に対してコントロールを置かない場合にこそ効果のある機能を盛り込むということにも若干の抵抗があります。そこで、Windows フォームの継承関係を考慮した上で、総合的な視点から対応を検討していく必要があるように思います。
重ね重ね、仕様変更によりご迷惑をおかけし、申し訳ありませんでした。
今後ともよろしくお願いいたします。この投稿は現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。詳しくは http://www.microsoft.com/japan/communities/msp.mspx をご覧ください。
-
ディベロッパー製品開発統括部インターナショナルPM - MSFT さん 皆さん harasawaです
IMEに関しては難しい問題もありますが、私のニーズはとにかく日本語が入れられれば良かっただけです、このように、非常に単純な理由でIMEが無効になった事で、問題が発生してしまう使い方をしている人もいる事を忘れないで下さい、ある人は無意味と思っても、ある人には非常に重要な場合がありますので、これを教訓に、今後は互換性には最大限の注意を払われる事を期待します。
こんなに多くの方の意見をもらいました、問題が起きた時はショックでしたが、逆にこのような機会を持てた意味で、収穫も多かったのではないかと振り返っています、今回のことがMicrosoftの.NET Framworkが輝かしい未来を築ける、糧に少しでもなれば幸いです。
今作っているソフトを最終的にどのようにするかはまだ決まってはいません、ただ、皆さんのおかげで何とか完成にはこぎつけそうです、気持ちの整理はすでに出来ております、私のURLの赤字のお詫びが消えたときが完成です。
脱線ですが、私の作っているプログラムはこのフォーラムには似つかわしくない話ですが、コンピュータの素人が基幹システムを作ることが出来る事を実現しようとしています、私の夢は、高校生が私のソフトでシステム作りとは何かを学ぶようになる事です、今は夢に向かってプログラムを作っています、生涯一プログラマーとして。
-
ディベロッパー製品開発統括部インターナショナルPM - MSFT さんからの引用 皆様
仕様変更により大変なご迷惑をお掛けして申し訳ありません。
IMEの挙動がおかしいので、ここへたどり着いたのですが、これは仕様変更なのでしょうか。重大なバグがあるのでは?
MainForm上のRichTextでIMEをOnにしておきます。そしてOptionFormをShowDialog()で立ち上げます。OptionFormを終了して、MainFormに戻ると、RichTextのIMEはOnのままです。ところが、もう1度OptionFormを立ち上げて、またRichTextに戻ると、IMEがOffになっています。
これ、再現性がありますね。何度でも繰り返してできるですが。
もっと単純にして、FormにRichTextだけ載せて、ImeModeをOnに設定したexeを作成します。このexeを2つ走らせます。交互に使ってみると、最初のうち、勝手にImeModeをOffにされます。OffにされたらOnに変えて、あと使っていると、Offにされなくなりますが、明らかに異常ですね。
-
-
続報を見つけたのでメモしておきます.
2007年4月17日付けでKBが出ています.
扱い的には .NET Framework 2.0 の不具合となっています.現在は Hotfix がリリースされていて,一般向けには年末のアップデートリリース (.NET 3.5 同梱) の "Red Bits" にて修正されるようです.
変更点としては,コントロールの基底クラスである System.Windows.Forms.Control に CanEnableIme という仮想プロパティが新設されます.この仮想プロパティをオーバーライドし,true を返すことで,該当コントロールで IME を有効化できるようになりました.
なお,仮想プロパティの新設ということで,新しいプロパティを使用するアプリケーションは,アップデートのあたっていない .NET Framework 2.0 では動作しないと考えられます.