Global keyboard listeners – pros and cons

As discussed previously, event listeners are a key component to GUI development and good software development. Being able to record mouse clicks, or keyboard keys can enhance the usability of software for the end-users. In this post, I intend to show you how to implement a global keyboard listener for C#.

What is a global keyboard listener?

There are two types of listener events, local and global. Local listeners only work when the software they are built for holds the focus. Global listeners will work regardless of whether their program holds focus or not. A good example of local listeners is in word processing – when the word processor holds focus, any keyboard press will result in a character (or action) occurring in the word processor. However, when the word processor does not hold focus, key strokes are not entered as characters in the document. An example of a global mouse listener would be in the mouse art shown previously. Although I do not know their source code, I would expect this to use global listeners to recall mouse movement and key strokes when the window is not in focus.

Global listeners can be dangerous

Global listeners have the advantage that they can listen for events at all times during the life time of the program, regardless of whether it has focus or not. However, if multiple programs have global key listeners, all (or none) may respond to the key stroke event. Let’s assume you have coded that the escape key in your program will cancel the running thread. Meanwhile, another developer has coded that it will close your word processor without saving your work (some developers are just evil, right?). With both running global listeners, both may occur when the escape key is pressed, or the wrong one may take ownership and responsibility of dealing with that key stroke. This is why local listeners are preferred – it restricts which program will take ownership of that key stroke event.

Global listeners can be necessary

If your program is being built to continuously run in the background, then global listeners become a necessity to record actions for that program when it’s not in focus. Good examples of this are some parental control programs available which monitor the key strokes for all usage (used to monitor activity). The good ones run in the background without any visual indication that they are there and so never have focus, but need to record key strokes, mouse movements and other such events at all times. Similarly, they need to ‘listen’ out for a certain combination of keys being pressed as the password to turn them off or reveal them. In software like this, global listeners are the way forward. Other software also makes use of these, such as screen recorders, Skype, and the mouse art maker, where events need to be dealt with when their programs may not be in focus.

Conclusion

Global listeners need careful management to ensure the event they capture will not interfere with other potential global listeners for other software. Of course, one way of doing this is to make every key command convoluted, requiring three or four keys to be pressed at the same time, but good luck winning usability awards if that’s the case. Of course you might be a very good programmer and your software may be perfect with its global listeners, but someone else may not. The simile I would use here is the one used for driving – you may be the best and safest driver in the world, but you still need to account for, and take avoiding action on, the rest of the road users. The same goes for using global listeners. Be wary of who else might be using them at any one time. Unless you intend for your program to be used when it does not hold focus, use local listeners instead as a safer option.