C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[9]: 確定前の文字列がある状態でテキストボックスのフォーカス移動


(過去ログ 160 を表示中)

[トピック内 22 記事 (1 - 20 表示)]  << 0 | 1 >>

■92477 / inTopicNo.1)  確定前の文字列がある状態でテキストボックスのフォーカス移動
  
□投稿者/ 田中 (1回)-(2019/09/30(Mon) 04:33:16)

分類:[.NET 全般] 


Windows Form アプリケーション
Windows 10 1809
VB.NET 2017(Framework4.7)
※VB2010(Framework3.5)でも同じ結果。


全角文字入力が未確定のテキストボックスから
別のテキストボックスに移動して確定すると、
プログラムが強制終了します。

フォームを作成してなにもコードを入れてなくてもなります。

おそらくVB以外の.NET環境でも共通して発生するのかと
考えていますが、同じ事象で悩まれている方
おられますでしょうか?

また、解決方法等の情報がございましたら
教えていただけますと幸いです。


引用返信 編集キー/
■92479 / inTopicNo.2)  Re[1]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ WebSurfer (1930回)-(2019/09/30(Mon) 10:25:03)
No92477 (田中 さん) に返信

全角入力というのは MS IME を使っているのでしょうか? とすると、未確定
で移動というのは具体的にどういう手順でやるのでしょう?

質問者さんの環境固有の問題のように思えますが、他の PC で同じアプリを
実行して見るなどして、どこに問題がありそう下の切り分けはできませんか?

環境固有の問題ではなさそうということであれば、問題を再現するのに必要
最低限のコードと詳細手順を書けませんか?


引用返信 編集キー/
■92481 / inTopicNo.3)  Re[2]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 田中 (2回)-(2019/09/30(Mon) 10:45:50)
No92479 (WebSurfer さん) に返信
> ■No92477 (田中 さん) に返信
>
> 全角入力というのは MS IME を使っているのでしょうか? とすると、未確定
> で移動というのは具体的にどういう手順でやるのでしょう?
>
> 質問者さんの環境固有の問題のように思えますが、他の PC で同じアプリを
> 実行して見るなどして、どこに問題がありそう下の切り分けはできませんか?
>
> 環境固有の問題ではなさそうということであれば、問題を再現するのに必要
> 最低限のコードと詳細手順を書けませんか?
>
>

ご返信ありがとうございます。
MSのIMEとなります。
他のWindows10 PCでもテストを行っていますが、同じ結果となりました、



再現方法ですが、

コードは何も記載せず、フォーム上に
テキストボックスコントロールを複数設置します。

IME入力をオン(全角入力)にして、文字を入力
通常はEnterで確定しますが、確定せず
別のテキストボックスへ移動し、
確定すると強制終了となります。




引用返信 編集キー/
■92482 / inTopicNo.4)  Re[3]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 774RR (733回)-(2019/09/30(Mon) 11:11:43)
2019/09/30(Mon) 11:15:13 編集(投稿者)

オイラんとこの Win10Pro1809 64bit VS2019Pro Ver 16.3.1 で再現したっす。
テキストボックス2つを MS-IME の候補ウインドウの大きさより離して横に配置
片方に「あいう」と入力しもう一つをマウスクリックすると候補ウインドウが移動
Enter で確定すると FormClosing / FormClosed ハンドラが呼ばれることなく異常終了
終了コードは 0x4000001f STATUS_WX86_BREAKPOINT ということだったのでネイティブコードデバッグを有効化

0x00200001 で例外がスローされました (Form1.exe 内): 0xC0000005: 場所 0x00200001 の実行中にアクセス違反が発生しました

0xC0000005 は変化しないけど場所は毎回変わる様子

ってことで多分 MS-IME か .NET Framework のバグっす。

オイラたちに言ってもしょうがないので MSDN Forum とかに報告、ないしはインシデントレポート。

s/1803/1809/
引用返信 編集キー/
■92483 / inTopicNo.5)  Re[3]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 魔界の仮面弁士 (2398回)-(2019/09/30(Mon) 11:11:53)
No92481 (田中 さん) に返信
> MSのIMEとなります。
> 他のWindows10 PCでもテストを行っていますが、同じ結果となりました、

手元に 1809 が無いのですが、ひとまず 1803 と 1903 では再現できませんでした。
以下思い付きで:

