I use GetLastInputInfo() to get the LASTINPUTINFO and check for idleness. This is used for client timeout in my program. Halfway through the set duration for timeout, a dialog will be displayed with a countdown.
It worked properly until now but recently, the timeout either doesn't happen or takes longer because once the dialog is displayed, 1-2 seconds in I will get a new event from GetLastInputInfo() and the timer will reset.
I've tried this multiple times and made sure I touched nothing but it still happens. Maybe it's worth noting, it only happens in some environments. In one computer there is never a problem and it proceeds to timeout properly. But in another, it will occur 100%.
I tried adding a GetMessage() check and found that a WM_MOUSEMOVE message is received at the time the timer is reset. I didn't move the mouse, though. I did find information that WM_MOUSEMOVE messages may be sent multiple times even if the mouse is not moving and that's why the position should be checked with the previous position. Is this somehow related to why I get a LASTINPUTINFO? For 30 seconds I do nothing and suddenly, a random WM_MOUSEMOVE appears.
It happens almost immediately after the countdown dialog is displayed so, by any chance, is a WM_MOUSEMOVE message sent when a dialog is displayed? If so, why did this not happen before? Was it just luck on the timing?
Are there other possible causes as to why I get new input events even if I am nowhere near the mouse/keyboard/computer in general?
I'm having a hard time with GLFW's input system, figuring out how to make it work the way I want it, so I've come to people with more experience for wisdom. Using GLFW 3.
There are 3 states 0 Release, 1 Press and 2 Repeat. This is exactly what I would want, only, the key state from Press to Repeat takes about a second to change. Ideally, I would want it to have a state "Press" only for 1 frame, and then change into a repeat state.
The goal: Be able to easily call functions based on what state my key is as follows:
press Tap (do once)
repeat Continuous (do every frame)
release Don't respond
LINK
Please have a look in the files on the link above, and let me know if there's another way around it. Or is the approach itself rubbish, the way I do it? Thanks guys, all feedback and help appreiated.
One way is to simply ignore the "repeat" event, and only go with the "press" and "release" events.
When you get the "press" event set a flag, and clear the flag on the "release" event. Then simply check this flag every frame.
It is very important that there is a delay between "press" and "repeat". Most human beings are incapable of pressing and releasing a key, such that your game only registers the key being pressed for exactly one frame. And the few who are capable of that cannot do so consistently, with any accuracy.
So a user will never be able to "do once". They will be doing it for multiple frames. That's generally bad.
Also, there is a conceptual difference between pressing, holding, and repeating. Holding is just what happens when you hold down the key. Repeating is a facility that is governed by the OS (which is why GLFW doesn't give you a way to set the repeat rate). Key repeating is typically meant for text input (which GLFW takes care of for you anyway via its text-based callback).
Essentially, you should ignore it. In a game situation, a key has 4 possible useful states: not pressed, was just pressed, being held down, and was just released. You can infer this from the button's previous state (which you can store) and the button's current state provided by the callback.
If all you want to do is take an action when a button "was just pressed", then you need to know that the button was not pressed in the previous frame. If the key is pressed now but not in the previous frame, take the action.
Using Qt4.8 on a Mint Linux 12, I implemented a simple window containing a QTableView to show contents of a model. The model data is continually updated (log messages) and the dataChanged() signal is emitted on a regular basis (i.e. every 100ms).
The problem I see is stuttering visual updates on the table.
I installed an event filter on the window that counts updateRequest-type events, which should trigger a widget repaint (also on child widgets, i.e. the tableView). These come in with an average time of ~170ms between them and a standard deviation of ~90ms (which is rather large, I guess). However, the perceived visual update rate is only two or three times a second and I wonder why. It seems that not all updateRequest events trigger a widget repaint or that the window system swallows visual updates.
As a second test, I forced the window to update itself by calling repaint or update every 100ms. Using repaint, I saw a corresponding increase in updateRequest-type events and a decrease of the standard deviation of the gaps; with update, the number did not increase. However, there was only a moderate increase of perceived update rate in both cases.
Also: Is there a good method to measure how often a widget is actually really repainted without having to overload its paintEvent handler? Maybe something from QTest?
Update: I extended my event filter to also catch paintEvent-type events. There are only a one-digit number of those versus > 1000 updateRequest-type events.
You should instrument the event dispatcher's aboutToBlock() and awake() signals, and measure time between them using a QElapsedTimer. The instance of the event dispatcher for the current thread is returned by the static QAbstractEventDispatcher::instance().
If the event loop sleeps for a very small fraction of your time measurement window, it means there's too much stuff going on in the GUI thread. You can keep a count of how long the event loop slept, say, during the last second. If it's below 10%, you can expect slow updates and whatnot. Remember that update events are queued with Qt::LowEventPriority. They will be preempted by standard queued signals and almost all other events.
QApplication::compressEvent discards QEvent::UpdateRequest, if there is already one unprocessed. Thus even repaint(s) can return immediately without painting, if the event is discarded. You can check, if your updateRequest events are discarded by overwriting compressEvent.
How to know if a mouse click is simulated or not? When mouse click send by a program or real mouse device
... I'm programming a system detection for a game to avoid bots, autoclicks,etc that only accept legit mouse clicks
This depends a bit on the kind of application you are writing, but if you can, I would watch the cursor movement, not the clicks.
Human mouse movement has non-uniform speeds, reaction times, imprecisions (clicks on different coordinates of your buttons, etc...).
Also, you can defend a gui against bots by randomly requiring an interaction that is hard to script. For example: If scripts depend upon buttons being always in the same position, I would make sure that, while trying to remain intuitive, the dialog should pop up in slightly different positions every time.
Otherwise: There is no way to detect if the mouse is a real one or a really well simulated one. The Windows HID/MacOS/Linux driver layer abstracts away the distinction between Mice, TrackPens, TrackBalls, draw-pads, touch screens... and of course script-mice...
Although the blog post itself is about a different issue, I refer you to Raymond Chen's excellent Old New Thing. In this specific blog post he talks about the validity of message parameters going into an application, but also makes the point that:
There's no point discussing the possibility that the sender of the message is playing tricks and lying to you because (1) your program should just go along with the ruse and respond to fake menu messages as if they were real menu messages, because (2) there's no way to tell that you're being lied to anyway. To detect lying, you'd have to be able to read into the mindset of the programmer who sent you the message.
Essentially the argument is that you should respond to mouse clicks as mouse clicks, regardless of how those clicks were generated.
Is mouse keys simulated mouse input or legit? The point of simulating mouse input is to make them look exactly like real mouse input. If the simulation is doing its job, then your job is impossible. Sorry, that's the blessing & curse of software for you. Here are some more imperfect ideas:
Use GetKeyboardState and verify that the button states are correct. If the message faker is using PostMessage, they will likely not be setting keyboard state and this would indicate fakery.
If you are targeting known applications that are doing the input simulation, detect them and complain. This is not perfect at all for many reasons.
Fuzzy logic, as many other people have suggested.
You need to be creative and figure out the difference between a simulated event and a real one to you, as there is no generalized answer.
It can't be done (reliably (with software alone anyway))
I've used WIN32API calls to read pixels/manipulate the mouse/send keystrokes to automate large portions of video games and other repetitive tasks. You could write a lot of code to analyze the input, but equally smart developers are just going to modify their code to match.
When I first try to automate a mouse click, that's all I'll do. Send a mouse click. And most of the time it works. You might have code that tracks the mouse movement and the entire stack of mouse events that would fire along with a legitimate click and say, 'That wasn't real - we ignore it' but nothing stops the developer from also implementing mouse movements.
The mouse events are more complex than keypresses; but it's essentially the same idea. If you write code that monitors the time between keypresses and determine that I'm sending the '2' key to your application in EXACTLY 250ms intervals, you might decide I'm a bot. But, all I'll do is modify my code to send the keystroke in 250ms + a random value between -25 and 25 ms.
It's a never-ending game of cat and mouse. The best solution is to make tasks non-trivial so simple forms of automation aren't applicable.
The question is a bit thin on details.
Events can be sent directly to controls without moving the mouse so find out where the mouse is when you get the click event and see if it's on the control. Keyboard input requires control focus, so check that too.
For situations where the mouse moves, you won't be able to tell if the mouse movement is recorded and played back. If its scripted then perhaps you could monitor the mouse behavior in the parent panel(s) of the control and use those events and movements to ascertain whether it is real or not. An automated click might appear from nowhere and cause an flurry of unlikely hover, focus events.
Only way it would be possible is with some specialist hardware and software on the mouse itself that sends evidence of the actual mechanical click. Via software this is not possible.
Although in my other answer I mention that you should ideally just respond to clicks as clicks, there is one possibility that could work, depending on how a "programmatic" click is generated.
I am assuming a Windows platform, due to the "vb.net" tag:
With the WinAPI you can send a message to any window in order to simulate, for example, a WM_LBUTTONDOWN event. In this message you would include the X and Y location of the mouse at the time the button was pressed - or where the receiving program expects it to be. When you handle the message you could use the GetCursorPos call to get the actual cursor position. Verify that the current position is close to that in the message, and handle it as a click, otherwise ignore it.
Bear in mind however that the nature of the message queue is such that it could take some time to handle the event, and the mouse can move a long way in a short space of time.
This solution would only work if the "click" is generated by a simple Send/PostMessage. If the application that is generating the click simulates the movement of the mouse also, then you should probably see the other answers :)
You can check the mouse event flags LLMHF_INJECTED and LLMHF_LOWER_IL_INJECTED or utilize input hooks to monitor mouse input data, where malformed data may indicated that input was injected.
https://learn.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-msllhookstruct
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa
I'm not sure there is a way to determine with perfect accuracy whether a mouse click is automated or not. I mean, you could write your own USB driver that sits in between the native mouse driver and the OS and relays only "real" clicks to you. However, even that can be defeated by plugging in a USB device (like a smartphone) that's programmed to send USB packets to host computer.
What are you trying to accomplish that requires you to distinguish between real mouse clicks and fake ones?
Create a statistical learning solution by logging the past X mouse events in your program. When the user clicks on the control, determine the probability based on the last X actions that it's a real click.
Train your solution using real clicks and a large variety of automated scenarios.
This is obviously not a guaranteed-to-work solution and is more for fun than anything else.
It is much more harder than what you think because input macro programs produce legit mouse and keyboard input messages to your game. I don't think there is a way to check if the input message is actually triggered by a physical hardware input (like mouse or keyboard) unless OS provides you with accessibility of input-driver-level.
Since this is specifically for a game, you can see how other games handle this situation. Some of the common methods are,
Check frequency of mouse clicks. (human beings cannot click as fast as programs.)
At random points or when it doubts, use CAPTCHA to verify. (Read this: http://www.threadmeters.com/v-1Vvd/CAPTCHA_The_Obvious_AntiBot_Solution/ )
Use outside monitoring tools to inspect all processes running in a machine to find out programs known for cheating purpose. Steam does this. Check Valve Anti-Cheat System Blizzard's WoW also does the same thing with Warden.
My own advice would be "Use your gameplay system". Since every game has its own rules and gameplay styles, it wouldn't be too hard to detect whether a player is cheating or not. This approach won't be a general solution and it could be silly but if it works for your game, why not? :)
There are two ways you could work around this problem.
Make a new Button with a Text proving that the user isn't AFK and if the user doesn't press the button, kick him or her out. Generate the button in random locations.
If the user isn't moving for a while, (for example, 10 mins) kick him or her out.
Basically, when one types, a keydown event happens. If the key is held for more than a certain time (~1 sec) then the key is repeatedly pressed until keyup hapens. I would like to change the time it takes for the key to be automatically repressed in my c++ application. How can this be done?
Thanks
The speed at which a keypress becomes automatically recurring is controlled by Windows.
If you want to manipulate automatic recurrences of key-presses, it might be more advantageous to poll for the state of the key rather than waiting for the keydown event. It depends on how responsive you need your application to be.
This article may help you in figuring out how to query for key states: link
You can use the SystemParametersInfo function to change the keyboard delay and refresh rate, as described in this newsgroup thread.
A simple way to handle this is to establish a buffer of time around the OnKeyDown event. Setup a timer that determines whether control passes to a secondary event handler. If the timer has expired, then it is OK to pass control. If the timer hasn't expired, then you should return and leave the event unhandled. Start the timer right before passing control to your secondary event handler.
void KeyDownHandler(...)
{
// ...
if (TimeLeft() <= 0)
{
StartTimer();
handleKeyDown();
}
}
A timer is better than counting duplicate events because you can't assume that a given system will have the same repeat rate set as yours.
I agree with Stuart that polling for the state of the key might work better. It depends upon what you are trying to accomplish.
Also note that this type of behavior might be highly annoying to your user - why do you need to ignore duplicates?
You might be able to tap into a Windows API but this might be controlled by the OS. Not sure...
You might need to manually draw a command such as to simulate a key press multiple times after a set number of seconds after the key has been pressed.
Use SetKeySpeed api (Kernel)