Dlaczego program Visual Studio przechwytuje kluczowe zdarzenia przed funkcją AutoHotkey?

Niedawno przerzuciłem się na układ klawiatury Dvoraka jako trochę eksperymentu. Jedna z najtrudniejszych części przejścia dotyczyła skrótów klawiszowych. Większość skrótów klawiszowych została zaprojektowana z myślą o QWERTY, a co gorsza, klawisze skrótu wydają się być ekstremalnie związane z pamięcią mięśniową.

Zamiast uczyć się na nowo wszystkie hot-klucze, pisałem skrypt AutoHotkey przetłumaczyć Dvorak layout z powrotem do QWERTY, gdy Ctrl, Altlub Winsą naciskane klawisze w połączeniu z innymi klawiszami. Działa pięknie wszędzie, gdzie próbowałem, z wyjątkiem Visual Studio '08. Wygląda na to, że naciśnięcia klawiszy są przechwytywane, zanim autohotkey może je przetłumaczyć.

Dlaczego tak się dzieje i jak to naprawić?

Poniżej fragment (od początku) mojego skryptu:

; control + letter
^;::^z
^q::^x
^j::^c
^k::^v

Aktualizacja: Skrypt działa dobrze na Win7 ze świeżo zainstalowanymi ahk, vs08 i coderush. Na komputerze, z którym mam problem, działa Vista. Jakieś przemyślenia na temat dalszego diagnozowania?

Aktualizacja 2: Skrypt działa dobrze z Vista i 2010 beta 2. Wydaje się, że jest to coś z tylko vs 08 + Vista. Dziś wieczorem spróbuję nowej instalacji VS08.

Aha! Rozgryzłem to. Jeśli ahk i aplikacja docelowa nie działają z tymi samymi uprawnieniami (lub użytkownikiem), ahk nie będzie poprawnie przechwytywać / symulować zdarzeń klawiatury. W moim przypadku Visual Studio zostało uruchomione z uprawnieniami administratora (podwyższonymi), podczas gdy skrypt ahk został uruchomiony jako aktualnie zalogowany użytkownik.

Jeden z poniższych rozwiązał problem:

• Uruchomiony zarówno vs, jak i ahk jako bieżący użytkownik
• Kompilowanie skryptu i uruchamianie zarówno vs, jak i skompilowanej aplikacji jako administrator

Chcę tylko dodać kilka punktów do rozwiązania znalezionego przez samego OP.

1) Problem nie polega na tym, że AHK i VS działają z różnymi uprawnieniami - po prostu skróty klawiszowe utworzone przez skrypt działający w trybie nieadministracyjnym nie działałyby na aplikacjach działających w trybie administratora , ale nie byłoby problemu, gdyby tak było odwrotnie.

2) Nie trzeba koniecznie kompilować skryptu, wystarczy ustawić autohotkey.exe tak, aby działał w trybie administratora (to właśnie robię) lub alternatywnie utworzyć skrót do konkretnego skryptu i ustawić go tak, aby zawsze działał w trybie administratora. (przy okazji, żeby zaznaczyć, nie ma wzrostu wydajności po uruchomieniu skompilowanej wersji skryptu AHK, ponieważ kod jest nadal interpretowany - po prostu teraz interpreter jest osadzony w utworzonym pliku wykonywalnym)

Wynika to z funkcji zabezpieczeń zwanej izolacją uprawnień interfejsu użytkownika (UIPI) , która jest częścią kontroli konta użytkownika (UAC).

W często zadawanych pytaniach znajduje się kilka obejść:

Jak obejść problemy spowodowane przez kontrolę konta użytkownika (UAC)?

Typowe obejścia są następujące:

• Włącz opcję Dodaj „Uruchom z dostępem do interfejsu użytkownika” do menu kontekstowych w konfiguracji AutoHotkey. Tę opcję można włączyć lub wyłączyć bez ponownej instalacji AutoHotkey, ponownie uruchamiając AutoHotkey Setup z menu Start. Po włączeniu uruchom plik skryptu, klikając go prawym przyciskiem myszy i wybierając opcję Uruchom z dostępem do interfejsu użytkownika lub użyj wiersza polecenia, takiego jak "AutoHotkeyU32_UIA.exe" "Your script.ahk"(ale dołącz pełne ścieżki).
• Uruchom skrypt jako administrator. Należy zauważyć, że powoduje to również uruchamianie programów uruchamianych przez skrypt jako administrator i może wymagać od użytkownika akceptacji monitu o zatwierdzenie podczas uruchamiania skryptu.
• Wyłącz lokalne zasady zabezpieczeń „Uruchom wszystkich administratorów w trybie zatwierdzania przez administratora” (niezalecane).
• Całkowicie wyłącz UAC. Nie jest to zalecane i nie jest możliwe w systemie Windows 8 lub nowszym.

Generalnie nie polecam uruchamiania skryptu jako administrator w celu obejścia tego problemu, ponieważ ma on efekty uboczne, które mogą być nieoczekiwane lub niepożądane. Na przykład każdy program uruchamiany przez skrypt Runbędzie również działał jako administrator. Skrypt będzie miał również niepotrzebne uprawnienia do zapisu w różnych folderach, takich jak Program Files. Trochę złego kodu (złośliwy kod wklejony skądś lub kod z błędem) może w ten sposób wyrządzić więcej szkód.

Oczywiście nie polecam też dwóch ostatnich opcji. Pozostaje tylko Uruchom z dostępem do interfejsu użytkownika , który można włączyć i używać zgodnie z powyższym opisem.

Najwyraźniej istnieje obejście tego problemu.

Z dokumentacji Program.htm # Installer_uiAccess .
Wątek na forum autorstwa Lexikos

Fragment:

EnableUIAccess

Modyfikuje AutoHotkey.exe, aby umożliwić skryptom wykonywanie następujących czynności nawet przy włączonej UAC:

Interakcja z oknami programów administracyjnych bez uruchamiania skryptu jako administrator. Użyj SendPlay. Istnieją ograniczenia; przeczytaj post przed użyciem tego skryptu.

Link do pobrania pliku ahk jest uszkodzony na forum, ale znalazłem go na Github: EnableUIAccess.ahk