(1) ユーザー辞書が破損していないか?
 → 他の PC で再現している以上、この可能性は低そうですが、
  一応念のため、[修復(O)] ボタンを押してみたら改善しないでしょうか。

(2) システム辞書で Outlook 連絡先が有効になっていないか?
 → Outlook 連携で変換時の失敗やもたつきの要因になりうるので、
  使っていないのなら、[辞書/学習]タブから Off にしてみるとか。
 →この辞書が運用上必要な場合は、Office の Update が無いかを確認してみましょう。

(3) 「Google 日本語入力」など、他の IME で再現するか検証する
 → MS-IME 自体の問題なのか、IMM / Text Services Framework の問題なのかの
  切り分けにはなるかもしれません。
引用返信 編集キー/
■92484 / inTopicNo.6)  Re[3]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ WebSurfer (1931回)-(2019/09/30(Mon) 11:13:11)
No92481 (田中 さん) に返信

Form に TextBox を 5 個ドラッグ&ドロップしてやってみましたが再現
しません・・・というか、確定しないまま他のテキストボックスに移動
できないのです。

先に聞きましたが、未確定で移動というのは具体的にどういう手順で
やっているのでしょう?
引用返信 編集キー/
■92485 / inTopicNo.7)  Re[3]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ WebSurfer (1932回)-(2019/09/30(Mon) 11:24:41)
No92481 (田中 さん) に返信

No92482 の 774RR さんの手順で問題が再現しました。

OS は Windows 10 Pro 64-bit バージョン 1903 (OS ビルド 18362.387)、
Visual Studio Community 2015 Update3, .NET 4.6.1 の Windows Forms
アプリ、言語は VB.NET です。
引用返信 編集キー/
■92486 / inTopicNo.8)  Re[4]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 田中 (3回)-(2019/09/30(Mon) 11:27:13)
>774RR さん

VSのデバック画面には何も表示されず、クラッシュし
Windowsのイベントログに

WindowsApp1.exe
1.0.0.0 5d916587 unknown 0.0.0.0 00000000 c00000fd 8c4434da 247c 01d5773518664f95
C:\Users\xxxx\source\repos\WindowsApp1\WindowsApp1\bin\Debug\WindowsApp1.exe
unknown 8453b506-1203-4250-a34c-439a250e8f77

こんなようなものが記録されますので、バグ?と思っていました。
ずっとこの状況に悩まされていました。

少しすっきりしました。



>魔界の仮面弁士さん

ご確認ありがとうございます。
セットしたばかりPCでも発生しました。

再現方法に不足があり申し訳ございません。
おそらくクリックでフォーカス移動した際に発生します。


>WebSurferさん

再現テストしていただき、ありがとうございます。

引用返信 編集キー/
■92487 / inTopicNo.9)  Re[4]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 魔界の仮面弁士 (2399回)-(2019/09/30(Mon) 11:39:21)
No92482 (774RR さん) に返信
> オイラんとこの Win10Pro1809 64bit VS2019Pro Ver 16.3.1 で再現したっす。
> テキストボックス2つを MS-IME の候補ウインドウの大きさより離して横に配置
> 片方に「あいう」と入力しもう一つをマウスクリックすると候補ウインドウが移動
> Enter で確定すると FormClosing / FormClosed ハンドラが呼ばれることなく異常終了
> s/1803/1809/


No92485 (WebSurfer さん) に返信
> No92482 の 774RR さんの手順で問題が再現しました。
> OS は Windows 10 Pro 64-bit バージョン 1903 (OS ビルド 18362.387)、
> Visual Studio Community 2015 Update3, .NET 4.6.1 の Windows Forms
> アプリ、言語は VB.NET です。

TextBox1 に「あいう」と入力し、変換キーまたはスペースキーで
第一候補の「アイウ」に変わった状態の、『入力未確定状態』で
TextBox2 に移してから Enter 確定しただけでは止まりませんでした。

TextBox1 に「あいう」と入力し、変換を継続して
 1 アイウ
 2 愛生
 3 あいう 》
の変換候補ウィンドウが出ている状態で TextBox2 に移してから
Enter 確定した場合は停止することがありました。
(常にクラッシュするわけではなく、継続入力できることもある)


