窓使いの憂鬱とAutoHotkeyのどちらを今後使うべきか迷っております。

窓使いの憂鬱のソースコードのhook.cppというファイルでは、

CallNextHookExやSetWindowsHookExが使われています。

どうも、Windowの最大化、最小化、CAPSキー、NUMLOCKキー、KANAキー、IME制御などの処理をやってるっぽいです。

ということは、AHKと同レイヤの処理もやっているわけなんですかね？

また、AHKの手前でフックして、フックメソッドの返値を1にして、SendKeysメソッドで、アクティブなアプリに直接キーイベントを送ると、AHKを回避してキーイベントをそのアプリに送ることができました。

どうも、AHKの動作原理の詳細が、いまいちよく分かりません。

窓使いの憂鬱は、Windows Device ModelのUSBクラスドライバとHIDクラスドライバを正規のものとすげ替えて、乗っ取って、定義ファイル通りにキーの置き換えをやったあと、ファイルシステムドライバにわたしてるっぽい。

ファイルシステムドライバは、OSから呼び出されているわけだから、ようは、ハードウェアからの信号が、OSに認識される手前で、変換処理をかける方式っぽい。

この理解で合ってますでしょうか？

AHKは、SetWindowsHookExで、WH_MOUSE_LLとWH_KEYBOARD_LLをフックしている方式。

要するに、OSがメッセージをアプリに配送する手前で、引っかけて、処理をしている。

ということで、どうも、ぜんぜん別レイヤのように思えるのですが、

この理解で合ってますでしょうか？

ちなみに、調べていて、どうも理解できなかったところがあります。

.NETでSetWindowsHookExで、WH_MOUSE_LLとWH_KEYBOARD_LLをフックするサンプルプログラムを書いて、

二つのキーイベントフィルタを同時に走らせて、

どちらのフィルタも、CallNextHookExを呼ばないようにすると、最初に立ち上げた方のフックが効かなくなる。

しかし、AHKを起動した後に、そのサンプルプログラムを実行すると、AHKはキーイベントを拾ってしまうのですね。

AHKのソースコードでは、同じ方式でフックをしているように見えるので、なぜ、そういう動作になるのか、分かりません。

AHKは、ソースコードのどこかで、なにか特別なことをやっているのでしょうか？それとも、.NETで同じことをした場合に、特有の現象なのでしょうか？

ActiveWindowの真ん中にマウスカーソルを持ってくるという操作は、窓使いの憂鬱ではできませんが、AutoHotkeyでは出来るようです。その認識で間違いないですか？

「AHKと窓使いの憂鬱を両方インストールして使っても、トラブルが起きたという話は聞かない」という書き込みをネットで見かけました。

なぜなら、ソフトを実装するレイヤが違うからだそうです。

つまり

キー入力→窓使いの憂鬱→AHK→アプリケーション

という順序で、キー入力処理が行われると。

また、その場合、キー定義は窓使いの憂鬱で、それ以外はAHKで、という使い分けをする、というスタイルのようでした。

しかし、窓使いの憂鬱のマニュアルには、AHKの併用はトラブルが出るので避けるように、と書いてあります。

この辺、実際のところは、どうなっているのでしょうか？

ご教授いただけると幸いです。

また、以下の点がとくによく分からなかったです。

●AHKでは、ウィンドウタイトルのマッチングに日本語を使った場合、問題なくマッチングできるのか？正規表現を使おうとすると、日本語は使えないみたいだけど、正規表現を使わなければ、日本語でウィンドウタイトルの指定も出来る？

よろしくお願いいたします。

ちなみに、私なりに調べたところ、どうやら、以下のことが、それらに相当するように思えるのですが、この理解は、正しいのでしょうか？

●AutoHotkeyでは、SandSなどのワンショットモディファイアは、一つの修飾キーしか指定できない。複数の修飾キーで修飾したキーに機能を割り当てたければ、窓使いの憂鬱を使うしかない。たとえば、「SpaceをDownしたまま、かつ、変換をDownしたまま、Kを押す」と、あるアプリが起動する、というようなキー割り当ては、AutoHotkeyではできない。

●窓使いの憂鬱の内部的な独自LockキーでであるLock0～Lock9は、AutoHotkeyではグローバル変数を使用することにより実装できる。

●x64系のマシンを使っている場合、窓使いの憂鬱は使えない。

●マウスジェスチャーに機能を割り当てるのは、AutoHotkeyでできるけど、窓使いの憂鬱ではできない。