Why is visual studio catching key events before autohotkey?

Question

I recently switched to the Dvorak keyboard layout as a bit of an experiment. One of the most difficult parts of the transition has been dealing with hot-keys. Most hot-keys are designed with QWERTY in mind and, to make matters worse, hot-keys seem to be extremely muscle memory bound.

Rather than relearn all the hot-keys, I've written an autohotkey script to translate the Dvorak layout back to QWERTY when the Ctrl, Alt, or Win keys are pressed in conjunction with other keys. It works beautifully everywhere I've tried, except Visual Studio '08. It seems keystrokes are being caught before autohotkey can translate them.

Why is this happening and how do I fix this?

Below is an excerpt (from the start) of my script:

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

Update: The script works fine on Win7 with ahk, vs08, and coderush freshly installed. The machine I'm having trouble with is running vista. Any thoughts on how to further diagnose?

Update 2: The script works fine with Vista and 2010 beta 2. Seems to be something with just vs 08 + vista. Gonna try a fresh install of vs08 tonight.

Answer 1

Aha! I've figured it out. If ahk and the target app are not running under the same privileges (or user) ahk won't intercept/simulate keyboard events properly. In my case, visual studio was run with administrator (elevated) privileges while the ahk script was run as the currently logged on user.

Either of the following solved the problem:

• Running both vs and ahk as the current user
• Compiling the script and running both vs and the compiled app as administrator

Answer 2

Just want to add a couple of points to solution found by the OP himself.

1) The problem is not with AHK and VS running with different permissions - its just that hotkeys created by a script running in a non-admin mode wouldn't work on applications running in the admin mode, but there would be no problem if it's the other way round.

2) There is no need to compile the script necessarily, just set autohotkey.exe to run in the admin mode (that's what I do), or alternatively create a shortcut to the particular script and set it to always run in admin mode. (btw, just to point out, there is no performance gain by running a compiled version of an AHK script, because the code is still interpreted - its just that now the interpreter is embedded in the executable created)

Answer 3

Apparently there is a workaround for this.

From the docs Program.htm#Installer_uiAccess.
Forum thread by Lexikos

Excerpt:

EnableUIAccess

Modifies AutoHotkey.exe to allow scripts to do the following even while UAC is enabled:

Interact with windows of administrative programs without running the script as administrator. Use SendPlay. There are limitations; please read the post before using this script.

The download link to the ahk file is broken on the forum but I found it on Github: EnableUIAccess.ahk

Answer 4

This is due to a security feature called User Interface Privilege Isolation (UIPI), which is part of User Account Control (UAC).

There are several workarounds listed in the FAQ:

How do I work around problems caused by User Account Control (UAC)?

Common workarounds are as follows:

• Enable the Add 'Run with UI Access' to context menus option in AutoHotkey Setup. This option can be enabled or disabled without reinstalling AutoHotkey by re-running AutoHotkey Setup from the Start menu. Once it is enabled, launch your script file by right-clicking it and selecting Run with UI Access, or use a command line like "AutoHotkeyU32_UIA.exe" "Your script.ahk" (but include full paths).
• Run the script as administrator. Note that this also causes any programs launched by the script to run as administrator, and may require the user to accept an approval prompt when launching the script.
• Disable the local security policy "Run all administrators in Admin Approval Mode" (not recommended).
• Disable UAC completely. This is not recommended, and is not feasible on Windows 8 or later.

I generally do not recommend running a script as administrator to work around this issue, as it has side-effects that might be unexpected or undesired. For example, any program that the script launches with Run will also run as administrator. The script will also have unnecessary write permission to various folders, such as Program Files. A bit of bad code (malicious code copy-pasted from somewhere, or code with a bug) could do more damage this way.

Of course, I do not recommend the last two options either. That leaves only Run with UI Access, which can be enabled and used as described above.