Win10 Pro 1903 (x64) Build 18362.356
Visual Studio Enterprise 2017 Version 15.9.16
.NET Framework 4.8.03752
引用返信 編集キー/
■92488 / inTopicNo.10)  Re[5]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 魔界の仮面弁士 (2400回)-(2019/09/30(Mon) 12:01:46)
No92487 (魔界の仮面弁士) に追記
> TextBox1 に「あいう」と入力し、変換を継続して
>  1 アイウ
>  2 愛生
>  3 あいう 》
> の変換候補ウィンドウが出ている状態で TextBox2 に移してから
> Enter 確定した場合は停止することがありました。


今のところ、x64 ビルドの場合は停止していません。
x86 / AnyCPU / AnyCPU32BitPreferred の場合に再現しています。


また、プロジェクトのプロパティの[アプリケーション]タブにあ
「アセンブリ名」「ルート名前空間」のボックス間でテストした場合は
問題ありませんでした。


Win10 1809 で、ANSI 版 IMM32 関数の内部実装が変更されたそうですが、関係あるのかな…。
https://social.msdn.microsoft.com/Forums/ja-JP/c8c24c72-4716-42e6-9278-dd6e599859e7/
引用返信 編集キー/
■92489 / inTopicNo.11)  Re[4]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 774RR (734回)-(2019/09/30(Mon) 12:48:03)
オイラんとこと魔界の仮面弁士さんとことで、微妙に状況が異なるような・・・
Visual Studio のプロパティ画面では確かに死なないっすね。でもここって Forms.TextBox 使ってないのでは?

Form1.exe の場合 x86/x64/AnyCPU32bit/AnyCPU のどれでもほぼ 100% の確率で死にます。
x64 にすると
0x0000000000000000 で例外がスローされました (HugeArray.exe 内): 0xC0000005: 場所 0x0000000000000000 の実行中にアクセス違反が発生しました
になったりするので 32bit コード内が原因ではなさそう。

イベントビューアー→ Application で見ると
> 障害が発生しているアプリケーション名: Form1.exe、バージョン: 1.0.0.0、タイム スタンプ: 0x8ff15b90
> 障害が発生しているモジュール名: ntdll.dll、バージョン: 10.0.17763.737、タイム スタンプ: 0xd7315be6
> 例外コード: 0x4000001f
> 障害オフセット: 0x000e34bb
例外コードと例外オフセットは毎回同じ様子っす。

まあ今の時点でオイラたち「ユーザー」がいろいろ考えても無駄っぽい。
Microsoft にインシデントレポート投げて終了っすね。
引用返信 編集キー/
■92490 / inTopicNo.12)  Re[5]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 田中 (4回)-(2019/09/30(Mon) 15:00:38)
>WebSurferさん 774RRさん 魔界の仮面弁士さん

色々とテストしていただきありがとうございます。
かなり長く困っていた部分ですので(バグとのことで解決には至りませんでしたが)
とてもすっきりしました。初めてですが掲示板で相談してよかったと思っています。

ご助言いただきましたとおりMicrosoftForumsには書き込みをしてみました。
※初めて書き込むので不慣れですが、何かフォローすべきことがあれば
 教えていただけますと幸いです。

https://social.msdn.microsoft.com/Forums/ja-JP/c84d040b-b85b-4f85-a7d1-e76de274b8e5?forum=netfxgeneralja



根本的な解決については、バクの解消となるかと思いますが、
そちらはMicrosoftForumsで検討していきますが。

(かなり昔から存在しているバグのようなので希望を薄く感じており)
こちらの掲示板では回避を検討できないか考えておりますので、
もう少しお付き合いいただけますと幸いです。


回避策を2つ考えたのですが、もしもう少し工夫したほうが良いとか、
このソースをもとに何か良いご意見いただけましたら幸いです。

※今回の問題とは未関係ですが、2番の方法を応用すると
 OSの設定を変更しなくても、IMEモードを半角カタカナ等に
 変更できることがわかりました。


1.少し原始的ですが、SendKeysでエスケープキーのキーイベントを送信する。

Private Sub TextBox_GotFocus(sender As Object, e As EventArgs) Handles TextBox1.Enter, TextBox2.Enter, TextBox2.Enter
SendKeys.Send("{ESC}")
SendKeys.Send("{ESC}")
SendKeys.Send("{ESC}")
End Sub


