I tested it on my ASUS TF101 10" Tablet and it worked fine, let me know if it works for you.
Re another one of you posts I've searched the Internet and cannot find a way to hide or programatically move the mouse pointer.
To hide the mouse pointer I created a new pointer_arrow.png (invisible) and copied it into the framework-res.apk replacing the pointer_arrow.png that is in there. To hide the bar at the bottom, I deleted the System_UI.apk file. Of course, the device has to be rooted. I haven't looked into placing the mouse pointer at boot time but one would guess it is in the firmware somewhere given that it is in the middle of the screen when it boots and I don't think that is an accident.
I suspect that I can do file manipulation with the B4ARootCmd library or maybe even with the file handling procedures? Although, a reboot is required I believe. So, a simple toggle function within an application isn't likely I'm guessing.
I tested the SWT1 above and I'm pretty convinced there is something up with the firmware for the device (Tronsmart T428) that prohibits the middle mouse button event from triggering. It is probably intercepted somewhere in the firmware? I have no doubt that it works on other devices.
Note: I've been experimenting with firmware tools and YIKES, that's a bit like drinking from a fire hose. Packing and unpacking, finding resources to manipulate and so forth. Not for the faint of heart.
I would encourage you (Stevel05) to publish the source of the SWT1 library and make it available to everyone. The ability to trap all the keys/mouse input events is potentially quite useful for many controller type applications.
While frustrating, it would be interesting to learn why the middle mouse button doesn't get through on my device with the firmware I have. Given the complexities of creating firmware, I suspect the middle mouse button is low on the priority list for a firmware developer.
Oh, one other thing - the right mouse button doesn't get captured, it exits the program and the action doesn't occur on the down event as expected? Maybe I'm not implementing correctly? At any rate, this isn't as simple as it seems and adapting the library to handle all possibilities, I would think, would be worthwhile...? Maybe not a commercially viable library, but an important one nonetheless and something I'm happy to support. I've discovered that there are some unusual things going on with event trapping and there are some confusing things with regards to where to put DoEvents for example. I've seen some undesirable side effects and don't fully understand what's going on. For example, I've had the app exit unexpectedly or hang and the problem went away when I eliminated a DoEvent... odd?