This project is for duplicating keyboard input sent to an application such as the World of Warcraft Client to all other World of Warcraft Clients nearby. The clients could be on the same machine or any machine on the local network that has this application running on it.
This application is not unique in what it does (duplicates keystrokes to all other like clients; even over a LAN). It is however unique in the aspect that it does not require any complicated setup. Run the application on each machine you have client program (game) running on and that (as they say) is that.
There is a "Key Setup" tab in the application for one purpose only. To enable and disable which keys to mirror to clients. This is because you do not want to duplicate every key; just in case someone is monitoring your network. This is especially true for when you are entering your username and password. You should certainly never enable every key that encompasses your username and password.
I occasionally Dual Box WOW (World of Warcraft) or LOTRO (Lord of the Rings Online). Originally I searched for a program to duplicate keys I push from one client to another. I could never find a simple straight forward program to use. Especially since I sometimes triple box as well and sometimes I use one or more machines. I searched for a program that would work across any combination of machines and clients. The only software I could find that was capable was very complicated to setup and get working. I wanted a program I could just run on my machines without complicated setups.
NOTE: Before anyone has a TOS cow; Multiboxing is not "BOTTING". Multiboxing in most cases is accepted and encouraged. "BOTTING" is completely unattended playing are is widely NOT acceptable. The two are completely separate and unrelated. In the specific cases of WOW and LOTRO; multiboxing is officially accepted by Blizzard and Turbine. But please do your own research before using any third party software for playing your mmorpg.
Using the code
The example project I will be including for this article includes several noteworthy .NET classes.
Included are RAW INPUT classes which will compile and work property for the 64-bit platforms as well as the 32-bit platforms. I have searched the internet extensively and I am not aware of any 64-bit dot Net RAW INPUT working examples at this moment. When I write an article on these Classes I will modify this article to link to it.
Included is a dot Net "Message Only Window"
class which is called
SimpleMessageWindow. It is a convenient single class which when instantiated (created); spawns a thread which calls
CreateWindowEx to create and house in the background thread, a simple message only window.
SimpleMessageWindow fires off up to four events; of course one being
OnNativeGetMessage which fires when it receives a message.
It is also noteworthy that the example project includes a
SystemEvents where only three system events are hooked up;
EVENT_OBJECT_FOCUS. However the class is a complete and clear example which can easily be edited to hook into any system event with minimal edits to the class.
Also noteworthy are Non-Blocking UDP Classes for broadcasting RAW INPUT information to other machines on a local network running the same application. These UDP classes are both the UDP client and UDP server. The duplication of enabled keys is done using UDP broadcasts; where all nearby machines will potentially receive the UDP packets. Those machines running the example project application will receive the packets. The application running on that machine will send keystroke messages to any clients running on that machine. There is also a class that monitors key_down versus key_up messages and ensure that a key_up message is sent in the case that a key_up message goes unnoticed by the application. This can happen for a few legitimate reasons. Such as some mmorpg games can utilize the cpu heavily at times. Or the very non-blocking nature of UDP packets means some packets may not be received; again especially if the cpu is under high utilization. The class
UDPKeyPost simply ensures that the client application receives a key_up message following a key_down message. In the case of a key being held down the application/raw input will send several key_down messages and each one will refresh the timeout timer which determines if a timeout key_up message should be sent.
Points of Interest
This example project uses
System.ComponentModel.BackgroundWorker for threading. Using threads for asynchronous event driven applications can be very dangerous and confusing. Keeping it simple with an elegant built in class works the best in most cases.
This example project also demonstrates how to test the length of an event
InvocationList in VB.NET like many readers have seen tested in C# but probably have never seen tested in VB.NET Below is an example for an event named
MyEventEvent is rarely documented and not a part of code insight. It is however a valid object; one that VB.NET creates for every event and it's name will always be the name of the event plus
Event added to the end. The
InvocationList can be tested for length; a length of zero indicated that no event handlers need to be called so the event does not need to be raised. Testing this in C# is much more intuitive.
If (Not MyEvent Is Nothing) Then
If (MyEventEvent.GetInvocationList.Length > 0) Then
The example project is in VB.NET. If there is interest I may port this application to C# as well.