2.Text Services FrameworkにてInputScopeを変更し、別のInputScopeとして認識させて
 変換中のテキストをキャンセルさせる。

<DllImport("msctf.dll", SetLastError:=True, CharSet:=CharSet.Auto)>
Private Shared Function SetInputScope(ByVal hwnd As IntPtr, ByVal inputscope As IntPtr) As IntPtr

End Function


Private Sub TextBox_Enter(sender As Object, e As EventArgs) Handles TextBox1.Enter, TextBox2.Enter, TextBox3.Enter
'SetInputScope(DirectCast(sender, TextBox).Handle, 40) 'アルファベット
SetInputScope(DirectCast(sender, TextBox).Handle, 44) '日本語入力
'SetInputScope(DirectCast(sender, TextBox).Handle, 45) '半角カタカナ
End Sub

Private Sub TextBox_TextChanged(sender As Object, e As EventArgs) Handles TextBox1.KeyPress, TextBox2.KeyPress, TextBox3.KeyPress
SetInputScope(DirectCast(sender, TextBox).Handle, 0) 'デフォルト
End Sub


引用返信 編集キー/
■92501 / inTopicNo.13)  Re[6]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 魔界の仮面弁士 (2401回)-(2019/10/01(Tue) 10:25:02)
No92488 (魔界の仮面弁士) に追記

Windows 10 で作成した exe を右クリックして、
[互換性]タブから 互換モード Windows 8 を選択したところ
今のところクラッシュしていないように見えます。

軽減しただけなのか、解消したのか、それとも
当方だけの現象なのかは定かではないですが。
引用返信 編集キー/
■92502 / inTopicNo.14)  Re[7]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 774RR (736回)-(2019/10/01(Tue) 11:03:22)
おおホンマやクラッシュせぇへん(混乱)
軽減したのか解消したのかはやはり定かではない感触
でもこれを「解決策」とするにはモヤモヤ感が残るっすね

今この瞬間に、この現象で困っているなら対策にはなりそう
引用返信 編集キー/
■92503 / inTopicNo.15)  Re[7]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 大谷刑部 (25回)-(2019/10/01(Tue) 11:37:51)
No92501 (魔界の仮面弁士 さん) に返信
> ■No92488 (魔界の仮面弁士) に追記
>
> Windows 10 で作成した exe を右クリックして、
> [互換性]タブから 互換モード Windows 8 を選択したところ
> 今のところクラッシュしていないように見えます。
>
> 軽減しただけなのか、解消したのか、それとも
> 当方だけの現象なのかは定かではないですが。

win7 .Net4.5の場合、クラッシュしないどころか未確定状態でマウスでほかのコントロールに移動したら、
テキストボックス同士だと未確定のテキストが移動して移動先のテキストボックスで正常に[enter]で確定するだけなので、
(タブキーだと移動すらできない)
.Netのバグの可能性は低く、Win 10の特定のバージョンのOSのバグの可能性が濃厚なんじゃなかろうか?
とすれば、クレーム付ける先が同じMSでもVisual StadioチームじゃなくOSのチームの方がいいような気もします。

引用返信 編集キー/
■92504 / inTopicNo.16)  Re[8]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 魔界の仮面弁士 (2402回)-(2019/10/01(Tue) 12:01:39)
No92503 (大谷刑部 さん) に返信
> .Netのバグの可能性は低く、Win 10の特定のバージョンのOSのバグの可能性が濃厚なんじゃなかろうか?


[Debug Diagnostic Tool] で、クラッシュログを取るところまではできましたが、
例外スレッドのコールスタックを読み解けないので、追跡を断念。
https://www.microsoft.com/en-us/download/details.aspx?id=58210

(なぜ GetMessageW ではなく GetMessageA が居るんだろう?)


