Respecto a la forma que intentas hacer esto, pufffff.....os recomiendo que lo olvideis
. No creo que sea una forma viable.
Para empezar, sigues sin poder controlar (ni lo vas ha hacer de esta forma) el tiempo al que se le pasan las pulsaciones.
Sí, muy bien, pulsas alt+tab y da una pulsación en su momento, ya que has puesto una variable auxiliar para parar la ejecución del código hasta que no sueltes la combinación de teclas y las vuelvas a pulsar. Pero resulta que esto no es simplemente una pulsación y ya está. Tienes que detectar las pulsaciones que genera win cuando mantienes apretada esa combinación, y tu código no lo hace.
Además, sigues dependiendo del bucle while inicial. Si metes un retardo grande, o simplemente salta un msgbox o cualquier otra cosa que te pare la aplicación, esto deja de funcionar. Seguramente este problema si tenga alguna solución, como meterlo en un timer asíncrono en vez de en el bucle.
Pero repito, yo creo que no vas a poder controlar en la vida la velocidad exacta de las pulsaciones sin capturarlas por mensajes de win
. Y ese es un grandísimo problema para este caso.
Prueba todo lo que te he dicho en mi código y verás que sigue su funcionamiento normal, ya que lo hace de forma asíncrona. Lo único que fallaría sería todo lo que está metido en el while, como cerrar la ventana, pero esto podría solucionarse con un timer asíncrono que detectase este evento
.
Aaahhh, y otra cosa. Si por alguna casualidad se consiguiese hacer lo de la velocidad así por las buenas (lo dudo), luego tendrías el problema de ir metiendo todas las condiciones que he tenído que encajar.....que es lo que más me ha costado
.
Ximorro escribió:Lo que sí es cierto es que hay que comprobar activamente, con tu sistema usando mensajes de Windows está muy bien porque te avisa cuando ocurre, aunque de todas maneras tienes que esperar en un bucle que hace "nada" (vaya, otro Sleep(10) ).
Aquí si que no te entiendo. Que tengo que esperar en un bucle que no hace nada? Solamente espero en el while principal, para que no se cierre la aplicación, pero eso es normal en todos los programas.
Si te refieres al while interno de la función _KeyProc, no afecta para nada al funcionamiento del programa, ya que se supone que mientras tengas apretadas atl+tab, no vas a poder hacer otra cosa que conmutar las ventanas (y si no mira win
).
Y si por casualidad quieres hacer otra cosa, metelo dentro de ese while o dentro de un timer
.
Ximorro escribió:Y lo mismo para conocer el funcionamiendo de KeyProc, ¿dónde podemos ver los códigos que toman los parámetros cuando se pulsan las teclas?
Los códigos de las teclas son los keycode.....los mismos que utiliza la función _IsPressed
. Te los devuelve la variable $codigo. Puedes hacer un consolewrite($codigo&@cr) y verás los códigos al pulsar las teclas.
Ximorro escribió:Lo que no veo por qué no estás impidiendo que Windows vea las teclas, esto me parece muy parecido al control de mensajes de Windows a través de AutoIT, y leí que había que devolver algo así como $GUI_RUNDEFMSG para que el mensaje sea rebotado al Windows y también lo procese. ¿O eso sólo es cuando cazas el mensaje con GUIRegisterMsg?
Jajajaja....pues mira, me acabas de enseñar algo nuevo. No tenía ni idea de que hacía la devolución de esa variable. Creía que no era importante y yo siempre la quitaba
. Habrá que ponerla al final por si acaso alguna vez genera algún error no deseado el no ponerla
.
Me has hecho leer en función GUIRegisterMsg en la ayuda. Puffffff....mi ingles es muy limitado y no lo entiendo muy bien. Y el google a veces traduce peor que yo
. Es como si dijese que para retornar a los mensajes internos de autoit se debe hacer esto
(que traducción más mala por mi parte
). No se no se.....estaría bien que alguno lo tradujese bien o que algún gurú de autoit no lo explicase.
Pero como tu bien dices parece que solo es cuando utilizas la funcion GUIRegisterMsg (que tampoco lo se a ciencia cierta. Ya te he dicho que ni papa de esta variable).
Pero pero pero.....jajajaja.....me has hecho pensar y me has recordado que si me dejaba algo por el camino. Así que me he ido al foro de habla inglesa y he buscado la función. Parece que al final devuelven el proximo gancho del teclado. Al no devolver yo nada, puede que el mensaje llege sin ninguna variación, pero por si acaso voy a editar el código y voy a meter esa devolución.
Código: Seleccionar todo
Return _WinAPI_CallNextHookEx($hHook, $nCode, $wParam, $lParam)
Ximorro escribió:¿Cómo impedirías con tu método que Windows no capture ALT+TAB?... ¡pero sí las demás teclas!
No retornando nada o un valor nulo a esta función (por ejemplo con un simple Return, Return -1, Return 1, etc
).
Tenías que haber buscado en el foro, que no es la única vez que utilizo esta función. Por ejemplo:
http://www.emesn.com/autoitforum/viewto ... Proc#p3059
Con este script verás mejor el funcionamiento del código.
Por curiosidad acabo de buscar en la ayuda y me ha aparecido un ejemplo que utiliza esto
. Ignoraba que estuviese ahí. A lo mejor en la antigua ayuda no aparecía. Como puedes ver el ejemplo del post anterior es bastante antiguo.
Mira en la ayuda el ejemplo de por ejemplo la función _WinAPI_CallNextHookEx.
Y probando mi script del conmutador de tareas, tenía abierta una ventana que me ha dado problemas y resulta que no me filtra una ventana oculta que pertenece a este programa!!!!! jajajaja.....me caguen en tooooo lo que se meneeeaaaa.
Solucionado. He sustituído el filtro que utiliza la propiedad $WS_EX_TOOLWINDOW por otro que utiliza $WS_CAPTION (parece que filtra mejor) y he dejado otros en comentarios por si fallase este también.
CODIGO DEL POST DE ARRIBA EDITADO (OTRA VEZ).
.
.
.
.
.
. En más de una ocasión se ha demostrado (por ejemplo en este foro recuerdo algo) que utilizar apis de win es más rápido que comandos de AutoIt