ビジュアルスタジオがオートホットキーの前に重要なイベントをキャッチするのはなぜですか？
私は最近、ちょっとした実験としてDvorakキーボードレイアウトに切り替えました。移行の最も困難な部分の1つは、ホットキーの処理です。ほとんどのホットキーはQWERTYを念頭に置いて設計されており、さらに悪いことに、ホットキーは非常に筋肉の記憶に縛られているようです。
すべてのホットキーを再学習するのではなく、オートホットキースクリプトを作成して、DvorakレイアウトをQWERTY Ctrl、 Alt、または Win キーは他のキーと組み合わせて押されます。 Visual Studio '08を除いて、私が試したすべての場所で美しく機能します。 autohotkeyがキーストロークを変換する前に、キーストロークがキャッチされているようです。
なぜこれが起こっているのですか？どうすればこれを修正できますか？
以下は私のスクリプトの（最初からの）抜粋です：
; control + letter
^;::^z
^q::^x
^j::^c
^k::^v
更新：スクリプトは、ahk、vs08、およびcoderushが新しくインストールされたWin7で正常に動作します。問題が発生しているマシンはVistaを実行しています。さらに診断する方法について何か考えはありますか？
更新2：スクリプトはVistaおよび2010ベータ2で正常に動作します。vs08+ Vistaで問題がないようです。今夜はvs08の新規インストールを試してみます。
あはは！私はそれを理解しました。 ahkとターゲットアプリが同じ特権（またはユーザー）で実行されていない場合、ahkはキーボードイベントを適切にインターセプト/シミュレーションしません。私の場合、ビジュアルスタジオは管理者（昇格）権限で実行され、ahkスクリプトは現在ログオンしているユーザーとして実行されました。
次のいずれかで問題が解決しました。
- 現在のユーザーとしてvsとahkの両方を実行している
- スクリプトをコンパイルし、vsとコンパイルされたアプリの両方を管理者として実行する
OP自身が見つけたソリューションにいくつかのポイントを追加したいだけです。
1）問題はAHKとVSが異なる権限で実行されていることではありません非管理者モードで実行されているスクリプトによって作成されたホットキーがアプリケーションで機能しないということだけですadminモードで実行していますが、逆の場合でも問題はありません。
2）必ずしもスクリプトをコンパイルする必要はありません。autohotkey.exeを管理者モードで実行するように設定するか（私が行うことです）、あるいは特定のスクリプトへのショートカットを作成して常に管理者モードで実行するように設定します。 （ところで、指摘するだけで、コードはまだ解釈されているため、AHKスクリプトのコンパイル済みバージョンを実行してもパフォーマンスは向上しません-作成された実行可能ファイルにインタープリターが埋め込まれているだけです）
これは、ユーザーアカウント制御（UAC）の一部である ユーザーインターフェイス特権の分離（UIPI） と呼ばれるセキュリティ機能によるものです。
FAQにリストされているいくつかの回避策があります。
ユーザーアカウント制御（UAC）によって引き起こされる問題を回避するにはどうすればよいですか？
一般的な回避策は次のとおりです。
- AutoHotkey Setupで [Run with UI Access]をコンテキストメニューに追加 オプションを有効にします。このオプションは、[スタート]メニューからAutoHotkey Setupを再実行することにより、AutoHotkeyを再インストールせずに有効または無効にできます。有効にしたら、スクリプトファイルを右クリックしてUIアクセスで実行を選択するか、
"AutoHotkeyU32_UIA.exe" "Your script.ahk"などのコマンドラインを使用して起動します。 （ただし、フルパスを含みます）。- 管理者としてスクリプトを実行します。これにより、スクリプトによって起動されたすべてのプログラムが管理者として実行され、スクリプトの起動時にユーザーが承認プロンプトを受け入れる必要がある場合があることに注意してください。
- ローカルセキュリティポリシー「すべての管理者を管理者承認モードで実行する」を無効にします（非推奨）。
- UACを完全に無効にします。これは推奨されておらず、Windows8以降では実行できません。
この問題を回避するために管理者としてスクリプトを実行することは通常お勧めしません。予期しない、または望ましくない副作用が発生する可能性があるためです。たとえば、スクリプトがRunで起動するプログラムはすべて、管理者としても実行されます。スクリプトには、ProgramFilesなどのさまざまなフォルダーへの不要な書き込み権限もあります。少し悪いコード（どこかからコピーして貼り付けられた悪意のあるコード、またはバグのあるコード）は、この方法でより多くの損害を与える可能性があります。
もちろん、最後の2つのオプションもお勧めしません。これにより、UIアクセスで実行のみが残ります。これは、上記のように有効にして使用できます。
どうやらこれには回避策があります。
ドキュメントから Program.htm＃Installer_uiAccess 。
Lexikosによるフォーラムスレッド
抜粋：
EnableUIAccess
AutoHotkey.exeを変更して、UACが有効になっている場合でもスクリプトが次のことを実行できるようにします。
管理者としてスクリプトを実行せずに、管理プログラムのウィンドウを操作します。 SendPlayを使用します。制限があります。このスクリプトを使用する前に、投稿をお読みください。
Ahkファイルへのダウンロードリンクはフォーラムで壊れていますが、Githubで見つけました： EnableUIAccess.ahk
small print のこのフレーズは関連性があるように聞こえます：
SendModeが自動実行セクション（スクリプトの上部）で使用されている場合、すべての再マッピングに影響します。ただし、再マッピングはSend {Blind}を使用し、SendPlayモードは{Blind}を完全にはサポートしていないため、一部の再マッピングはSendPlayモード（、特にControl、Shift、Alt、およびWin）で正しく機能しない場合があります。 ）。これを回避するには、再マッピングするときに自動実行セクションでSendPlayを回避します。次に、コマンドSendPlay vs.Sendをスクリプト全体の他の場所で使用します。または、再マッピングを、SendEventとSendを明示的に呼び出すホットキー（以下で説明）に変換することもできます。