0x00200001
msctf!CInputContext::_DoEditSession+42531
msctf!CInputContext::_EditSessionQiCallback+4f
msctf!CInputContext::_EmptyLockQueue+ec
msctf!CACPWrap::OnLockGranted+268
msctf!CBackingStore::RequestLock+a0
msctf!CACPWrap::RequestLock+4b
msctf!SafeRequestLock+3e
msctf!CInputContext::_PostponeLockRequestCallback+76
msctf!_GetMsgHook+3f15c
msctf!TF_Notify+c5
user32!CtfHookProcWorker+2b
user32!CallHookWithSEH+2a
user32!__fnHkINLPMSG+5b
ntdll!KiUserCallbackDispatcher+4d
win32u!NtUserGetMessage+c
user32!GetMessageA+55
System_Windows_Forms_ni!DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef, System.Runtime.InteropServices.HandleRef, Int32, Int32)+45
System_Windows_Forms_ni!DomainBoundILStubClass.IL_STUB_PInvoke(MSG ByRef, System.Runtime.InteropServices.HandleRef, Int32, Int32)+45
System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)+310
System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)+310
System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+175
System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+175
System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+4f
System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+4f
Microsoft_VisualBasic_ni!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()+93
Microsoft_VisualBasic_ni!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.OnRun()+93
Microsoft_VisualBasic_ni!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.DoApplicationModel()+83
Microsoft_VisualBasic_ni!Microsoft.VisualBasic.ApplicationServices.WindowsFormsApplicationBase.Run(System.String[])+65
WindowsApp1.My.MyApplication.Main(System.String[])+6e
clr!CallDescrWorkerInternal+34
clr!CallDescrWorkerWithHandler+6b
clr!MethodDescCallSite::CallTargetWorker+16a
clr!RunMain+1b3
clr!Assembly::ExecuteMainMethod+f7
clr!SystemDomain::ExecuteMainMethod+5ef
clr!ExecuteEXE+4c
clr!_CorExeMainInternal+dc
clr!_CorExeMain+4d
mscoreei!_CorExeMain+d6
mscoree!ShellShim__CorExeMain+9e
mscoree!_CorExeMain_Exported+8
kernel32!BaseThreadInitThunk+19
ntdll!__RtlUserThreadStart+2f
ntdll!_RtlUserThreadStart+1b

引用返信 編集キー/
■92505 / inTopicNo.17)  Re[9]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 大谷刑部 (27回)-(2019/10/01(Tue) 14:21:59)
No92504 (魔界の仮面弁士 さん) に返信
> ■No92503 (大谷刑部 さん) に返信
>>.Netのバグの可能性は低く、Win 10の特定のバージョンのOSのバグの可能性が濃厚なんじゃなかろうか?
>
>
> [Debug Diagnostic Tool] で、クラッシュログを取るところまではできましたが、
> 例外スレッドのコールスタックを読み解けないので、追跡を断念。
> https://www.microsoft.com/en-us/download/details.aspx?id=58210
>
> (なぜ GetMessageW ではなく GetMessageA が居るんだろう?)

Win API系が絡んでいるんだとすると、32bit 64bit問題の可能性があるかもしれませんね。
Win7で云々と記載した現象を試したのは32bitです。

32bitアプリとしてコンパイル(最新のVSでそれができるか手元に環境がないのでわかりませんが)して、同じOS同じ.Netframeワークのバージョンで再現しなくなるなら、
それがボトルネックである可能性が高くなります。

たまにありますね。64bitOS環境なのに、dll関係が32bitでないと動かないことが。
SSISでOLEDBプロバイダー接続(accessに接続するときとか)でそんなことが起こりました。
Officeは64bit版のままで問題なく、あくまでOLEDBプロバイダーが32bit版じゃなきゃだめ、要するにoffice自体は64bitでインストールし、
Accessランタイムを32bit版で追加インストールすると動くようになる。という類の話。



引用返信 編集キー/
■92506 / inTopicNo.18)  Re[6]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 大谷刑部 (28回)-(2019/10/01(Tue) 14:31:13)
No92488 (魔界の仮面弁士 さん) に返信
> ■No92487 (魔界の仮面弁士) に追記
>>TextBox1 に「あいう」と入力し、変換を継続して
>> 1 アイウ
>> 2 愛生
>> 3 あいう 》
>>の変換候補ウィンドウが出ている状態で TextBox2 に移してから
>>Enter 確定した場合は停止することがありました。
>
>
> 今のところ、x64 ビルドの場合は停止していません。
> x86 / AnyCPU / AnyCPU32BitPreferred の場合に再現しています。
>
>
すいません。この書込み見落としてました。
そうだとするとこのケースは逆ですね。
であるなら、リリース環境のOSがどうかによりますが、
エンドユーザーの規約で「32bitじゃなきゃだめ」とかじゃなきゃ、x64ビルドにすりゃいいという話になりますね。
もうさすがに64bit端末の方が主流ですからね。

