[Resolved] Simulating keystokes and focus issues (virtual game pad for tablet UPC)

Edit: I finally found something that works! Hooking the mouse, preventing actual mouse clicks when the mouse is over the control form and calling the click events manually did the trick :D

I've recently been working on a virtual game pad to be controlled by a mouse (or more likely a touch screen on a tablet UPC). It is nearing completion and works exactly as I had hoped except for one issue. I created a topic about it in the VB6 section though as of yet I havn't found a working solution. jemidiah suggested I consider porting it to .NET if anyone here can give some insight.

Quote:

---

Originally Posted by Me, other topic

I'm using the keybd_event API to simulate keystrokes on the target application. It does the job rather well, except for the fact that keybd_event requires focus on the target in order for it to work, and with the application I've used for testing (Project64 1.6) and assumedly other applications, the keys that are simulated are lost every time the target application loses focus, which happens quite a lot, in fact every time the virtual pad is clicked to press another button.

This isn't an issue in most cases, however if a virtual button has been set to hold down (by clicking on it and dragging away), clicking anything else will make that key get released, at least until it resends all of the ones that are supposed to be held down. Even then it isn't always an issue, but for example if I'm using it to play Mario Kart and I want to hold down a banana behind me, as soon as I try to steer or anything else it will be let go.

---

Failed solutions:
Using postmessage (doesn't require focus) rather than keybd_event
- Sends keystrokes to file menu rather than game, sending to child hwnds doesn't work either

Bringing target window to foreground (using setforegroundwindow or setwindowpos) during the WM_ACTIVATE event
- Still loses keystates as when it is brought to foreground during a click event and prevents click events on the form from activating (so buttons don't work either)

Disabling mouse clicks on the form by using SetCapture Me.hwnd during the Form_MouseMove
- Prevents form from getting focus however does not prevent target window from losing focus

Possible solutions:
Hooking the target window and setting back to foreground during the event where focus is lost eg WM_KILLFOCUS
- Tried by calling this c++ .dll and this one but I was unable to catch this event or even the WM_ACTIVATE event for some reason, though some other events were working and the events I needed were showing up in spy++ for the same window

Hooking the target and canceling the WM_KILLFOCUS
- Same issue for hooking target as previous solution

Disabling mouse clicks altogether somehow while still being able to capture the mouse state (possible redirect to another key?) to program custom click events
- Yet to find code that disables mouse clicks but still allows mouse to move, etc. Tried useing SetWindowsHookEx with WH_MOUSE_LL and could catch events, though I have no idea how to cancel the damn things...

So, does somebody have an idea?

Original topic
Source code

just a quick fyi, keybd_event will require your program have administrator access.

also fyi, if your target program is a game, there is a good possibility the program is receiving keyboard input from directinput, and postmessage (and sendmessage) won't work because when you write a program in those languages, you actually have to add code to receive those messages, and it's redundant with directinput. You might find your program works just fine with a different sort of program, such as notepad. The reason keybd_event works is it works at the driver level and the OS sees it as an actual keypress.
I wonder if you could check to see which window was in focus after each click, and give that window focus again before sending the keybd_event? You could even have the z-order of your virtual pad set so it is always on top and turn the border off so you don't get an annoying flicker.

edit: here's another idea: If your program only uses the mouse for input, you don't actually have to ever have focus to read the mouse presses. Hook your own program and block it getting focus and read the mouse clicks/location with api calls.

It already refocuses the target window each time you click the form, but unfortunately this doesn't prevent the keystates from being lost. I've already considered subclassing to try and prevent the form from getting focus but the problem with that is I don't know how...I tried this code and setting the uMsg to 0 (WM_NULL) whenever WM_ACTIVATE/WM_ACTIVATEAPP/WM_SETFOCUS/WM_KILLFOCUS occurs but it has no effect. If you know how to do it or know what I'm doing wrong that would be great :D

And yet again the frame flicker issue comes up...I've had an option for that since before my first topic :D Trust me, I've thought this through...I'm actually trying to do a good job of it.

Quote:

---

Originally Posted by xXSnowyXx

It already refocuses the target window each time you click the form, but unfortunately this doesn't prevent the keystates from being lost. I've already considered subclassing to try and prevent the form from getting focus but the problem with that is I don't know how...I tried this code and setting the uMsg to 0 (WM_NULL) whenever WM_ACTIVATE/WM_ACTIVATEAPP/WM_SETFOCUS/WM_KILLFOCUS occurs but it has no effect. If you know how to do it or know what I'm doing wrong that would be great :D

And yet again the frame flicker issue comes up...I've had an option for that since before my first topic :D Trust me, I've thought this through...I'm actually trying to do a good job of it.

---

i've never done your exact situation, but if you write the hook correctly, all messages go through your program and get passed on with callwindowproc. You don't have to set anything to zero. If it was a message i wanted to block, i just didn't call the default callwindowproc at the end. Nowif i am not mistaken visualbasic won't actually let you hook an external program, and this may be why you haven't gotten that part to work. This could be the main issue since windows sends messages to both the new window and the old one.

i know this was an issue with vb6, but i am not sure with vbnet. I am sure this is why you couldn't get it to work in vb6.
http://www.vbforums.com/showthread.php?t=314119

I guess that code isn't written correctly then...I tried that and it doesn't work either. I guess I'll have to find something else.

And no, VB6 doesn't allow for external hooking AFAIK, which is why I use the C++ .dll used by an custom control in the VB6 app. It does work, but its not catching all of the events which is the problem with that. I'll try that one you posted though...I tried that one first but couldn't get it working, though that might have been because I was using it on an x64 notepad (the other one only works on x86, so this might be the same)

Edit: tried with old notepad, works for detecting right click but I havn't got it working for focus changes yet. I'll have another go later.
Edit: Nope, same issue as previous .dll. Tried it on Notepad and Project64 and it simply won't detect any of the possible events that I could use for whatever reason, though it will detect some others, and spy++ detects everything...

bump for still unresolved

bumping is not only unnecessary in the general pc forum (posts are rare in general), bumping in general is actually frowned upon by the forum moderators since it inflates your post count. i wish megatron was still on the forum to help you with his code, but he vanished years ago.

I wouldn't call it unnecessary...every page of topics it falls behind, the less likely anyone is going to see it and help with my problem :(

Quote:

---

Originally Posted by xXSnowyXx

I wouldn't call it unnecessary...every page of topics it falls behind, the less likely anyone is going to see it and help with my problem :(

---

for some reason i was thinking this thread was in general pc. The .net will flip a page every day or two, but on the weekend, you aren't going to get any replies. Most of the gurus on there are off weekends.