HOTKEY.DLL is designed to provide hotkey support to Visual Basic as this is not directly supported in VB. You can define multiple hot
keys in your application and the DLL can be used by multiple applications
simultaneously.
The Point:
The point is that you might want to create a TSR type utility in VB that "pops up" or performs some background task given a certain "hot key." For example, let's say that you want to be able to insert the
current date the the cursor location of whatever text editor you are using. This is normally impossible to accomplish in VB. Not anymore! Now you can create a ultility that has a hot key of Ctrl-D that, while as an icon, inserts today's date in whatever application you are using. Another example might be a popup calander application. Normally, the user would have to double-click on your icon, but now you can define a key that brings your application to the fore front for immediate use. I am certain, that when you think about it, you will be able to come up with much more interesting ideas, but those are just a couple.
How do You Do It?
Well, HOTKEY.DLL has two functions: CreateHK and KillHK. The former establishes a hotkey and the latter gets rid of them. The syntax for them is as follows:
hHotKey = CreateHK (VKCode, Shift, Wnd, UserVK)
where
VKCode is an valid virtual key code. These are the same codes
used in the KeyDown and KeyUp event handlers. The values
for the different keys can be found in CONSTANT.TXT with
the KEY_ prefix.
Shift is the mask for the shift keys you want included in your
hot key. These are the same as those used in the KeyDown
and KeyUp events in the "Shift" parameter. These values
can be added together for multiple shift keys. This
concept is explained on page 277 of the Programmer's
Guide.
Wnd is the hWnd property of the Form that you want to receive
"hot key events." Therefore, you would normally simply
pass hWnd as this parameter.
UserVK is the value you want sent to your window when your hot
key comes up. This can be any value you want it to be.
It is best to start with values over 144 as this is where
the normal Key_Codes end. This can be *any* valid integer
hHotKey is returned by the function as the "handle" to the hotkey.
This is used only to "kill" the hotkey later on. This
will be set to (-1) if the hot key you selected is
already in use. It will return a (-2) if there are no
more hot keys. You are limited to 1024 simultaneous hot
keys on your desktop. Note: this does not include, any
hot keys that might be defined in the Windows Macro
Recorder. Those are independent of HOTKEY.DLL. Also,
HOTKEY.DLL *cannot* detect if a hot key is already taken
by the Windows Macro Recorder. Be careful of overlap!
Once you have created as many hot keys as you want, you need to create
a KeyDown event handler for that form. This event is rarely used because normally, it requires that the form have focus. This can only happen when there are no controls on the form or they are all disabled. Never fear, however, HOTKEY.DLL can easily coexist with normal KeyDown processing as long as you define UserVK codes that to not represent valid virtual key codes. Anyway, in the KeyDown handler, you will see two parameters: KeyCode and Shift. The only one of interest to us is KeyCode because the event will only be triggered if all the proper shift keys are pressed! What the KeyCode parameter will contain is the UserVK code that you specified when creating your hot key. You can then use SELECT CASE or something to process the different hot keys that you have created. All this can transpire with your app as an icon and with you app never receiving focus!
When Unloading Your Form:
When you are unloading your form, please call KillHK and pass the "handle" returned to you by CreatHK. Not only will this allow other applications to use those hot keys but HOTKEY.DLL does a lot of cleanup when a hot key is "killed" so that key processing is as fast as possible. When you consider that the DLL has to filter *every* keystroke, it is imperative to processes keys as fast as possible. I think it's pretty quick but I would like to hear comments from you on any performance hits you feel you are taking. I don't think the human eye will be able to
notice.
The Example:
HOTKEY.EXE (HOTKEY.* source files) is a *very* simplistic demo of some of the features of HOTKEY.DLL. Essentially, it loads itself as an icon and then loads NotePad. You may type freely in notpad but when
you use the following key combinations, funning things happen, all with NotePad never losing focus:
F7 HOTKEY.EXE exits
Shift-F9 The Icon toggles between two pictures
Ctrl-T The Current time is inserted into Notepad
Ctrl-D The Current date is inserted into Notepad
Shift-Ctrl-Alt-F10 A message appears
How did I do it? (For those who care...)
HOTKEY was written in Turbo Pascal for Windows. I like Pascal better than C and, as a matter of priciple, I would choose to use the tool that cost me $199 and included a compiler, windows based debugger, the Whitewater Resource Toolkit all in a Windows based development environment (hey, I thought it was MS who was hot on Windows!) that allows me to create *one* source file instead of four (with all sorts of crazy link options and import libraries!). The C/SDK combo cost me close to $1,000 and it is a PITA to use.
HOTKEY was not implemented as a custom control because: 1) it would have been more trouble than it was worth. 2)it probably would have required multiple keyboard hooks instead of one which would degrade performance. 3)it would only work with VB and we use lots of other similar tools and finally 4)it would have to have been done in C! Argh! Besides, Crescents is creating a low-level keyboard handler control that I will simply buy.
Essentially, HOTKEY has four routines. There is an itialization routine that dims an array of record variables (you know TYPE..END TYPE) to 1024 elements. It then sets some global variables. Finally, it makes a call out to SetWindowsHook, telling it to trap all keys and to filter them through my keyboard handler: KBProc
CreateHK searches through the array to see if the the hot key is already taken. If not, it inserts the passed parameters into the next possible element of the record variable array and increments the count of hotkeys in the system. The long integer returned by CreateHK is actually a combination of your hWnd and your UserVK. This way, the hotkey is uniquely identified.
KillHK moves everything, below the hot key being removed, up one element in the record variable array and decrements the total. I chose to take the extra time to do this here rather than make the search longer for every keystroke.
KBProc constructs a mask using GetKeyState for the SHIFT and Ctrl keys and using lParam for the ALT key. It then scans through the record variable array looking for the same keycode and mask. If it finds it, it passes the WM_KEYDOWN message to the corresponding hWhd, passing the UserVK that you provided as the parmeter. If they key is not found, it is passed on to the next keyboard handler which is usually the application you are working in.
The exit procedure, unhooks KBProc from the keyboard chain and frees up the memory taken by the record variable array. That's about it. I hope you are able to find this useful in your applications and I welcome any suggestions or comments.