引用返信 編集キー/
■92510 / inTopicNo.19)  Re[6]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
□投稿者/ 大谷刑部 (29回)-(2019/10/01(Tue) 15:01:52)
No92490 (田中 さん) に返信
> 回避策を2つ考えたのですが、もしもう少し工夫したほうが良いとか、
> このソースをもとに何か良いご意見いただけましたら幸いです。
>
> ※今回の問題とは未関係ですが、2番の方法を応用すると
>  OSの設定を変更しなくても、IMEモードを半角カタカナ等に
>  変更できることがわかりました。
>
>
> 1.少し原始的ですが、SendKeysでエスケープキーのキーイベントを送信する。
>
> Private Sub TextBox_GotFocus(sender As Object, e As EventArgs) Handles TextBox1.Enter, TextBox2.Enter, TextBox2.Enter
> SendKeys.Send("{ESC}")
> SendKeys.Send("{ESC}")
> SendKeys.Send("{ESC}")
> End Sub
>
>
> 2.Text Services FrameworkにてInputScopeを変更し、別のInputScopeとして認識させて
>  変換中のテキストをキャンセルさせる。
>
> <DllImport("msctf.dll", SetLastError:=True, CharSet:=CharSet.Auto)>
> Private Shared Function SetInputScope(ByVal hwnd As IntPtr, ByVal inputscope As IntPtr) As IntPtr
>
> End Function
>
>
> Private Sub TextBox_Enter(sender As Object, e As EventArgs) Handles TextBox1.Enter, TextBox2.Enter, TextBox3.Enter
> 'SetInputScope(DirectCast(sender, TextBox).Handle, 40) 'アルファベット
> SetInputScope(DirectCast(sender, TextBox).Handle, 44) '日本語入力
> 'SetInputScope(DirectCast(sender, TextBox).Handle, 45) '半角カタカナ
> End Sub
>
> Private Sub TextBox_TextChanged(sender As Object, e As EventArgs) Handles TextBox1.KeyPress, TextBox2.KeyPress, TextBox3.KeyPress
> SetInputScope(DirectCast(sender, TextBox).Handle, 0) 'デフォルト
> End Sub
上記の2者択一なら2の方がいいでしょうね。
1の場合、Gotfocus発生の時点で未確定のテキストがどういう状態になっているか微妙な気がするので、エスケープキーによるキャンセルの発動により、よからぬ挙動が起こるリスクがあるような。

ただ、2もKeyPresをハンドルするのはやめた方がいいと思いますよ。未確定のまま次の文字入れたら不安定な挙動をするような気がします。


引用返信 編集キー/
■92521 / inTopicNo.20)  Re[7]: 確定前の文字列がある状態でテキストボックスのフォーカス移動
 
□投稿者/ 田中 (5回)-(2019/10/02(Wed) 00:13:24)
>魔界の仮面弁士さん

互換性モードを数台のWin10Pro(64bit)で試しましたところ、
確かにエラーは発生しなくなりました。

回避策3として追記したいと思います。
また、追跡調査ありがとうございます。


>大谷刑部

ご助言ありがとうございます。
もう少しソースを工夫してみます。


>皆様

回避策の3と4を追記します。

3.互換性モードを利用する。

Windows 10 で作成した exe を右クリックして、
[互換性]タブから 互換モード Windows 8 を選択。

インストーラに組込む場合は、以下レジストリに追加する。
※追加する値はテスト実行するなどして洗い出す。

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers


4.Visualスタイルを無効化する。 ※いろいろ弊害がありそうですが

プロジェクトのプロパティの[アプリケーション]タブにある
Visualスタイルのチェックを外す。



本件、もう少し論議したほうがいいのか少し悩みますが、
回避策がたくさん出てきましたので、最後の書き込みから
24時間がたちましたら解決済みフラグを付けたいと思いますが
いかがでしょう。
※特にご意見がなければクローズいたします。


引用返信 編集キー/

次の20件>
トピック内ページ移動 / << 0 | 1 >>

管理者用

- Child Tree -