I am working on a application that involves remote control. The keyboard and mouse state gets updated about 100 times a second, saved on arrays, sent on the internet, and reproduced. Perfect reproducing timing is required. Since now I only coded the keyboard part and it was actually easier to program than windows messaging. All I had to do is call GetAsyncKeystate every 9 milliseconds on the host, and then, on the client, use SendInput every 9 milliseconds to get perfect timing. The other side of the medal is, I will have to manually check if the host window is highlighted, and if is not, avoid calling GetAsyncKeyState. But now that i'm about to code the mouse part, I have a doubt about what method to use, since perfect timing for mouse will be difficult to achieve even without window messaging. That's why I am asking to programmers that are more experienced than me:
In this case, is it better to use a combination of GetAsyncKeyState and GetCursorPos or is it better to use Windows Messaging? What are the positives and negatives of both? Thanks in advance.
You'll want to use a Windows hook. See SetWindowsHookEx and related documentation. This can be used for keyboard events as well.
On recent Windows versions there is also a newer, asynchronous input capture technology available whose name escapes me at the moment. Google for that as well.
EDIT:
I remember now: The other technology is known as event hooking. See the SetWinEventHook function.
GetAsyncKeyState and GetCursorPos is your best choice. The simpler the code, the faster your program will be able to be. Considering that sending windows messages through functions like SendMessage() gives you the option to fiddle with a lot of different aspects of different programs, this usually means that there are more processes happening inside the SendMessage() function and that speed is taken away in order to provide practicality for other applications.
I would also like to point out that you will never be able to get perfect timing since you are in fact collecting data from the source computer, passing it to an array and sending it online.
Summary:
Pros of using GetAsyncKeyState and GetCursorPos:
You won't find any functions retrieving data faster than these functions given that they are functions that only look to do small basic tasks. SendMessage type functions will be slightly slower since they have more coding inside them, allowing them to work with more than just mouse and keyboard functionality.
Cons... I don't really see any.
Related
I want to know how I can receive the event of a middle mouse clicked in C++. Is there anyway to do so? If there is, how exactly can I implement this? I've read online that I can use WM_MBUTTONDOWN however I am really unfamiliar with using this and I've been told that it is indeed not even part of C++.
WM_MBUTTONDOWN is defined as part of the Windows API. It is just an integer value that's recognized by the operating system. You can use C++ to compile a Windows application, although the language doesn't matter in this case.
A typical Windows application has a message loop. When a message is received by your application, you can decide what to do with it before passing it back for the next application to handle.
I recommend reading the Forger's Guide.
i'd like to make a function that can move a window in Linux in C++ by its PID. So I've tryed in under Windows. But I have trouble to compile it for Linux.
Is there any mean to do it with Qt ? Since I haven't found one, I've tryed to compile for Linux.
I'm using the MoveWindow function, which is part of the Windows API. Is there any Linux equivalent ?
You don't have to do that by hand if you don't really want to as there already are lots of tools out there, that can perform such tasks as moving, resizing, maximizing and whatever windows.
One tool you might want to take a closer look upon goes by the name of wmctrl even if you don't intend to use maybe you'll find some interesting tricks by taking a look into the sources.
The task of moving a window only known by the pid of the client that created the window might not be the easiest tasks of all for a couple of reasons.
First of all you really shouldn't try to do this as in the X Windows philosophy it is the job of the window manager to arrange the windows on the screen.
As well ICCCM (see: http://de.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual) as the EWM spec (see: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html) strongly discourage any client from trying to move resize or whatever on its own. Most probably moving windows "owned" by another client might be considered even bigger evil.
The second problem you might face is, that the X 11 protocol doesn't have any notion of pid.
As it was designed to be used over a network you never can't be really sure the program runs on the same machine as the one you are currently sitting in front of. As such there isn't much sense in something like a pid as by chance there might be any number of clients with identical pids displaying windows on the same X Server if they ran on different machines.
Fortunately enough it is not all that bad, as the EWMH spec encourages any client to set the _NET_WM_PID property on its top level window the the pid of the client that created the window.
Again adhering to the EWMH spec isn't enforced by the X Server in any way so that while practically propably almost all clients will set it there's still no guarantee you'll find the window belonging to a specific pid.
Possibilities
While the whole points mentioned until here might seem rather limiting in fact most probably rather the opposite is true. Even because practically it is relatively easy to totally mess up any other client running in an X session the whole set of rules about how to be a good citizen in the X word were introduced.
As the X11 protocol itself is a network protocol (well not 100% true as locally running clients most probably will be communicating with the X Server via a UNIX domain socket) there isn't any specific library required to talk to the X Server.
Talking about C as mentioned in your question the Xlib has long been the one and only one implementation in wide use but there's also another binding called xcb. With a slightly changed API in comparison to the Xlib.
Xlib
Speaking Xlib I've never ever used any xcb until now, so I can't tell you too much about it might be the following methods that might be of use.
XOpenDisplay - open connection to the X server
XQueryTree - aquire the tree of windows currently alive on the server
XInternAtom - no fear it isn't dangerous. Just read about it in the manuals as you'll need it the get the "atom" mapping to _NET_WM_PID mentioned above
XListProperties - search for the _NET_WM_PID property with the value you are looking for
XConfigureWindow, XMoveWindow, XResizeWindow, ... - to finally perform whatever you wish to do.
All functions mentioned above should be documented in the manual pages. Just use man XOpenDisplay for example.
Oh, and be sure to learn about all the other tools at your disposal to further investigate about the X Window world. Run xlsatoms, check what xwininfo reports an take a list at the output of xprop for one single (!) window alone. Try to set some yourself to see what happens xprop will even do that for you if you ask politely.
I am working on an automated testing library, and want to simulate mouse and keyboard inputs using the SendInput Win32 API. This API allows one to push several input items in a single call to the API. There are a number of other examples and similar libraries throughout the web using SendInput. Many of them pass a single input operation for each call to the API. Is there any advantage to batching inputs, or using a single input per call to SendInput? The documentation doesn't seem to offer guidance, or perhaps I'm misreading it.
There's no real benefit to one technique vs the other that I know of. In either case, the usual potential problem with SendInput is that the input focus could change between when you send the input and when the input is received by the target application. The classic example is a modal dialog appearing asynchronously to alert the user of some problem, and ends up stealing focus, and soaking up the remaining input that was supposed to go elsewhere. There's no difference between doing a successive series of SendInputs vs a single SendInput in this scenario.
(I'm pretty sure that internally, SendInput is just looping over the inputs passed to it anyway...)
I'm implementing a touch interface for Windows in Win32 (C++). I would like to find out the current double-tap (not double-click) speed that Windows is set to. I know Windows is set to accept double-taps as various messages (depending on whether you're using gestures or not), but I'm looking at doing something a bit more advanced. I'm thus handling WM_TOUCH messages. I'm hoping there's a better (i.e. future-proof) way than rummaging through the registry to find that setting. MSDN wasn't helpful.
Since there doesn't seem to be a specific double-touch notification, I suspect the application is expected to decided for itself if a WM_TOUCH is part of a double tap. The most common way to do that is probably to check the timing between touches. By default, I'd imagine that most apps use the mouse double-click setting as the default.
GetDoubleClickTime
How can I completely disable the keyboard using c++ in windows? And by completely disable I mean so even Ctrl+Alt+Delete doesn't work. I did consider using a keyboard driver but I think you need to restart the computer after it is installed, but since I only need to disable it for a couple minutes that wouldn't really work.
This is not really possible.
WinLogon is designed as the one process that intercepts the Ctrl+Alt+Del key press, even when all other things hang or die.
This is the failsafe against malicious sessions, etc. So there is no obvious workaround.
Maybe a keyboard filter driver would make your request possible, but that is a real kernel-driver.
You can't disable Ctrl-Alt-Delete without removing the keyboard or replacing the keyboard driver, it generates a kernel level notification.
You could use BlockInput function. But it doesn't block CTRL + ALT + DEL.
You could install a keyboard hook and filter out the messages, but you might need to have your application as the top most window. Even then Ctrl+Alt+Del would not get filtered out.
Here's SetWindowsHookEx on MSDN
Example of Hooking the Keyboard
Ok, here goes several random suggestions. I don't have a definitite answer, but here's where I would start:
1) SetupDiRemoveDevice is probably the API you want to call. Although to call it, you'll need to make a lot of other device enumeration calls. Enumerate your HID and USB devices and find the keyboard. Start by looking for the VID/PID of the actual device for starters.
2) Delete the drivers kdbclass.sys and kbdhid.sys. You'll be fighting Windows system file to do this. I have no idea if this will work, but sounds interesting and simple.
3) Write a USB filter driver. Your driver will need to know (or be passed) the vid/pid of the device to filter on, but it might work.