visual-studio visual-studio-2008 autohotkey dvorak

¿Por qué Visual Studio captura eventos clave antes de autohotkey?



visual-studio visual-studio-2008 (4)

Recientemente cambié al diseño de teclado de Dvorak como un pequeño experimento. Una de las partes más difíciles de la transición ha sido lidiar con teclas rápidas. La mayoría de las teclas rápidas están diseñadas con QWERTY en mente y, para empeorar las cosas, las teclas rápidas parecen tener una memoria extremadamente muscular.

En lugar de volver a aprender todas las teclas de acceso rápido, he escrito un script de autohotkey para traducir el diseño de Dvorak a QWERTY cuando se presionan las teclas Ctrl , Alt o Win junto con otras teclas. Funciona muy bien en todas partes que he intentado, excepto Visual Studio ''08. Parece que las pulsaciones de teclas están siendo atrapadas antes de que autohotkey pueda traducirlas.

¿Por qué sucede esto y cómo soluciono esto?

A continuación se muestra un extracto (desde el principio) de mi script:

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

Actualización: la secuencia de comandos funciona bien en Win7 con ahk, vs08 y coderush recién instalado. La máquina con la que estoy teniendo problemas está ejecutando Vista. ¿Alguna idea sobre cómo diagnosticar aún más?

Actualización 2: el script funciona bien con Vista y 2010 beta 2. Parece ser algo con solo vs 08 + vista. Voy a intentar una nueva instalación de vs08 esta noche.


Aha! Lo he descubierto. Si ahk y la aplicación de destino no se están ejecutando bajo los mismos privilegios (o usuario), ahk no interceptará / simulará los eventos del teclado correctamente. En mi caso, visual studio se ejecutó con privilegios de administrador (elevado) mientras que el script ahk se ejecutó como el usuario actualmente conectado.

Cualquiera de los siguientes resolvió el problema:

  • Ejecutando ambos vs y ahk como el usuario actual
  • Compilando el script y ejecutando tanto vs como la aplicación compilada como administrador

Aparentemente hay una solución para esto.

De los documentos Program.htm#Installer_uiAccess .
Tema del foro por Lexikos

Extracto:

EnableUIAccess

Modifica AutoHotkey.exe para permitir que los scripts hagan lo siguiente, incluso mientras el UAC está habilitado:

Interactúa con Windows de programas administrativos sin ejecutar el script como administrador. Use SendPlay. Hay limitaciones; por favor lea la publicación antes de usar esta secuencia de comandos.

El enlace de descarga al archivo ahk está roto en el foro, pero lo encontré en Github: EnableUIAccess.ahk


Esta frase en letra pequeña suena relevante:

Si SendMode se utiliza en la sección de ejecución automática (parte superior del script), afecta a todas las remapeadas. Sin embargo, dado que la reasignación utiliza Send {Blind} y dado que el modo SendPlay no es totalmente compatible con {Blind}, es posible que algunos remapeos no funcionen correctamente en el modo SendPlay ( especialmente Control, Shift, Alt y Win ). Para evitar esto, evite SendPlay en la sección de ejecución automática cuando tenga remapeados; luego use el comando SendPlay vs. Send en otros lugares a lo largo del script. Alternativamente, podría traducir sus remapeos en teclas rápidas (como se describe a continuación) que explícitamente llaman SendEvent vs. Send.


Solo quiero agregar un par de puntos a la solución encontrada por el propio OP.

1) El problema no es que AHK y VS se ejecuten con diferentes permisos, es solo que las teclas de acceso rápido creadas por un script que se ejecuta en un modo no administrador no funcionarían en aplicaciones que se ejecutan en el modo de administración , pero no habría ningún problema si al revés.

2) No es necesario compilar el script necesariamente, simplemente configure autohotkey.exe para que se ejecute en el modo de administración (eso es lo que hago), o bien, cree un acceso directo al script en particular y configúrelo para que siempre se ejecute en el modo de administración. (Por cierto, solo para señalar, no hay ganancia de rendimiento ejecutando una versión compilada de un script AHK, porque el código todavía se interpreta, es solo que ahora el intérprete está incrustado en el ejecutable creado)