IMEが有効なときが2段階のショートカットキーがきかない
-
Mery 3.7.1 x64（Win11 x64 Pro 23H2にて動作確認）
連続での問い合わせとなり失礼します。Zenモードの起動に割り当てられているCtrl+K, ZのショートカットキーがIME有効時に使えません。
これはGoogle日本語入力でもMS IMEでも同じのようです。
Visual Studio Codeにおいてこのような挙動になっていないため、Meryのバグと思われます。| yuishin | 返信 -
ご報告ありがとうございます。
同様の環境で確認してみましたが、IME がオンの状態でも問題なく 2 段階ショートカット キーが動作していることを確認しました。
検証した環境は、Windows 11 Pro 23H2 (ビルド 22631.3593) と Mery Ver 3.7.1 (x64) の組み合わせです。
IME は Windows 11 標準の IME を使用し、「以前のバージョンの Microsoft IME を使用する」のオン/オフや Google 日本語入力でも正常に動作しました。
お手数ですが、再度 [Zen モード] に正しくキーボード割り当てがされているかご確認いただけますでしょうか。
また、問題なくキーボード割り当てがされている場合は、プラグインなどの外的要因も考えられます。
プラグインを導入されている場合はその情報を、また、キーボードの操作を補助するアプリなどの使用についても教えていただけますと、解決の手がかりになるかもしれません。
| Kuro | 返信 -
Kuroさん、こんにちは。
2ストロークキーのショートカットについて、yuishinさんと同じ現象が発生したため、ご報告します。
以前の「Linuxでの動作報告（とバグ報告）」で、Kuroさんの環境でも同様の現象をご確認されていたと思いますが、改めてご確認いただけると幸いです。
発生した現象の詳細
IMEがONの状態で2ストロークキーのショートカットを使用すると、ショートカットが効かなくなることがあります。
例えば、Meryでは以下のようなショートカットがあります。
- 「Zen モード」：
Ctrl+K, Z - 「編集モードの選択」：
Ctrl+K, M
これらのショートカットが、IMEがONの状態では使用できなくなることがあります。
ただし、この状態でもIMEをOFFにすると、2ストロークキーのショートカットは正常に使用できます。
また、一度この現象が発生すると、別のポータブル版やインストーラー版のMeryでも同様の現象が発生します。
さらに、PCを再起動するまで現象が継続するようです。
現象の再現方法
まだ確実な再現手順を特定できておらず、再現には少し手間取っています。
現時点では、再現方法の一つとして、Meryの
Pluginsフォルダーに「Markdown プレビュー プラグイン」を追加したり削除したりした後、Meryを起動してIMEをONにすると現象が発生することがあります。念のため、Mery v3.8.9のポータブル版を新たにダウンロードして確認しましたが、こちらでも同じ現象が発生しました。
現象発生時の環境
IMEはWindows 11標準のMicrosoft IMEを使用しています。
「以前のバージョンの Microsoft IME を使う」の設定については、ON・OFFのどちらでも現象が発生しました。
また、Google 日本語入力をインストールして確認したところ、こちらでも同じ現象が発生しました。
なお、PowerToysのKeyboard Managerなど、キーボード操作を補助・変更するアプリは使用していません。
Mery: 3.8.9 (x64)
Onigmo: 6.2.0
C/Migemo: 1.3
Tidy: 5.8.0
Hunspell: 1.7.1
uchardet: 0.0.8
QuickJS: 0.16.2
アウトライン: 3.2.5 (Outline.dll)
Markdown プレビュー: 1.0.7 (MarkdownPreview.dll)
OS: Windows 11 (Version 25H2, OS Build 26200.9457, 64-bit Edition)| MSY-07 | 返信 - 「Zen モード」：
-
こんばんは、ご報告ありがとうございます。
> 以前の「Linuxでの動作報告（とバグ報告）」で、Kuroさんの環境でも同様の現象をご確認されていたと思いますが、改めてご確認いただけると幸いです。
こちらの環境では、Windows PC では現象を確認できていません。
以前のスレッドでは、こちらからもいくつか確認したいことがあり質問していたのですが、その後、追加の情報をいただけていない状態でした。そのため、こちらではまだ現象を再現できていませんでした。
今回、詳しい発生状況や環境について情報をいただけたので、とても助かります。
ただ、まずはこちらからもいくつか確認させてください。
以前のご報告から、こちらでは「Linux 上で Wine を使って Mery を動かした場合に発生する現象」と認識しているのですが、今回ご報告いただいた現象は、Windows 上で Mery を実行している場合のものでしょうか？
また、
> 現時点では、再現方法の一つとして、MeryのPluginsフォルダーに「Markdown プレビュー プラグイン」を追加したり削除したりした後、Meryを起動してIMEをONにすると現象が発生することがあります。
こちらは「Markdown プレビュー」プラグインで合っていますでしょうか？
もし「Markdown バー」プラグインのことであれば、こちらにはショートカットキーを上書きする機能があります。
たとえば、プラグイン側で Ctrl + K を割り当てた場合、Mery 本体側でも 2 ストロークキーの最初のキーとして Ctrl + K が設定されていても、プラグイン側が優先されるため、仕様上、Mery 本体の 2 ストロークキーは発動できなくなります。
また、「Markdown プレビュー」や「アウトライン」など、別のペインにフォーカスがある場合は、そもそも Mery 本体側のショートカットキーは動作しません。
> また、一度この現象が発生すると、別のポータブル版やインストーラー版のMeryでも同様の現象が発生します。
とのことですが、こちらは「Mery を再起動しても現象が続く」という意味でしょうか？
もしそうであれば、Mery 側では特に IME の状態を保存したり、IME の挙動を書き換えたりするような仕様はありませんので、Mery の設定や導入しているプラグインなど、Mery の実行環境に依存する要因がないか確認する必要がありそうです。
また、「Markdown プレビュー」を導入しているときにしか発生しない、ということであれば、プラグインの影響である可能性も考えられます。
まずは、プラグインなどを導入していないクリーンなポータブル版でも同じ現象が発生するか、ご確認いただけると参考になります。
| Kuro | 返信 -
ご返信ありがとうございます。
> 以前のご報告から、こちらでは「Linux 上で Wine を使って Mery を動かした場合に発生する現象」と認識しているのですが、今回ご報告いただいた現象は、Windows 上で Mery を実行している場合のものでしょうか？
はい、今回ご報告した現象は、Windows 上で Mery を実行している場合に発生したものです。
> こちらは「Markdown プレビュー」プラグインで合っていますでしょうか？
はい、「Markdown プレビュー」プラグインで合っています。
ただ、これまで何度か「Markdown プレビュー」プラグインを追加・削除して確認しましたが、プラグインを追加したからといって、必ず現象が発生するわけではありませんでした。
> また、「Markdown プレビュー」や「アウトライン」など、別のペインにフォーカスがある場合は、そもそも Mery 本体側のショートカットキーは動作しません。
「Markdown プレビュー」や「アウトライン」など、別のペインにフォーカスがない状態で試しましたが、それでも現象が発生しました。
> とのことですが、こちらは「Mery を再起動しても現象が続く」という意味でしょうか？
はい、「Mery を再起動しても現象が続く」という意味です。
> また、「Markdown プレビュー」を導入しているときにしか発生しない、ということであれば、プラグインの影響である可能性も考えられます。
>
> まずは、プラグインなどを導入していないクリーンなポータブル版でも同じ現象が発生するか、ご確認いただけると参考になります。プラグインなどを導入していないクリーンなポータブル版でも確認してみました。
Mery を起動した直後で、まだ設定を変更していない状態では現象は発生しませんでしたが、オプション画面で設定を変更すると、同じ現象が発生することがありました。
ただ、クリーンなポータブル版を複数用意して試してみたところ、オプション画面で設定を変更した場合でも、必ず現象が発生するわけではありませんでした。
| MSY-07 | 返信 -
本件に関係あるかわかりませんが、新しいMS-IMEとCopilotKeyboardはIMEをOFFにすることはできなくて、変換モードが直接入力に切り替わるだけです。
いつからなのか、大昔のナチュラル・インプット・モードのような挙動になっています。そのため、IME ON/OFFの判定方法では常に１が返ります。以前のMS-IMEではIME OFFでは０が返ります。
SendMessage(0x0283, 0x0005, 0,, hwnd)なので追加で、変換モードの判定方法で直接入力のかどうか（０または１６）を見る必要があります。
SendMessage(0x0283, 0x0001, 0,, hwnd)Google日本語入力は今はインストールしていないのですが、以前は設定次第だったと思います。
| enaka | 返信 -
>> MSY-07 さん、enaka さん
情報ありがとうございます。
こちらでもクリーンなポータブル環境で検証してみましたが、現時点では現象を再現できていません。
試したのは、以下のようなケースです。
- オプション画面で設定を変更
- Markdown プレビュープラグインを導入・削除
- MS-IME、Google 日本語入力、Copilot Keyboard で確認
- プラグインを多数導入した環境でも確認
これらを何度か繰り返してみましたが、こちらの環境では一度も現象は発生しませんでした。
オプション画面で変更する項目については特に指定されていなかったため、いくつか適当な項目を変更して確認しています。
そのため、現時点では原因を特定できていないのですが、いくつか確認していただきたいことがあります。
「Mery を再起動しても現象が続く」について
特に気になっているのが、
「Mery を再起動しても現象が続く」
という部分です。
これは、
- 一度現象が発生すると、その後は 2 ストロークキーが常に効かなくなる
という意味でしょうか？
それとも、
- 2 ストロークキーが効いたり効かなかったりする状態が、その後も続く
という意味でしょうか？
もし後者であれば、以下のようなケースも考えられます。
Ctrl + K を押したタイミングによる可能性
Ctrl + Kは、一度入力すると次のキー入力を待機する状態になります。たとえば、一度
Ctrl + Kを押したあと、「ちゃんと押せたかな？」と思ってもう一度Ctrl + K → Zと入力しても、Zen モードは発動しません。この場合は、最初の
Ctrl + Kがまだ有効な状態なので、Ctrl + K → Ctrl + Kという 2 ストロークとして認識されるためです。
Ctrl + K → Zが正しく入力されていない可能性デフォルトでは、Zen モードのキー割り当ては
Ctrl + K → Zです。この場合、
Ctrlキーを押しっぱなしにしたままK → Zと入力すると動作しません。Ctrl + K → Ctrl + Zという 2 ストロークとして認識されるためです。
日本語入力中は動作しません
日本語入力の途中で、まだ文字を確定していない状態では、2 ストロークキーは動作しません。
日本語入力を確定してから実行してみてください。
Ctrl + Kがタイムアウトしている可能性1 番目のキーを押してから、次のキーを入力するまでの待機時間は 5 秒です。
タイムアウトした場合は、もう一度 1 番目のキーから入力する必要があります。
また、1 番目のキーを押してから 1.5 秒ほど待つと、ステータスバー (左下) に 1 番目のキー
[Ctrl + K]が表示されます。この表示が消えている場合は、タイムアウトしています。
他のアプリとの干渉
1 番目のキーを入力したあとに Mery のウィンドウが非アクティブになった場合、2 ストロークキーの入力は解除されます。
また、
Ctrl + Kが他のアプリのホットキーなどに割り当てられている場合は、そちらに入力が奪われる可能性もあります。追加で確認していただきたいこと
もし 2 ストロークキーが受け付けられない状態になった場合は、まず
Ctrl + Kを押してから 1.5 秒ほど待ち、ステータスバー (左下) を確認してみてください。Ctrl + Kを入力すると、正常に受け付けられている場合は、ステータスバーに[Ctrl + K]と表示されます。ここが表示されるのであれば、少なくとも 1 番目のキーは Mery まで届いています。
また、可能であれば、2 ストロークキーが動作しない状態のときに、2 ストロークキーを使用する別のアプリでも同様の現象が発生するか確認していただけると、IME 側の問題なのか、Mery 側の問題なのかを切り分ける手掛かりになるかもしれません。
…ということで、現時点でこちらからお願いできる確認はこのあたりになります。
お手数をおかけしますが、検証にご協力いただけるようでしたら、確認してみてください。
| Kuro | 返信 -
ご返信ありがとうございます。
> オプション画面で変更する項目については特に指定されていなかったため、いくつか適当な項目を変更して確認しています。
オプション画面のどの項目を変更すると現象が発生するのかを再現しようとしたのですが、うまく再現できなかったため、具体的な項目は指定していませんでした。
> 「Mery を再起動しても現象が続く」について
これは「一度現象が発生すると、その後は 2 ストロークキーが常に効かなくなる」という意味です。
> もし 2 ストロークキーが受け付けられない状態になった場合は、まず
Ctrl + Kを押してから 1.5 秒ほど待ち、ステータスバー (左下) を確認してみてください。
>
>Ctrl + Kを入力すると、正常に受け付けられている場合は、ステータスバーに[Ctrl + K]と表示されます。
>
> ここが表示されるのであれば、少なくとも 1 番目のキーは Mery まで届いています。Ctrl + Kを入力してから 1.5 秒ほど経過すると、ステータスバーに[Ctrl + K]と表示されることには気づいていませんでした。そこで、2 ストロークキーが動作しない状態のときに、IME を ON にして
Ctrl + Kを入力して確認してみました。その結果、ステータスバーに
[Ctrl + K]と表示されました。このことから、少なくとも IME が ON の状態でも、1 番目のキーである
Ctrl + Kは Mery まで届いているようです。> また、可能であれば、2 ストロークキーが動作しない状態のときに、2 ストロークキーを使用する別のアプリでも同様の現象が発生するか確認していただけると、IME 側の問題なのか、Mery 側の問題なのかを切り分ける手掛かりになるかもしれません。
Mery で 2 ストロークキーが動作しない状態のときに、VSCode と Sublime Text でも下記のショートカットを確認しましたが、現象は発生しませんでした。
- VSCode
- 「Zen モード」：
Ctrl + K, Z - 「編集モードの選択」：
Ctrl + K, M
- 「Zen モード」：
- Sublime Text
- 「大文字に変換」：
Ctrl + K, Ctrl + U - 「小文字に変換」：
Ctrl + K, Ctrl + L
- 「大文字に変換」：
ちなみに、Mery には「Zen モード」(
Ctrl + K, Z) と「編集モードの選択」(Ctrl + K, M) 以外にも、下記の2 ストロークキーのショートカットがあることを最近知りました。- 「大文字に変換」：
Ctrl + K, Ctrl + U - 「小文字に変換」：
Ctrl + K, Ctrl + L - 「ドキュメントの整形」：
Ctrl + K, Ctrl + D - 「キーボード マップ」：
Ctrl + K, Ctrl + R
そこで、こちらも確認してみたところ、現象は発生しませんでした。
この結果を見ると、2 番目に入力するキーの種類によっては、IME が ON の状態でもキーが Mery まで届く可能性があるのかもしれません。
そのため、今回の現象は「IME が ON だと 2 ストロークキー全般が動作しない」というよりも、特定の 2 番目のキーを入力した場合に発生している可能性もありそうです。
| MSY-07 | 返信 - VSCode
-
> オプション画面で変更する項目については特に指定されていなかったため、いくつか適当な項目を変更して確認しています。
ちなみに、実際に現象が発生したときは、オプション画面などで普段使用している項目を複数まとめて、一度に一通り変更していました。
そのため、参考になるかは分かりませんが、現象が発生したときの「全部入り」の設定内容を報告いたします。
事前設定
- メニュー バーを右クリック
- [マクロ バー] - [ON]
- [プラグイン バー] - [ON]
マクロ
- [マクロ] - [カスタマイズ] - [マクロを全選択] - [削除]
- [MeryToys.js] を開いて [マクロ] - [これを選択]
プラグイン
- [ツール] - [プラグイン] - [1 アウトライン] - [ON]
オプション画面
- [基本]
- [折り返し方法] - [ウィンドウの右端で折り返し]
- [ルーラーを表示する] - [OFF]
- [リンクを開く] - [ON] - [Ctrl + クリック]
- [カラー コードを開く] - [OFF] - [Ctrl + クリック]
- [タブ/インデント]
- [折り返しインデント] - [ON]
- [追加のインデント文字] - [-[x]]
- [箇条書きのインデント幅を自動調整する] - [ON]
- [折り返しインデント] - [ON]
- [表示]
- [フォント] - [サイズ] - [12]
- [詳細] - [折り返しを超えて強調表示する] - [ON]
- [DirectWrite]
- [DirectWrite を有効にする] - [ON]
- [記号]
- [改行の表示] - [OFF]
- [EOF の表示] - [OFF]
- [折り返し線を表示する] - [OFF]
- [スクロール]
- [オーバー スクロール] - [半ページ]
- [スクロール マージン] - [0]
- [タブ]
- [閉じるボタン] - [すべてのタブの上]
- [ダーティ インジケーターをドットで表示する] - [ON]
- [マウス ホイールでタブを選択する] - [OFF]
- [タブを左揃えにする] - [ON]
- [アクティブなタブを強調表示する] - [ON]
- [色の指定] - [基本色] - [右下にある白]
- [ウィンドウ]
- [タイトル バーとウィンドウの境界線を強調表示する] - [ON]
- [自動保存]
- [ワークスペース] - [ワークスペースを保存、復元する] - [ON]
隠しオプション（MeryToys.jsで設定）
- [基本]
- [従来のルーラーを使用する] - [false]
- [Ctrl + ホイールでフォント サイズを変更] - [false]
- [ファイル]
- [無題の文書に連番を付ける] - [false]
- [非アクティブ時フルパスにしない] - [false]
- [表示]
- [Zen モード]
- [行番号を非表示] - [false]
- [ルーラーを非表示"] - [false]
- [記号を非表示] - [false]
- [文字数を非表示] - [false]
- [Zen モード]
| MSY-07 | 返信 - メニュー バーを右クリック
-
ご確認いただきありがとうございます。また、設定内容についてもご報告ありがとうございます。
> このことから、少なくとも IME が ON の状態でも、1 番目のキーである Ctrl + K は Mery まで届いているようです。
なるほど、これは大きな手掛かりです。
こちらの環境ですと、いまだに現象が再現できていないのですが、その情報と、「Mery を再起動しても現象が続く」という情報から、ひとつ仮説ができました。
以下、推測も含みますが、内部で起きている可能性についてご説明します。ちょっと長くなりますが…😅
2ストローク目で何が起きているか
まず、Ctrl + K を受け付けた時点で、Mery は正常に 2 ストローク目の待機状態 (chord モード) に入っています。
問題は、IME が ON の状態で Z などを入力した瞬間です。
IME が ON の場合、Windows の仕様により、アプリには「Z が押された」という直接の情報ではなく、「IME がキーを処理中 (VK_PROCESSKEY)」という特殊なメッセージが届く場合があります。
そのため Mery では、Windows から「現在のキーボードの状態 (どのキーが押されているかの一覧)」を取得し、キーコードを順番に走査することで、実際に押されたキーを推測・特定する処理を行っていました。
なぜキーの認識に失敗するのか
この探索処理では、キーコードを 0 ～ 255 まで順番にチェックしています。
ところが、実はこの中にはキーボードのキーだけでなく、VK_LBUTTON (マウスの左ボタン) や VK_RBUTTON (マウスの右ボタン) なども含まれています。
もし何らかの拍子に、OS のキーボード状態テーブル上で Z より小さいキーコードの押下状態 (Down フラグ) が残ってしまうと、Z (コード番号 90) に到達する前にそちらが見つかり、「2 ストローク目のキー」として誤認してしまう可能性があります。
その結果、該当するショートカットが存在しないと判定され、chord モードが終了してしまう、というわけです。
なぜ Mery を再起動しても直らないのか
この点について、キーボード状態を取得するだけの簡単なテストアプリを作って確認してみました。
たとえば、別のアプリをアクティブにして Shift キーを押しても、当然、テストアプリ側のキーボード状態は変化しません。
ところが、Shift キーを押しっぱなしにした状態でテストアプリの上にマウスカーソルを移動すると、テストアプリは非アクティブで何も操作していないにもかかわらず、キーボードの状態が更新され、Shift キーが押されている状態として取得されました。
このことから、Windows の入力管理では、OS 全体の入力状態と各アプリ側で取得できるキーボード状態との間に何らかの同期の仕組みがあるのではないか、と推測しています。
(もちろん、Mery 側で OS レベルのキーボード状態を書き換えたりしているわけではありません)
そう仮定すると、IME や他のアプリ、あるいは何らかの原因によってキーの解放状態が正しく反映されないような状況が発生した場合、Mery を再起動しても、その状態を再び取得してしまう可能性があります。
これが、「Mery の再起動では直らず、PC を再起動すると直る」という現象につながっているのではないか、と推測しています。
今後の対応について
この仮説が正しければ、「キーボード状態テーブルを総当たりして 2 ストローク目を推測する」という従来の実装をやめることで、根本的に回避できる可能性があります。
具体的には、IME によって VK_PROCESSKEY になった場合でも、本来の入力キーを取得できる公式 API (ImmGetVirtualKey) があります。
とはいえ、これが Windows 10 の特定のバージョンではバグがあったりして、10/11 あたりの新しい IME との相性も心配だったため、現在の実装にしたという経緯があります。
また、自力で押されたキーを解析するという力技もあるのですが、そちらの方法だと、テンキーやメディアキーなどへの対応が困難という問題もあります。
そういうわけで、ひとまず別の方式で実装して、本当に問題が解決するかどうかだけは確認してみたいところです。
もし今回の現象の決定的な再現方法がわかりましたら、教えていただけると助かります。
こちらでも別の方式について検討してみますが、そもそも現象が再現しないため、もしかするとテスト版をリリースして、検証にご協力をお願いするかたちを取らせていただくことになるかもしれません。
その際は、ご協力いただけると幸いです。
| Kuro | 返信 -
ご返信ありがとうございます。
> もし今回の現象の決定的な再現方法がわかりましたら、教えていただけると助かります。
現時点では、なかなか現象を再現できていませんが、再現方法が分かりましたら、改めてご報告いたします。
> こちらでも別の方式について検討してみますが、そもそも現象が再現しないため、もしかするとテスト版をリリースして、検証にご協力をお願いするかたちを取らせていただくことになるかもしれません。
テスト版をリリースされることになりましたら、こちらでも検証にご協力いたします。
引き続き、よろしくお願いいたします。
| MSY-07 | 返信 -
引き続き現象の再現方法を探していたところ、下記の手順で私の環境では100%再現することが確認できました。
- テキストエディター「Mery」ベータ版 v3.8.9 を公開から「Mery v3.8.9 (64 ビット版) ポータブル」をデスクトップフォルダーにダウンロードし、ZIPファイルを展開する
- 【雑談】Markdown プラグインで遊ぼうから「Markdown プレビュー プラグイン Ver 1.0.7 (64 ビット版)」をダウンロードしてZIPファイルを展開し、「C:\Users\xxxx\Desktop\MeryPortable-x64-3.8.9\Mery\Plugins」フォルダーに「MarkdownPreview.dll」を追加する
- 「C:\Users\xxxx\Desktop\MeryPortable-x64-3.8.9\Mery」フォルダーにある「Mery.exe」をダブルクリックしてMeryを起動する
- Meryの起動後、IMEをONにしてから
Ctrl+K, Zを入力する
なお、ほかのプラグインについても確認したところ、下記のプラグインでも同じ現象が発生しました。
- 半透明プラグイン (AlphaBlend.dll)
- 検索バー プラグイン (FindBar.dll)
- Web プレビュー プラグイン (WebPreview.dll)
| MSY-07 | 返信 -
ご報告ありがとうございます。
こちらの環境でも試してみましたが、残念ながら再現しませんでした。
というより、そもそも前回ご説明した仮説が正しいとすると、Mery 自体が原因ではない可能性も十分に考えられます。
つまり、別のアプリやマウス、キーボード関連のドライバ、Windows の特定の操作など、何らかのタイミングで、OS が持っているキーボード状態の情報に「特定のキーを離した」という情報が正しく反映されない状態になっている、という可能性です。
その状態になってしまうと、Mery を何度起動しても、また、どのバージョンの Mery であっても、起動するたびに OS のキーボード状態と同期されるため、その後は Mery を起動するたびに同じ現象が発生する、ということになります。
ちなみに、この現象が発生しない VS Code では、おそらく Chromium 系の実装になっていると思いますが、Chromium は内部的にキーボード状態テーブルをチェックするのではなく、自前で生の入力データからキーコードを解析するような処理になっているようでした。
そのため、OS 側のキーボード状態の影響を受けないのではないかと思います。
ということで、今回の現象については、いったん Mery 上での操作だけに絞らずに考えていただければと思います。
つまり、Mery で問題なく 2 ストロークキーが動いていた状態から、突然、動かなくなってしまった場合、その直前に行っていた操作についてです。
これは Mery 上での操作だけでなく、Windows の操作や、他のアプリの操作など、あらゆる可能性が考えられます。
たとえば、普段使用されている別のアプリが、何らかのタイミングでトリガーになっている可能性もありますので、そのあたりも含めて見ていただけると、何か手掛かりが見つかるかもしれません。
> テスト版をリリースされることになりましたら、こちらでも検証にご協力いたします。
ありがとうございます。その時はよろしくお願いいたします。
| Kuro | 返信 -
関係ない話題ですが、何かのヒントになるかもと思ったので投稿します。
ショートカットキーで快適な環境を構築するために、次の２つを利用しています。
・AutoHotkey
・AutoControl(chrome拡張機能)快適なのですが、何かの拍子に突然キーがきかなくなります。
これは当たり前のように起きる現象なので、もう諦めています。解決方法は、
・AutoHotkey 再読込
・AutoControl Emergency repair（リセットのようなもの）それでも直らない場合がたまにありますが、
何か日本語を入力して確定させると直る場合があります。
ＩＭＥの状態が中途半端なのを直す効果があるのかも知れません。的外れな話題でしたら申し訳ありません。
Mery の２段階ショートカットは利用していませんが、
もし使ってバグったとしても、AHK ユーザーなら自己責任と感じると思います。
そして上記の解決方法を試すと思います。| TN24 | 返信 -
>> Kuroさん
ご返信ありがとうございます。
> ということで、今回の現象については、いったん Mery 上での操作だけに絞らずに考えていただければと思います。
>
> つまり、Mery で問題なく 2 ストロークキーが動いていた状態から、突然、動かなくなってしまった場合、その直前に行っていた操作についてです。
>
> これは Mery 上での操作だけでなく、Windows の操作や、他のアプリの操作など、あらゆる可能性が考えられます。その後も調査したところ、エクスプローラーでタブを2つ以上開いている状態で、今回の現象が発生することを確認しました。
ご存じのとおり、Windows 11のエクスプローラーにはタブ機能が搭載されており、複数のフォルダーを1つのウィンドウ内で管理できます。
実は、以前私がPluginsフォルダーに「Markdown プレビュー」プラグインを追加した際も、エクスプローラーでタブを2つ以上開いている状態でした。そのため、この条件が現象の発生に関係していたのではないかと思います。
一方、エクスプローラーでタブを1つしか開いていない状態では、Pluginsフォルダーに「Markdown プレビュー」プラグインを追加しても、現象は発生しませんでした。
そこで、確認のため再度調査したところ、下記の手順で現象を再現できました。
- テキストエディター「Mery」ベータ版 v3.8.9 を公開から「Mery v3.8.9 (64 ビット版) ポータブル」をデスクトップフォルダーにダウンロードし、ZIPファイルを展開する。
- 「C:\Users\xxxx\Desktop\MeryPortable-x64-3.8.9\Mery」フォルダーを開く。
- 「Mery」フォルダーだけを開いている状態で、以下のいずれかの方法を実行する。
- もう1つ別のフォルダーを別ウィンドウで開き、「Mery」フォルダーのタブにドラッグ＆ドロップして、2つのタブが並んだ状態にする。
- 「Mery」フォルダーにフォーカスがある状態で
Ctrl+Tを押して新しいタブを追加し、そのタブを分離して別ウィンドウとして表示する。
- 「Mery.exe」をダブルクリックしてMeryを起動する。
- MeryでIMEをONにした状態で
Ctrl+K, Zを入力する。
>> TN24さん
> ショートカットキーで快適な環境を構築するために、次の２つを利用しています。
> ・AutoHotkey
> ・AutoControl(chrome拡張機能)情報ありがとうございます。
申し訳ありませんが、私の環境では「AutoHotkey」と「AutoControl」はインストールしていません。
| MSY-07 | 返信 -
>> MSY-07 さん、TN24 さん
TN24 さん、情報ありがとうございます。
いえいえ、今回の件と直接関係があるかどうかはまだ分かりませんが、とても参考になります。
特に「何かの拍子にキーが効かなくなり、日本語を入力して確定すると直ることがある」というのは興味深いですね。
ただ、MSY-07 さんの環境では、キーボード操作の補助といったソフトは導入されていないとのことでしたので、今回の件の原因とはまた別かもしれません。
こちらでも引き続き調査していますが、現象はまだ再現できていない状態です。
そこで、テスト用の Mery プラグインを作ってみましたので、こちらを試していただけないでしょうか？
テスト プラグイン (64 ビット版) [622,831 バイト 2026/09/21]
https://www.haijin-boys.com/download/CustomBar.zip
ウイルスチェック: https://www.virustotal.com/#/file/6fe07c232994e603fae02fc9407095c4a709f18d6060156bde3891ff614fc069
解凍すると
CustomBar.dllが出てきますので、Mery ポータブル版 (64 ビット) のPluginsフォルダーに配置してください。その後、[ツール] → [プラグイン] → [GetKeyboardState チェック] をクリックすると、カスタムバーが表示されます。
そこには、
GetKeyboardStateで「押されている状態」として認識されているキーのコードが表示されます。今回の例では
Zキーが 90 番なので、現象が発生している状態で、90 より小さい数値が表示され続けていないかをご確認いただけますでしょうか。もし 90 より小さい数値が表示されている場合は、何らかの原因で、そのキーが押されたままの状態として認識されている可能性があります。
なお、マウスのクリックやキー入力などの操作を行うと、それに反応して表示される数値が変化しますが、そこは気にしなくて大丈夫です。
お手数をおかけしますが、よろしくお願いいたします。
| Kuro | 返信 -
>> MSY-07 さん
あらら、投稿のタイミングがかぶってしまいましたね😅
情報ありがとうございます。
ちょっとこれから夕飯の支度があるので、いただいた手順については、後ほど確認させていただきたいと思います。
| Kuro | 返信 -
ご返信ありがとうございます。
> 今回の例では
Zキーが 90 番なので、現象が発生している状態で、90 より小さい数値が表示され続けていないかをご確認いただけますでしょうか。
>
> もし 90 より小さい数値が表示されている場合は、何らかの原因で、そのキーが押されたままの状態として認識されている可能性があります。テスト プラグインを導入し、現象が発生している状態で確認したところ、「90」より小さい数値として「0」が表示されました。
ご指摘のとおり、何らかのキーが押されたままの状態として認識されている可能性がありそうです。
> ちょっとこれから夕飯の支度があるので、いただいた手順については、後ほど確認させていただきたいと思います。
承知いたしました。お時間のあるときにご確認いただければと思います。
| MSY-07 | 返信 -
ご報告ありがとうございます。
> テスト プラグインを導入し、現象が発生している状態で確認したところ、「90」より小さい数値として「0」が表示されました。
テストプラグインでの検証にもご協力いただき、ありがとうございます。
おかげさまで、原因を特定することができました。
> もう1つ別のフォルダーを別ウィンドウで開き、「Mery」フォルダーのタブにドラッグ＆ドロップして、2つのタブが並んだ状態にする。
いただいた手順で、こちらでも現象を再現できました。エクスプローラーのタブ機能は使ったことがなかったもので😅
それから、テストプラグインを起動した状態で同様の操作を行ったところ、
Ctrl + Tなどは特に関係ないようで、- エクスプローラーを 2 つ開く
- 片方のタブをドラッグする
- もう一方のタブの横にドロップする
という操作だけで、通常のキー入力には使用されないキーコード 0 が、常に押された状態になることが確認できました。
そのため、Mery で現在押されているキーをチェックする際に、キーコード 0 ～ 255 を順番にチェックしているのですが、最初にキーコード 0 がヒットしてしまい、Z (90) が検出されない、という状況になっているようです。
しかも、Windows を再起動するまでキーコード 0 が押された状態のままになるようで、エクスプローラーのタブを閉じても、エクスプローラーを再起動しても直りませんでした。
これが、Mery を再起動しても直らない原因だったようです。
どうやら、Windows の不具合である可能性が高そうですね。
そういうわけで、対策をどうするかですが…
現状の仕様を変更せずに対応するのであれば、キーコード 0 のチェックを飛ばすだけでも大丈夫そうです。
ただ、今回のような Windows 側の不具合があることを考えると、TN24 さんがおっしゃっていた AutoHotkey 関連の現象など、別の要因によって同じような問題が発生する可能性もありそうです。
そこで、こちらでも調べていた別の実装方法をもう少し検証しまして、複数の方法を組み合わせてキーコードを検出するような、より安全なロジックにできないか検討してみたいと思います。
| Kuro | 返信 -
>通常のキー入力には使用されないキーコード 0 が、常に押された状態になることが確認できました。
2026年6月の定例パッチで入り込んだバグみたいですね。
https://www.bleepingcomputer.com/forums/t/816748/windows-explorer-tabs-not-allowing-drag-drop/自分はタブもリボンもないWindows7時代の旧エクスプローラーに戻して使っているためか、バグを再現できませんでした。
>しかも、Windows を再起動するまでキーコード 0 が押された状態のままになるようで、エクスプローラーのタブを閉じても、エクスプローラーを再起動しても直りませんでした
AutoHotkeyなどでキーコード0のUpを送信したら直るでしょうか。
#0:: Send("{vk00 up}")| enaka | 返信 -
ご返信ありがとうございます。
> いただいた手順で、こちらでも現象を再現できました。エクスプローラーのタブ機能は使ったことがなかったもので😅
Kuroさんの環境でも現象を再現できたようで、とりあえずほっとしました😓
> 現状の仕様を変更せずに対応するのであれば、キーコード 0 のチェックを飛ばすだけでも大丈夫そうです。
>
> ただ、今回のような Windows 側の不具合があることを考えると、TN24 さんがおっしゃっていた AutoHotkey 関連の現象など、別の要因によって同じような問題が発生する可能性もありそうです。確かに、今回の Windows 側の不具合に限らず、別の要因によって同様の問題が発生する可能性はありそうですね。
> そこで、こちらでも調べていた別の実装方法をもう少し検証しまして、複数の方法を組み合わせてキーコードを検出するような、より安全なロジックにできないか検討してみたいと思います。
ありがとうございます。
より安全な方法を検討していただけるとのことで、よろしくお願いいたします。| MSY-07 | 返信 -
ご返信ありがとうございます。
>> enaka さん
> 2026年6月の定例パッチで入り込んだバグみたいですね。
情報ありがとうございます。
ご紹介いただいたサイトも確認してみました。
確かに、エクスプローラーのタブをドラッグ＆ドロップすると発生するという点では、今回の現象に似ているところがありますね。
> AutoHotkeyなどでキーコード0のUpを送信したら直るでしょうか。
それができれば、PC を再起動しなくても回避できるので良さそうですね。
Send("{vk00 up}")の前後にチェックロジックを追加して試してみましたが、Send("{vk00 up}")の直後はvk00がオフになるものの、すぐにオンに戻ってしまうようで、アプリ側からの操作では効果がないようです。強制的に
vk00をオフにするコードを Delphi で実行して試してみても、テストアプリからフォーカスが外れた瞬間にvk00が復活してしまいますね😨それから、新しいロジックに置き換えるにあたって、各種 IME での検証用 PC が必要になるので、試しに 2026年3月版の Windows 11 (25H2 Build 26200.8037) をインストールして確認してみたところ、その時点ですでに現象は発生していました。
ただ、そちらでは現行の Windows 11 では発生しない問題も抱えているようで、エクスプローラーの不具合は VK00 問題だけでなく、キーボード状態テーブル全体が吹き飛んだり、タブのドラッグができなくなったり、マウスカーソルが消失したりと、いろいろな問題が発生しました。
なので、以前から潜在的に眠っていた問題なのかもしれません。
それから、これは現行の Windows 11 でも確認できたのですが、UAC (何かをインストールしたりする直前に表示される、画面全体が暗くなるやつ) が出ると、VK00 の押下状態が解除されるみたいです。
また、UAC の後は、しばらくの間はタブをドロップしたりしても VK00 問題が発生しなくなるようです。謎すぎ…
というわけで、これを利用して、デスクトップ上に適当なインストーラーを置いておいて、問題が発生したらそれをダブルクリック → UAC → キャンセル、で直すという力技😂
>> MSY-07 さん
> Kuroさんの環境でも現象を再現できたようで、とりあえずほっとしました😓
お手数をおかけしました。そして、ご協力ありがとうございました。
エクスプローラーのタブを使うという習慣がないもので、教えていただけなかったら、きっと永遠に原因はわからなかったと思います😅
> 確かに、今回の Windows 側の不具合に限らず、別の要因によって同様の問題が発生する可能性はありそうですね。
OS レベルでキーボード状態テーブルが壊れるというのは、さすがに普通のアプリでは考えにくいところではありますが、昔のソフトだと、本体を自動スリープさせないためにキーコード 0 を送り続ける、といったものもあるみたいですね。
> より安全な方法を検討していただけるとのことで、よろしくお願いいたします。
はい。とはいえ、IME レベルでの追加実装が必要になるので、検証には時間がかかりそうですね…
今のところ、メインの環境では新しい実装で動いていますが、Windows XP あたりが心配なのと、ATOK が対応しているかがちょっと怪しいところです。
もしかすると、「やはりダメでした」というご報告になってしまう可能性もありますが、がんばってみます。
検証にご協力いただき、本当にありがとうございました。
| Kuro | 返信 -
> 強制的に `vk00` をオフにするコードを Delphi で実行して試してみても、テストアプリからフォーカスが外れた瞬間に `vk00` が復活してしまいますね😨
恐らくドラッグ動作をきっかけに、マウスドライバかそれに近い下層の何かのバッファが溢れて、キーボードドライバの状態テーブルやバッファを上書きし、"{vk00 down}" を送り続けているということですかね。
ALPSやSynaptics などのサードパーティーのドライバだとどうなるんでしょう。どちらも今はOnSemiなのか。> それから、これは現行の Windows 11 でも確認できたのですが、UAC (何かをインストールしたりする直前に表示される、画面全体が暗くなるやつ) が出ると、VK00 の押下状態が解除されるみたいです。
UACにより上記が初期化されるということですかね。サスペンドやハイバネートからの復帰だとどうなるんでしょう。
Windows11のカスタムテーマでカラー変更していても、復帰後はデフォルトテーマのカラーで強制初期化されたりしますので。最近はマウスカーソルまで。> また、UAC の後は、しばらくの間はタブをドロップしたりしても VK00 問題が発生しなくなるようです。謎すぎ…
上記のバッファが再確保されて余裕が出来るため、再び溢れるまで発生しないということですかね。
> というわけで、これを利用して、デスクトップ上に適当なインストーラーを置いておいて、問題が発生したらそれをダブルクリック → UAC → キャンセル、で直すという力技😂
"sudo cmd /C" のショートカットなら、うっかりキャンセルし損ねてインストールする心配がないので安全かも。
> OS レベルでキーボード状態テーブルが壊れるというのは、さすがに普通のアプリでは考えにくいところではありますが、昔のソフトだと、本体を自動スリープさせないためにキーコード 0 を送り続ける、といったものもあるみたいですね。
ありましたね。抜本的解決に時間がかかるようであれば、キーコードを255から逆順に検索するなど、暫定回避でお茶を濁すのもありかもしれません。
| enaka | 返信 -
ご返信ありがとうございます。
> それから、これは現行の Windows 11 でも確認できたのですが、UAC (何かをインストールしたりする直前に表示される、画面全体が暗くなるやつ) が出ると、VK00 の押下状態が解除されるみたいです。
>
> また、UAC の後は、しばらくの間はタブをドロップしたりしても VK00 問題が発生しなくなるようです。謎すぎ…
>
> というわけで、これを利用して、デスクトップ上に適当なインストーラーを置いておいて、問題が発生したらそれをダブルクリック → UAC → キャンセル、で直すという力技😂7-Zipのインストーラーを用意して、上記の方法を試してみました。
確かに、UACを表示してキャンセルすると、その後しばらくの間は、タブをドロップしてもVK00問題が発生しなくなりますね。
> お手数をおかけしました。そして、ご協力ありがとうございました。
>
> エクスプローラーのタブを使うという習慣がないもので、教えていただけなかったら、きっと永遠に原因はわからなかったと思います😅こちらこそ、お手数をおかけしました。
Kuroさんにいろいろとご協力いただいたおかげで、最終的に、エクスプローラーのタブ機能が今回の現象の発生原因であることを突き止めることができました。
自分だけでは、なかなか原因にたどり着けなかったと思いますので、本当に助かりました。
> 今のところ、メインの環境では新しい実装で動いていますが、Windows XP あたりが心配なのと、ATOK が対応しているかがちょっと怪しいところです。
>
> もしかすると、「やはりダメでした」というご報告になってしまう可能性もありますが、がんばってみます。ぜひ、良いご報告をお待ちしております😊
| MSY-07 | 返信 -
MSY-07 さん、enaka さん、ご返信ありがとうございます。
>> enaka さん
> 恐らくドラッグ動作をきっかけに、マウスドライバかそれに近い下層の何かのバッファが溢れて、キーボードドライバの状態テーブルやバッファを上書きし、"{vk00 down}" を送り続けているということですかね。
その可能性は高そうですね。
Windows API では、GetKeyboardState でも GetKeyState でも VK00 が常に押下状態になっていることを確認できたので、API 周りの問題というより、OS のもう少し下のレベルで何かがおかしくなっているのだと思います。
> UACにより上記が初期化されるということですかね。サスペンドやハイバネートからの復帰だとどうなるんでしょう。
こちらも、どうやらそのようです。
たまたま検証中にお腹が痛くなって、しばらく離れて戻ってきたら PC がスリープになっていまして、復帰したら現象が改善されていました。
なので、スリープからの復帰でも何らかの初期化が行われているのだと思います。
> ありましたね。抜本的解決に時間がかかるようであれば、キーコードを255から逆順に検索するなど、暫定回避でお茶を濁すのもありかもしれません。
それも考えたのですが、私の環境では、どうも 240、244、246、251 あたりが何故か常にオンの状態になっているようで… (UAC が発動すると、それらもクリアされて、きれいな状態になるみたいですが🤔)
GetKeyboardState で現在押されているキーをチェックする方法は、基本的には Microsoft が想定している方法なので、これで問題ないだろうというのが前提だったのですが…
今回の件を考えると、やはり Mery のこの検出方式自体を見直したほうが良さそうかなと思っています。
>> MSY-07 さん
> 7-Zipのインストーラーを用意して、上記の方法を試してみました。
おっ😅
さすがに、Mery 的にその方法をオススメしているわけではないので、あくまで一時しのぎということでお願いします (笑)
> 確かに、UACを表示してキャンセルすると、その後しばらくの間は、タブをドロップしてもVK00問題が発生しなくなりますね。
そこ、謎なんですよね。
1 回だけ発生しなくなる、というのであればまだ分かるのですが、その後しばらくの間は安定して発生しなくなるので、何か別のトリガーがあるのか、ちょっと気になるところではあります。
ただ、そこから先は Windows のバグの領域ということで、今回はこれ以上の深追いはやめておこうと思います。
> Kuroさんにいろいろとご協力いただいたおかげで、最終的に、エクスプローラーのタブ機能が今回の現象の発生原因であることを突き止めることができました。
私も、別のアプリの影響までは考えましたが、まさか Windows のエクスプローラーのタブ機能までは想像が及びませんでした。
普段はそこまでしないのですが、今回は一応、Microsoft にフィードバックを送っておきました。
連休の 4 日間を Windows のバグ調査に費やしてしまうとは…とほほ。みなさんも、どうか残りの 1 日はごゆるりとお過ごしください😊
| Kuro | 返信 -
> それも考えたのですが、私の環境では、どうも 240、244、246、251 あたりが何故か常にオンの状態になっているようで…
この辺は、IMEがフックしたりトグル動作したりして、仮想キーコードだけでなくスキャンキーコードなども併せて確認しないと、押しているか状態が分からない、所謂ダメキーですね。
vkF0(240) Eisu/CapsLock vkF1(241) Shift + Katakana/Hiragana vkF2(242) Katakana/Hiragana vkF3(243) Hankaku/Zenkaku Toggle vkF4(244) Hankaku/Zenkaku Toggle vkF5(245) Alt (+ Shift or Ctrl) + Katakana/Hiragana Toggle vkF6(246) Alt (+ Shift or Ctrl) + Katakana/Hiragana Toggle vkF7(247) Ctrl + Alt (+ Shift) + NonConvert vkF8(248) Ctrl + Alt (+ Shift) + Hankaku/Zenkaku vkF9(249) None vkFA(250) Ctrl + Alt (+ Shift) + Eisu/CapsLock Toggle vkFB(251) Ctrl + Alt (+ Shift) + Eisu/CapsLock Toggle以下を参考にしました。
https://bsakatu.net/doc/virtual-key-of-windows/
https://bsakatu.net/doc/scancode/
https://bsakatu.net/doc/usb-hid-to-scancode/
https://bsakatu.net/doc/how-to-input-japanese-more-convinient-with-us-layout/#sc-and-vk| enaka | 返信 -
ご返信ありがとうございます。
> たまたま検証中にお腹が痛くなって、しばらく離れて戻ってきたら PC がスリープになっていまして、復帰したら現象が改善されていました。
>
> なので、スリープからの復帰でも何らかの初期化が行われているのだと思います。確かに、私の環境でもPCがスリープから復帰すると、現象が改善されました。
また、スリープだけでなく、PCをロックした場合や、休止状態・サインアウトから復帰した場合にも、同様に現象が改善されることを確認しました。
> それも考えたのですが、私の環境では、どうも 240、244、246、251 あたりが何故か常にオンの状態になっているようで… (UAC が発動すると、それらもクリアされて、きれいな状態になるみたいですが🤔)
確認してみたところ、私の環境でもいくつかの数値が常にオンの状態になっていました。
- IMEがオフ：240、243、246、251
- IMEがオン：242、244、246、251
> 普段はそこまでしないのですが、今回は一応、Microsoft にフィードバックを送っておきました。
Microsoftへのフィードバックまで送っていただき、ありがとうございます。
> 連休の 4 日間を Windows のバグ調査に費やしてしまうとは…とほほ。みなさんも、どうか残りの 1 日はごゆるりとお過ごしください😊
今回のフォーラムの件は、長くなりそうだなとは思っていたのですが、まさか現象の発生原因を特定するまでに4日間もかかるとは、さすがに想定外でした😓
Kuroさんも、どうか残りのお休みはごゆっくりお過ごしください😊
| MSY-07 | 返信 -
こんばんは。
皆さんのいろいろな作品のお世話になっています。
いつもありがとうございます。キーのフックについて、まったく関係がなかったり、既にご存じかもしれませんが、念のために書きました。
私の環境では、PowerToysが1.00 になったら、なぜか急に Keyboard Manager が使えなくなったので、
AutoHotKey 2.xで代わりになるか試しており、マニュアルによると、日本語のIMEと併用するためには、AutoHotKey 側でキー・フックをかける必要があるようなので、AutoHotKeyのスクリプトの最初の方に、コピペした以下のような部分を加えました。それでも安定性には難があると思いますが……
;; The keyboard hook must be installed to work with IME
InstallKeybdHook
SendSuppressedKeyUp(key) {
DllCall(“keybd_event”
, “char”, GetKeyVK(key)
, “char”, GetKeySC(key)
, “uint”, KEYEVENTF_KEYUP := 0x2
, “uptr”, KEY_BLOCK_THIS := 0xFFC3D450)
}| AHK | 返信 -
> キーのフックについて、まったく関係がなかったり、既にご存じかもしれませんが、念のために書きました。
これはAutoHotkeyが、USキーボードで修飾キー＋CapsLockを使うためにIMEのキーイベントを無効化するAutoHotkey関数です。
JPキーボードはCapsLockの単体キーがなくShift+英数なので特に使う意味はありません。
USキーボードでは、以下のように使います。~LAlt:: SendSuppressedKeyUp "LAlt" ;; IMEのAltショートカットを無効化 !CapsLock:: MsgBox("TEST") ;; Alt+CapsLockに割り当て| enaka | 返信
