How do i prevent a mouse from sending input to DirectInput game? - c++

This question was originally about how to trap mouse events, which i solved after a lot of research using SetWindowsHookEx with C++.
Problem is, its working for me on Windows, it works in applications, but it doesnt work in games.
can somebody help me understand why the mouse hook doesnt work in some games? could it be possible all the games i tried use Raw Input? :S
(i tried Ibb&Obb, Fallout 4, Metro Last Light and some other titles)
Basically im asking: how is it possible to use a Mouse Hook to trap it globally in all the applications running?
thanks for the helpers.
EDIT : I found out that most games i play use DirectInput. guess the better question is: How can i intercept mouse messages in DirectInput and prevent them from being registered by the game? i want to be able to drag the mouse and it would have no effect on the game.

after a lot of research i found out that, from what i understood, API Hooking (Microsoft Detours, API Hijack and more) is the only way to do it.
Important note: it doesnt help me much since API Hooking for games require DLL injection which will get you banned from Steam and other platforms.

Related

Prevent other windows from "overriding" hotkeys with the windowsAPI

I'm trying to learn the basics of the windows API by making a program that, when the PRINTSCREEN button is pressed, will save a .jpeg and instantly upload it to imgur. Currently, while I'm playing most games or just browsing the desktop, this program works fine.
Some games, however, seem to block my ability to use this hotkey. (Dark Souls 2 specifically does this.) I currently use
RegisterHotKey(NULL, 1, 0, VK_SNAPSHOT)
to assign the button to my program. However, when some games are running, neither the above RegisterHotKey nor the below GetAsyncKeyState work when the key is pressed.
GetAsyncKeyState(VK_SNAPSHOT)
(I don't want to use GetAsyncKeyState due to the fact that it will keep bugging the windows API and make the program unnecessarily slow, it was just for test.)
Does anyone know of a way to stop this from happening?
(and, on an unrelated note: If it is a simple task, how would I take a screenshot spanning multiple monitor(s)? Mine currently works on only my primary monitor...)
If the application is using raw input for its keyboard mapping, then the keyboard processing code bypasses the hotkey checker. I personally have no idea if Dark Souls does this or not, but I am familiar with the Windows kernel code that does keyboard processing.

Low level programmatic keyboard emulation

I bought a physical button and hooked it up to my computer, using the Arduino it communicates over USB serial to a C++ program I'm writing. Now I want to make the button simulate a keypress on my computer so I could use it as an alternative controller for the games I play.
If you are not familiar with Arduino, don't mind it, my problem lies completely in C++
The solution for this is pretty simple, it basically boils down to using SendMessage to a window with keystrokes, or many alternative methods like sendKeys and what not.
I have tried every single library or windows function that could handle something like this, but none of them actually simulates a keystroke being pressed by a keyboard.
Everything I tried so far has worked in many programs like Notepad and Chrome but none works with a game that doesn't listen to windows messages to handle key input.
My guess is that these games use GetAsyncKeyState which is communicating with the physical keyboard in a direct manner.
How could I resolve this? What API provides such functionality?
I need something very low level here, maybe even a program that emulates a new keyboard so windows thinks I have plugged in a physical one.
This would help me ALOT I've encountered this problem numerous times and I will keep encountering it in the near future with other projects.
I hope someone can help,
Thanks!
Use keybd_event() or SendInput()

Mouse/Keyboard input in OSX without Cocoa

I am writing an application in C++ using CGL/OpenGL, and need keyboard/mouse input. I was trying to avoid Objective-C and Cocoa if possible. I am aware that one can capture input using Carbon, but seems that Carbon is slowly being phased out, plus it is not clear if it plays well with 64-bit applications. Does anybody know if there any other alternatives in OSX for mouse/keyboard input using C++ without going to something very low level (e.g. I/O kit)? Any code snippets to get me started?
Thank you-
Quartz event taps might do what you want. Without knowing why you are trying to avoid using the Cocoa event system it's hard to know what technology would be best for what you are trying to do.
Gaffer on Games wrote an article doing just what you want, context and surface creation with CGL and a minimal event loop (although it's a little out of date, for El Capitan you need CGLSetFullScreenOnDisplay())
http://gafferongames.com/2009/01/19/opengl-on-macosx/
It uses InstallApplicationEventHandler, one of the two keyboard APIs mentioned here:
Keyboard input on OSX

event handling in C++

I'm writing a game in C++, and I'm trying to get it to recognize keyboard and mouse events. Google tells me that boost.signal is suitable for event handling, but none of the code samples or tutorials I've found tell me how to associate a keypress or mouseclick with a function. Can anyone shed any light on this?
I think taking a look at SDL and it's SDL input subsystem might give you some hints. It all depends on what is the source of your keyboard and mouse events. Is it SDL? DirectX? If neither, then you're probably doing it wrong :).
The events that you receive will depend on the operating system you're using, and any frameworks that stand between you and the OS. Qt is a popular cross-platform framework, for example.
If you're not using a GUI library or other type of engine that already provide you input informations, a good library to just get inputs is OIS : http://sourceforge.net/projects/wgois/

Debugging GUI Applications in C++

Background: I'm currently debugging an application written over a custom-built GUI framework in C++. I've managed to pin down most bugs, but the bugs I'm having the most trouble with tend to have a common theme.
All of them seem to be to do with the screen refreshing, redrawing or updating to match provided data. This is a pain to debug, because I can't break on every refresh, and most of this stuff is time-sensitive, so breakpoints occasionally "fix" the bug.
Q: Does anyone have any tips for debugging Windows-based GUIs, especially regarding the refreshing of individual components?
I agree with dual monitors or even remote debugging to reduce interfering with the messages.
I also highly recommend Spy utilities. These let you see what messages are being sent in the system. One such program is Winspector.
http://www.windows-spy.com/
This may not help, but I've found using dual monitors useful in this scenario. I have the debugger on one screen and the application on another. I can then step thru the code and see the application refreshing or doing whatever it is on the other screen.
There is still issues with focus doing this way, but at least I can see when it repaints.
Logging is pretty much the only answer. Without knowing your framework I can't give an exact answer but basically open a file and append messages in the various procedures of interest. Finally close it.
In the message include the values of the variable that you are interested in.
Also using the window Message Box is useful to see if you are in the correct branch or procedure. This has minimal effect on over all flow.
Finally try downloading any of the express version of .NET and use Winforms to try to make test of particularly problematical areas. While Winform is it own framework there is a high degree of correspondence between it's control and the ones provided by Windows.
I maintain a simulation of the Project Mercury Capsule as an add-on for the Orbiter Space Simulator. It is written in C++ and has to use Win32 directly for some of the panels and dialogs. There were times I fired up VB6 (VB.NET later) to work out some complex interaction and then translated it over to it's Win32 equivalent in C++.
However this is a last resort.
Having a dual screen really help when debugging refresh/redraw problem for Windows controls and UI.
Having the application on the second screen will not have the debugger generate "invalidate" on the main UI screens when it breaks for a debugging breakpoint.
If you cannot have a second screen, try to have both application side-by-side so that the application and the debugger will not interfere.