ds14050

xyOutlineDock=0,0,0,0 という設定値に問題がありそうです。 新しくアウトラインウィンドウが表示できないことから、 表示されているけど見えていない状態に陥っているような。 再現手順をなぞっても再現できなくなったときには、設定値は xyOutlineDock=312,217,312,217 のようになっていました(他は同じ)。 考えるべきはどのようにして 0,0,0,0 のような値が書き込まれたかでしょうか。

日本語キーボード(設定)では [;+], [:*] の刻印がある日本語キーボードのキーに対して仮想キーコード 187, 186 に対応するコマンドが TranslateAccelerator により送られてきます。英語キーボード(設定)では同じキーに対して 186, 222 の仮想キーコードに対応するコマンドが送られてきます(ちなみに 187 は [^~] の刻印があるキーに対応する)。 国により多様性があるキーボードのキーを、Unicode で文字を扱うように 256 種類の ID(※) で識別することはできないのでしょう。※CommonSetting_KeyBind.m_VKeyToKeyNameArr[] のサイズが 256+10。 現在の取り扱いに準じた対応としては、キー割り当ての設定に「^(英語')」「@(英語`)」とあるように、ラベルを「:(英語;)」にすることかなと思います。

「;(英語=)」もかな。

噛み合いませんね。仮想キーコードを介するアクセアレータキーの処理により、各言語キーボードに配された物理キーを識別することができています(※日本語キーボード(物理)で英語キーボード(設定)を利用すると[変換]キーと[カタひら]キーの識別ができませんが、これはあるはずのない余分なキーがあることによる例外的状況)。そして、日本語キーボードの [;+] キーと英語キーボードの [;:] の間に仮想キーコードの共通性が期待できないというのが今回の原因。そういう期待を抱かせないために、仮想キーコードにどう紛らわしくないラベルを貼り付けるかというのが課題。UI の多言語対応とは切り離されるべきキーボードの使い分けに関する問題で、でも現在は `STR_KEY_BIND_HAT_ENG_QT` や `STR_KEY_BIND_AT_ENG_BQ` という識別子に見られるようにおそらく UI の多言語対応とくっついてしまっている。その結果の苦肉の策が「^(英語')」「@(英語`)」という、日本語のラベルに付随する英語キーボードの刻印です。 人的リソース以外の理由で、現状に即した対応をせずに据え置きたい理由があるとは飲み込めません。

>見た目動いてそうな状態にできると思います。 見た目(キー割り当てのラベル)の修正提案ですから当然です。 そしてそこからですけれど、UI の多言語対応はこの問題と無関係だと考えていますが勘違いでしょうか。無関係の問題を持ち出して問題を大きくしているように感じます。 先のコメントで `STR_KEY_BIND_HAT_ENG_QT` という識別子を持ち出して UI の多言語対応と関連があるかのように書きましたが、その定義を確かめたところ `"^(英語')"` と `"^(EN KBD ')"` を切り替えるだけのものでした。「英語」と「EN KBD」を切り替えるだけでその内容は同じ。 仮想キーコードの下に物理キーコードというものがあることを自分は認識していませんでしたけれど、berryzplus さんは物理キーコードを読んで TranslateAccelerator に渡す前に独自に仮想キーコードに変換することを目論んでいるのでしょうか。これも先の見通しのない大きな問題を持ち出して、目前の小さな問題を先送りしているように感じます。 サクラエディタは日本語キーボードにしか対応していないのではないですか？ おそらく `VK_XXX` などと事前定義された以外の仮想キーコードを利用した時点でキーボード言語依存性が生じるでしょう。`STR_KEY_BIND_HAT_ENG_QT` と `STR_KEY_BIND_AT_ENG_BQ` がそうですし、`;` と `:` にも事前定義がありません。そしてキーボードの切り替えに対応して仮想キーコードをあれこれするコードは全くありませんよね？...

初めて話が噛み合った気がします。自分は MapVirtualKey 関数の存在を今初めて知りました。スキャンコードや物理キーコードについてもです。これが自分にとっての意義です。 > @ds14050 さん お願いできませんか？ これですが、卑怯と言われようとも自分はやるとは言いません。それは意欲と知識と問題意識のある人が新機能としてインプリメントするものであって、これまでのサクラエディタの延長にはなく、この Issue のスコープからも外れていると考えるからです。 報告者は「日付挿入ではなく」という表現で望む結果を示していますが、キーボード種別が区別できるようになったとして、日本語キーボードの [;+] キーと英語キーボードの [;:] キーなど、一部の記号キーをあえて同一視することにハック以上の必然性や合理性が見いだせるでしょうか(反語ではありませんが否定的に見ています)。 berryzplus さんの考える対策は、日本語キーボードと US ASCII 配列のキーボードのどちらかが使えるだけでは満足できない、典型的日本人からは外れる人達の使い勝手を改善する、根本的に正しい処理かもしれませんが、それは別の話です。

訂正。使い勝手が改善される対象は「典型的日本人からは外れる人達」ではありませんでした。(典型的日本人も含めて)複数種類のキーボードを切り替えて使う人達でした。

いつか何かの参考になるかなと置いていきます。 たとえばキーボードの切り替えによりコロンの入力方法が [：＊] キー単独入力から [Shift]+[；：] の２キー入力に変わったとします。そのとき [Alt]+[：＊] に割り当てられていた機能が [Alt]+[Shift]+[；：] へ割り付けられるように、仮想キーコードを変換の上アクセラレータテーブルに登録します。こういう変換です。 仮想キーコード@日本語キーボード → 記号文字 → 仮想キーコード@現在のキーボード キートップの文字 (+[Ctrl]) (+[Alt]) で呼び出される機能が決まるため、[Alt]+[；：] や [Alt]+[Shift]+[；：] の実行結果が予測可能なものになります。 また、キー割り当て画面の「^(英語')」「@(英語`)」という、実用的ではあるがアドホックな併記が無用のものになります。しかしこれは仕様変更を意味します。 「キー割り当て」の GUI が、日本語キーボードの配列が目の前にない人にとっては使いにくいものになりますが、(^ を Shift すると何になるんだっけ？)、これまでは日本語キーボードの使用を要求していたようなものなので、一概に悪くなったとは考えていません。 [translate_vkeycode.r1.txt](https://github.com/sakura-editor/sakura/files/2109498/translate_vkeycode.r1.txt)

Ctrl 対応というのが EXE 埋め込みの初期設定を変更することであれば特に意見はありません。 バージョンアップではエディタの使用に際して影響はありませんし、独自の設定を出すよりも長いものに巻かれておいたほうが覚えることが少なくて済みます。 コード上の変更点が静的データまわりに留まるので、先に Ctrl 対応をしたいという動機につながらず勘違いしているかもですが……。 提案１が実現しなければキーボード別に対応する手段がないので、提案２の Ctrl 対応はこういう結果にならざるをえません。 日本語キーボードの場合の挙動 Ctrl + ；　…　日付 Ctrl + ：　…　時刻 USキーボードの場合の挙動 Ctrl + ＾　…　日付 Ctrl +...

「Excel に合わせる」ということから Excel 英語版を除外せずに考えていましたが、それは参考情報で、Excel 日本語版が第一なんですね。それは納得できることです。自分の手元には参考画像を撮れるキーボードがありませんから。 こういう説明がありました>「[キーボードの同時押しについて - forPCActionGamer Wiki*](https://wikiwiki.jp/fpag/%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%81%AE%E5%90%8C%E6%99%82%E6%8A%BC%E3%81%97%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6)」 心配するほどのことではない気がしますし、修飾キーの組み合わせが認識できないようなキーボードは投げ捨てた方がいいでしょう。