内部の動作がよく分かりませんが、条件を外から見るとショートカットキーだからだと思われます。以下のすべてが該当するものと思われます。
Tera TermIDR_ACC ACCELERATORS
BEGIN
"T", ID_ACC_AREYOUTHERE, VIRTKEY, ALT, NOINVERT
"C", ID_ACC_COPY, VIRTKEY, ALT, NOINVERT
"Q", ID_ACC_EXIT, VIRTKEY, ALT, NOINVERT
"N", ID_ACC_NEWCONNECTION, VIRTKEY, ALT, NOINVERT
"V", ID_ACC_PASTE, VIRTKEY, ALT, NOINVERT
"R", ID_ACC_PASTECR, VIRTKEY, ALT, NOINVERT
"P", ID_ACC_PRINT, VIRTKEY, ALT, NOINVERT
"B", ID_ACC_SENDBREAK, VIRTKEY, ALT, NOINVERT
"G", ID_FILE_CYGWINCONNECTION, VIRTKEY, ALT, NOINVERT
"D", ID_FILE_DUPLICATESESSION, VIRTKEY, ALT, NOINVERT
"I", ID_ACC_DISCONNECT, VIRTKEY, ALT, NOINVERT
END
このキーの組み合わせは、他のウィンドウにも飛んでよいものでしょうか。分け方がこれでいいのか分かりませんが、ブロードキャスト送信されるのが「端末へのキー入力」なのか「ショートカットキーを含めた全てのキー操作」なのか、という疑問が発生します。
ID_ACC_SENDBREAK などに関しては、飛んだら困る場合もあると思われ、実際に飛んだら設定値のチェックを飛ばしてリモートに送信されそうです。
アクセラレータキーは WM_KEYDOWN や WM_SYSKEYDOWN ではなく、WM_COMMAND でメッセージ送信される ようです。
cf. http://eternalwindows.jp/winbase/menu/menu07.html
BroadcastEditProc()で WM_COMMAND も処理するようにすればよさそうです。 ただ、永田さんがおっしゃるような懸念事項があるので、そのまま素直にインプリしてしまってよいものかどうか。
選択肢としては、(1)自ウィンドウにも飛ばないようにする、(2)選択中の全ウィンドウに飛ばす、の2種類だと思います。
私の懸念事項については、受け側の VTWin でも Proc でも自分の設定値を見て通すかどうか決めるようにすればよいと思います。
私の感覚では、「端末への入力」を飛ばすものだと思っており、ブロードキャストのダイアログにいるのに VTWin に Alt-v などが飛ぶという動きを不自然に感じます。なので(1)のほうがよいと思います。
Note:現状でMetaキーはブロードキャスト送信されているようです。
Meta キーの設定も考慮すべきことに気付きました。今の挙動は以下の通りです。
※すべて操作は A 側 (1) A Meta=off B Meta=off A にのみアクセラレータキーが飛ぶ (2) A Meta=on B Meta=on 両方に Meta が飛ぶ (3) A Meta=off B Meta=on A にのみアクセラレータキーが飛ぶ (4) A Meta=on B Meta=off A に Meta が飛ぶ B にアクセラレータキーが飛ぶ
Meta が off の場合はアクセラレータキーとして食われてしまうのでよそに飛ぶことはありませんが、Meta だった場合にはよそに飛び、それを受け取った側ではアクセラレータキーとして動作しているようです。つまり、問題があるかもしれないと述べた現象はすでに (4) のパターンで発生していそうです。
CTeraApp::PreTranslateMessage で Meta をチェックしてアクセラレータキーになるかどうか分岐してますので、このために IDD_BROADCAST_DIALOG でもアクセラレータキーが効くものと思われます。
(4)のパターンは、メッセージ受け取り時に設定値をCVTWindow::OnCommandでチェックしているので問題ないようです。
リアルタイムモードを on にしたブロードキャスト送信で、Alt-v(貼り付け)が自プロセスにのみ送信される。