Ik zit met een nogal apart probleem. Voor mijn macro-tool moet ik alle keyboard-input van het systeem uitlezen, maar daarbij wil ik ook nog graag bijhouden wat het actieve scherm is waarin dit gebeurd.
Als ik een WH_KEYBOARD-hook zet, wordt mijn DLL lekker geïnjecteerd in alle actieve processen, waardoor ik zonder problemen GetFocus in de actieve applicatie kan aanroepen. Maar dan komt het probleem: als de keyboard-actie een nieuw scherm opstart (zoals CTRL+O) blijft de GetFocus hangen totdat dit nieuwe scherm actief is, waardoor ook de PostMessage/SendMessage naar mijn eigen applicatie blijft wachten. Hierdoor retourneert de GetFocus de handle naar het actieve control op het nieuwe scherm, en niet naar die op het moment van de toetsenbord-actie actief was, waardoor de volgorde in mijn script niet klopt.
Heeft dit ermee te maken dat de GetFocus weer een message bovenop de queue plaatst, waardoor deze pas afgehandeld wordt nádat de message van het openen van het nieuwe window afgehandels is?
Dit kan ik wel oplossen door een WH_KEYBOARD_LL te zetten, maar dan wordt de DLL niet meer geïnjecteerd, waardoor GetFocus alleen nog maar in mijn eigen process-boundaries werkt. Ik kan natuurlijk wel bij iedere actie mijn InputThread koppelen aan die van het actieve window, maar ik vond juist de eerste methode zo elegant.
Edit: De GetFocus is belangrijk, omdat ik op die manier bij elkaar horende input van het toetsenbord kan groeperen, en niet elke key als aparte actie in mijn script hoef op te nemen.
Als ik een WH_KEYBOARD-hook zet, wordt mijn DLL lekker geïnjecteerd in alle actieve processen, waardoor ik zonder problemen GetFocus in de actieve applicatie kan aanroepen. Maar dan komt het probleem: als de keyboard-actie een nieuw scherm opstart (zoals CTRL+O) blijft de GetFocus hangen totdat dit nieuwe scherm actief is, waardoor ook de PostMessage/SendMessage naar mijn eigen applicatie blijft wachten. Hierdoor retourneert de GetFocus de handle naar het actieve control op het nieuwe scherm, en niet naar die op het moment van de toetsenbord-actie actief was, waardoor de volgorde in mijn script niet klopt.
Heeft dit ermee te maken dat de GetFocus weer een message bovenop de queue plaatst, waardoor deze pas afgehandeld wordt nádat de message van het openen van het nieuwe window afgehandels is?
Dit kan ik wel oplossen door een WH_KEYBOARD_LL te zetten, maar dan wordt de DLL niet meer geïnjecteerd, waardoor GetFocus alleen nog maar in mijn eigen process-boundaries werkt. Ik kan natuurlijk wel bij iedere actie mijn InputThread koppelen aan die van het actieve window, maar ik vond juist de eerste methode zo elegant.
offtopic:
Moet bij een WH_KEYBOARD_LL de callback-functie sowieso wel persé in een DLL geplaatst worden? Want ik ben er nu dus achter dat díe niet geïnjecteerd wordt in alle actieve processen. Want ik begrijp ook het zinnetje uit MSDN "application-definded or library-defined callback function used with de SetWindowsHookEx" niet helemaal... Betekend dat ik ook gewoon een functie uit m'n eigen applicatie door mag geven, en dit dus geen Access Violation is?
Moet bij een WH_KEYBOARD_LL de callback-functie sowieso wel persé in een DLL geplaatst worden? Want ik ben er nu dus achter dat díe niet geïnjecteerd wordt in alle actieve processen. Want ik begrijp ook het zinnetje uit MSDN "application-definded or library-defined callback function used with de SetWindowsHookEx" niet helemaal... Betekend dat ik ook gewoon een functie uit m'n eigen applicatie door mag geven, en dit dus geen Access Violation is?
Edit: De GetFocus is belangrijk, omdat ik op die manier bij elkaar horende input van het toetsenbord kan groeperen, en niet elke key als aparte actie in mijn script hoef op te nemen.
[ Voor 17% gewijzigd door riezebosch op 20-12-2004 11:43 ]
Canon EOS 400D + 18-55mm F3.5-5.6 + 50mm F1.8 II + 24-105 F4L + 430EX Speedlite + Crumpler Pretty Boy Back Pack