Posts: 32
Threads: 10
Joined: Feb 2009
I have been using QM 2.1.8 since it was released. And blocked for some keys in a LLKeybProc.
Then used 'ifk' in other functions, to detect if these keys are pressed.
Now when i have upgraded to QM 2.2.1, it seems that this is not possible anymore. Using GetKeyState, RealGetKeyState or GetAsyncKeyState makes no differens.
I can get around this problem, but cannot figure out why a new QM version should cause this..?
Posts: 12,147
Threads: 143
Joined: Dec 2002
Don't remember, maybe in older QM ifk used keyboard hook, and now uses GetKeyState or similar function, which is unaware about blocked keys. I had to change code of some functions because I did not want to use hooks in exe (QM 2.1.9).
Posts: 32
Threads: 10
Joined: Feb 2009
Thanks, now i know what to go for.
- not always easy to make everyone happy..
Posts: 32
Threads: 10
Joined: Feb 2009
This was a little more complicated than i first thougt..
My 'LowLevelKeybordProc' have grown to king size - also had to use 'GetGUIThreadInfo' to detect when a menu is in focus.
I'm learning a lot by this, but think that QM is not the same without the possibility to block a key, and then use 'ifk' to read that key.
Could it be an option, even if it not will work in exe..?
Posts: 12,147
Threads: 143
Joined: Dec 2002
ifk, RealGetKeyState and GetAsyncKeyState work when keys are blocked using not LL hook.
LL hook option for QM triggers added in QM 2.2.0.
When using LL hooks to block keys, then only LL hook (same or another that is installed later) can know key state.
Posts: 32
Threads: 10
Joined: Feb 2009
Ok,- now i've got it.
Use QM trigger to block key - not LL hook. And do not use option 'low level keyboard hook' for QM triggers.
Then 'ifk' will work in any case.
When you first know, it's so simple...
