[Home] [Puzzles & Projects] [Delphi Techniques] [Math topics] [Library] [Utilities]
|
|
Problem DescriptionThis program implements a global keyboard hook which displays pressed character keys in any other program while the demo is running until the "Enter" (Return) key is pressed. Background & TechniquesThe demonstration program was motivated by a user request for a program which could display entered characters for use during password entry for any program which has no option to view the keys being entered. It may be useful if complex passwords or lengthy pass-phrases must to be entered with no option to display the keys being typed. It also turned out to be an interesting programming project because, even though the procedures are well documented, there are a few undocumented problems to be resolved. Non-programmers are welcome to read on, but may want to jump to bottom of this page to download the executable program now. Programmer's Notes:A program generally cannot access what happens in other programs but it may load a DLL (Dynamic Load Library) program which can intercept system messages from any program . The DLL can can then intercept keyboard messages and pass special "user" messages with the info back to the program which loaded it. So, in our case, KeyDisplay.exe loads KeyDisplayHook.DLL and lets it send him a message each time a character key is pressed. There is no shortage of online examples of Delphi keyboard hook procedures, but it took several days to find the trick of reliably distinguishing lower from upper case . The keyboard itself knows nothing about upper/lower case. The messages generated by the keyboard driver should contain information not only about the key being pressed but also about other keys held down at the time (e.g. the shift key). It does this by including a "Keystate" array it its message with one byte for each possible key, including one bit indicating whether that key is currently pressed. It may just be a bug in the driver for my new HP Envy 17 laptop, but it turns out that the key state array is not completely updated during the "Keydown" message. A call to GetKeyState(vk_shift) returns the actual current key state for either shift key. Updating the key state array with that information corrected my problem of missing the state for the first key pressed after a shift key was pressed. If integrated debugging of DLLs is possible, I couldn't figure out how to set it up, so debugged by passing variable values back to the calling program as parameters in the user messages generated. A slow process but, once again, persistence paid off! Running/Exploring the Program
Suggestions for Further Explorations
|
[Feedback] [Newsletters (subscribe/view)] [About me]Copyright © 2000-2018, Gary Darby All rights reserved. |