If you have more than one keyboard built or attached to your computer, you can use these functions to make keyboard-specific triggers. For example, F7 trigger that works when you press F7 on your attached USB keyboard, but does not work when you press F7 on your notebook keyboard.
These functions also allows you to make mouse-specific mouse triggers (added Nov 26, 2005).
Requirements: Windows XP or later, QM 2.1.5 or later.
Aug 26 2008:
Works better on computers with more than 1 CPU.
More reliable. Minimized possibility to recognize incorrect keyboard or mouse, even when pressing keys on two keyboards simultaneously.
Easier setup. Now you don't have to edit filter functions.
Does not show error messages when Keyboard_Detector is not running.
UPGRADING
Delete Keyboard detector folder. Import the downloaded file. Run Keyboard_Detector two times to show dialog. In the dialog, associate filter functions with keyboards and/or mouses.
Read this if you don't know how to start using Keyboard Detector.
SETUP
1. Click the Download link. When asks to save or open, click Open. The file will be opened in QM File Viewer. Click Import. Alternatively, save the file somewhere and import it using menu File -> Import.
2. When you import the file, you will see Keyboard Detector folder at the left-bottom, and Keyboard_Detector function in it. Open the function.
3. Click the Run button on the toolbar. It starts Keyboard Detector, which is running in the background. Click Run again. It shows a dialog.
4. If you will use multiple keyboards, you need to associate them with filter functions. Read about it in the dialog. If you will use only multiple mouses, uncheck "Use multiple keyboards".
5. If you will use multiple mouses, check "Use multiple mouses" and associate mouses with filter functions.
6. When you already don't need the dialog, click Close. The dialog will disappear but Keyboard Detector will continue running. If you click Exit, Keyboard Detector will stop running. Whenever you need to access the dialog again, run Keyboard_Detector one or two times.
7. To use multiple keyboards and/or mouses, Keyboard_Detector must be running all the time. You can launch it using whatever method (Run button, some trigger, etc). To launch it automatically when QM starts, do the following. In the left pane, find item named init2. It should be in User folder. If init2 does not exist, create new function (not macro) and name it init2. Insert this code:
mac "Keyboard_Detector"
USAGE
To make a keyboard or mouse macro specific to one of devices, assign it the filter function that is associated with that device.
Example 1. Assume, you want to start a macro using F7 on your second keyboard. Open Properties, assign F7 trigger, click "Filter" button (or FF). Remember what filter function is associated with your second keyboard. Probably it is FF_Keyboard2. Check "Use", select FF_Keyboard2 from the drop-down list, click OK, OK.
Example 2. Assume, you want to start a macro using right button on your second mouse. Open Properties, assign mouse right button trigger, click "Filter" button (or FF). Remember what filter function is associated with your second mouse. Probably it is FF_Mouse2. Check "Use", select FF_Mouse2 from the drop-down list, click OK, OK.
If Keyboard Detector is running, low level hooks don't work in QM windows. Low level keyboard hooks are used by the recorder and by the BlockInput2 function. If you want to record keys in QM windows, at first exit Keyboard Detector.
QM 2.2.0. Low level hooks also can be used for keyboard triggers. If your keyboard triggers stopped working, go to Options and uncheck 'Use low level keyboard hook'.
I was corresponding with ken gray regarding these functions, and I am having some difficulty with it.
I installed following the instructions, and it kind of works, but not very well.
I have created a macro which is supposed to execute when I press "p" on the second keyboard, let's call that event "kb2:p". The first time I press kb2:p, it actually does not eat the key event at all, and allows it through to the foreground application, for instance, Notepad. But it works after that. The second time I press kb2:p, it works and the macro fires, and continues to work until I use kb1. Using kb1 seems to prevent any kb2 macros from getting through the first time.
So it's working like this:
kb1: blah blah blah
result: "blah blah blah" sent to active window.
kb2:p
result "p" sent to active window
kb2:p
result: p macro fires.
kb2:p
result: p macro fires.
kb1: blah blah blah
result: "blah blah blah" sent to active window.
kb2:p
result "p" sent to active window
kb2:p
result: p macro fires.
kb2:p
result: p macro fires.
So anyways, I write software too, and I was really curious about what goes on behind the scenes here. I wrote a small test application that uses both Raw Input (to get the keyboard id) and a low level hook (to consume the key event) and the results are interesting.
1) I can detect and deny a keyboard event with the LL hook, but I can't determine the originating keyboard ID.
2) I can determine the originating keyboard ID with RI, but I can't deny they keyboard event from passing through to the foreground application.
3) If I deny a keyboard event with the LL hook, it never bubbles up to the RI hook for origin detection.
So there appears to be a chicken and egg problem here. Is this the reason that the macros on the kb2 work the way that they do? When you see the first kb2:p event, via RI, set a flag that causes the next LL p event to change context to kb2 and then set the context back to kb1 the next time a RI event is received from kb1?
How exactly are you working around what seems to be an inherent limitation of how Raw Input and Low Level keyboard hooks work?
Now I cannot analyze the code, test, etc, but only can say what I know so far.
Keyboard detector is incompatible with low level keyboard hooks when both run in the same process (in this case - QM). On my computers, low level hooks stop working. On somebody elses computer, LL hooks work but keyboard detector does not. Make sure that 'use low level keyboard hook' is unchecked in Options.
To work correctly, the WM_INPUT message (raw input) must be received before QM receives notification about the key through its keyboard hooks. Even if keyboard hooks work, low level hooks are always called before WM_INPUT. Non LL hooks in most cases are called after WM_INPUT.
What you described, happens when WM_INPUT is received later. On first message generated by new keyboard, QM still thinks that it came from old keyboard, because WM_INPUT for that key still did not arrived.
i have to deal with 12 different kinds of software applications almost simultaneously, all require my immediate attention. i have made about 1600 plus scripts to accomplish this. Now i just need to map each of these to a button.
My life would be a whole lot less stressful
No all of them are in autohotkey. i never knew about Quick Macros until i went searching for something that would make use of multiple keyboards.
Very new to Quick Macros
i dont know much about QM.
I have just tried it. installed Keyboard Detector and is working beautifully with 4 keyboards.
little playing around i found if i create a macro with a run command to the right .ahk file.
so far looks good, but need to utilize more keyboards
you don't need that many keyboards for all those scripts (thought you'll have to rebuild them in QM if you're going to use QM's native lang).
just use one extra keyboard and use modifiers like shift, ctl-shift, shift-alt, shift-win, alt-ctl, alt-win, alt-shift, ctl-shift-alt. ctl-shift-win. that'll give you just under a 1,000 and it's not including things like Left-Shift and Right shift. That'll easily take it over 4,000 possible iterations.
ken there are a few reasons i dont want to that. for one i just want to press one button and be done with. One big clear button on a day i am not that alert really would help. i really dont have to look at the ctrl alt win and stuff. few hundred less keys to push in a day brings a lot of peace. second i have plans to expand the scripts even more accurately later. so if the key A runs a script ascriptkybd1.ahk, the ctrl A, Alt A will just run the slightly modified version of the same script.
no all scripts require a keypress from me, as i authorize
i am not working alone on this project, so not everybody agrees to show the work. but i can tell you they require a keypress from me definately.
is it really hard to get more keyboards with QM?
Possible, but requires several hours for changing and testing. Maybe much more, because this Keyboard Detector is not optimized for so many keyboards, would need to create completely new. This is so exotic, nobody else will use it.
Possible, that word sounded so sweet
From where i am people hardly have enough jobs, i am happy doing this project no matter how much it pisses me of.
infact i tend to love it, cause it feeds my family of six.
i wish this would be done.
i dont mind making a donation for this even if i have to go hungry a few lunches.
infact i will be happy
guess i am in the christmas spirit
