I am working on a program that is supposed to simulate basic mouse input for a program while it stays in the background (meaning, I want to do other things in other windows with the actual mouse and keyboard while the target receives input). One thing I need to be able to do is move the mouse to a specific (x,y) point.
It seems to work for the most part, but in a certain region of the screen the message only works correctly some of the time. Other times, it moves to a consistent but wrong other point within the region. I am reading that sometimes it is relative, but if I spam the message repeatedly, it does seem to work consistently. Also, reading in Spy++, the messages that are sent by me actually moving my mouse are using what seem to be absolute coordinates.
My function is here:
void mouseMove(short x, short y) {
PostMessage(wnd, WM_MOUSEMOVE, 0, MAKELPARAM(x, y));
}
Preferably, I'd like for any (x,y) to be absolute so I can have the region treated as any other. But it would also be fine to set the position to a coordinate relative to the top left corner of the region.
I have tried just about all of the messages I've seen sent to the window in Spy++ before the WM_MOUSEMOVE but nothing is helping.
How might I approach this?
Edit, since details might not prove enough info:
I am sending these messages in this order:
WM_ACTIVATE 2 0
WM_MOUSEMOVE 0 MAKELPARAM(x,y)
WM_LBUTTONDOWN MK_LBUTTON MAKELPARAM(x,y)
WM_LBUTTONUP 0 MAKELPARAM(x,y)
I think what I initially thought (bad WM_SETCURSOR area) is wrong because Spy++ consistently shows HTCLIENT being used.
I have found a lot of people trying to do this (background input) and most seem to be told it's impossible. It's not impossible, and I think if someone can answer how to do this correctly once and for all it would be doing quite a few people a big favor.
Synthesizes keystrokes, mouse motions, and button clicks.
UINT WINAPI SendInput(
_In_ UINT nInputs,
_In_ LPINPUT pInputs,
_In_ int cbSize
);
PostMessage function. Places (posts) a message in the message queue
associated with the thread that created the specified window and
returns without waiting for the thread to process the message.
For PostMessage to work you need to be in the process as the target that you can achieve with SetWindowHook but the these links will do the jobs:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/ms171542(v=vs.110).aspx
Related
First off, what I wanted to accomplish: intercepting (via a low level mouse hook) WM_MOUSEHWHEEL messages to go back and forward in Windows' file explorer history, or at least to the parent window if access to the history weren't possible.
That was what started it all, not that I had any idea if it'd be possible or not, specially with a touchpad, but that was my intention. So I started looking at the more usual WM_MOUSEWHEEL (vertical scrolling), only to find out that those messages aren't being generated much of the time!
As per the MSDN docs on WM_MOUSEWHEEL:
Sent to the focus window when the mouse wheel is rotated. The DefWindowProc function propagates the message to the window's parent. There should be no internal forwarding of the message, since DefWindowProc propagates it up the parent chain until it finds a window that processes it.
Okay, looks good, so when the mouse wheel is rotated that message is sent to the window that has the focus. Let's see if that's the case with the help of Spy++ from the Visual Studio pack of utilities, made a recording of it and uploaded it to YouTube, embedding doesn't seem to be allowed in this Stack Exchange: https://youtu.be/YJvjw_BPJf0
Summing it up though, there's no WM_MOUSEWHEEL being generated for all of the programs tested. Explorer was the first one I tried to look at, focusing on the different sub-windows a window had and made sure it was scrollable.
I could see some related messages being received by the scrollbar section of it, but that's it, no sign of that message anywhere (however, VM_VSCROLL was posted to one of the windows of the scrollbar).
Next up was Notepad3, nada, its SysListView32 doesn't see anything and the parent window gets some notification, activation messages and the like but nothing scrolling related.
Everything's SysListView32 received some LVS_SCROLL messages but it didn't act on them (its message loop is probably looking for the darn WM_MOUSEWHEELs instead).
Finally a browser, nothing at all, the "view" didn't register anything at all while the parent window captured the mouse by the look of the events.
NOTE: For those of you who see the video, note that while Spy++ was on top it didn't have focus during all tests, it was merely pinned so I could see the messages.
I almost gave up, starting from the default example Win32 application they give you in Visual Studio I added a hook procedure and if that message was received it'd print a message box, just in case it was the shell the one getting the messages somehow.
There was my surprise when I ran the code directly in VS that I see message boxes when I scroll through the code. WTF?!
Fire Spy++ again (also 64-bit because it was the 2022 Preview I was running) and let's see, there they are!
https://youtu.be/ekrWKP7HiTE
The code editor sub-window is receiving those messages whenever I scroll vertically with the trackpad using two fingers. So, what is going on?
I mean, I even tried to run that sample code elevated to be at a higher integrity level and see if that'd make those messages appear, but to no avail.
The code is as simple as it gets, most of it was autogenerated as a sample Win32 application, but the hook and procedure are as follows:
// The callback procedure:
LRESULT CALLBACK mouseHookProc(int nCode, WPARAM wParam, LPARAM lParam) {
if (nCode == 0) {
if (wParam == WM_MOUSEWHEEL)
MessageBox(NULL, L"We got it!", L"Yay!", MB_OK);
}
return CallNextHookEx(NULL, nCode, wParam, lParam);
}
...
// Setting the mouse hook (at the application's entry point):
HHOOK mouseHook = SetWindowsHookEx(WH_MOUSE_LL, mouseHookProc, hInstance, 0);
if (!mouseHook) {
LPWSTR errorMessage = NULL;
if (FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), 0, (LPWSTR)&errorMessage, 0, NULL) == 0) {
MessageBox(NULL, L"Couldn't format the error message...", L"Error", MB_OK | MB_ICONERROR);
}
MessageBox(NULL, errorMessage, L"Damn", MB_OK | MB_ICONERROR);
LocalFree(errorMessage);
return FALSE;
}
Although I tagged it as C, it really applies to any language that runs in Windows and can access low level mouse events, be it managed or not.
PS. By the way, although the intention I mentioned at the beginning was the motivation that started it all, I reckon it's impossible to do. If vertical scroll messages aren't always generated even in scrollable controls, I don't see horizontal ones being generated when there's nothing to scroll. It'd need to be implemented in the File Explorer itself most likely.
I am currently messing around with the windows API in C. I thought it would be funny to make a simple chalkboard. Everything is working fine. It's drawing etc, etc.
The problem is that the contents are lost when the window is repainted/updated/resized...
I thought maybe I should save the HDC or something, but then I don't know how to put it back.
How do I solve this? I figured it shouldn't be a very difficult question to answer, yet I can't really find anything on google somehow.
You need to handle the WM_PAINT event and repaint the invalidated region in its entirety. That's what WM_PAINT is -- a request from the system to redraw a dirty region.
For your specific application it sounds like you should create an off-screen device context (CreateCompatibleDC), a corresponding bitmap (CreateBitmap) of the size of your canvas, do all the drawing operations there and call InvalidateRect on your window. When WM_PAINT fires call BitBlt to transfer the relevant portion of that bitmap to the screen.
I've got a drawing area inside a scrolled window (with convenience viewport),
and this drawing area updates itself according to incoming motion-notify-events.
When I scroll the area though obviously no motion events are emitted,
but I wanted to work around this, and so tried to connect the drawing area's
"scroll-event" signal to the same motion-notify callback.
The problem I'm facing here is that this signal is emitted before the scrolled window
has update its viewport, so in the callback, I end up with pointer coordinates that were true just before scrolling, making it look like the drawing area is always "lagging a step behind" the actual pointer when scrolling while not moving the pointer itself.
I thought I could compensate for this by manually extracting the coordinates with gdk_window_get_pointer, but then I realized this cannot work as the pointer is technically still at its old position when the callback is commencing.
I also tried using g_signal_connect_after in hopes it would have the callback get called after the viewport was scrolled, but it didn't help.
My last hope would be to start a timer on scroll-events, and have the callback fire after a minimal amount of time, but this sounds realllly ugly, and I'd like to avoid that at any cost.
Any ideas as to how this could be realized?
Thanks in advance!
A solution would be to connect to the "value-changed" signal of the GtkScrolledWindow
adjustments.
Source: https://mail.gnome.org/archives/gtk-app-devel-list/2011-September/msg00014.html
When sending the WM_MOUSEMOVE message to the client area of an application (in this case Open Office Writer) the image will flicker as if the mouse is over the specified coordinates, but does not stay in that state. The code is:
PostMessage(hWndClient, WM_MOUSEMOVE, 0, MAKEWORD(x, y))
where x and y are relative to the client area.
Sending this in a loop still does not work as the area highlighted by the mouse over event will just flicker.
Any help would be appreciated.
The app could be triggering on all sorts of other events. Maybe it wants to see WM_MOUSEHOVER etc... It's been long a while, but I remember there being something really klugy about how some of these events were implemented - like there was a separate thread that polled the mouse and generated WM_MOUSELEAVE events when the mouse was no longer over the window. You could be getting bitten by something like that too. It's also possible that the application itself is polling the mouse for its true position when it receives the event.
Depending on what you're trying to do, perhaps you could programmatically move the mouse instead of just trying to fake events. Unfortunately, I don't remember the API for this, but I'm sure it's possible.
I used sth like this in my main window and looks that helps... in WM_MOUSEMOVE:
POINT Point;
GetCursorPos(&Point);
ScreenToClient(hHwnd, &Point);
int X = Point.x;
int Y = Point.y;
Try this: PostMessage(hWndClient, WM_MOUSEMOVE, MK_LBUTTON, MAKELONG(x, y)), since postion is a 32-bit integer, the lower 16 bit is x, and the higher 16 bit is y, maybe you should use MAKELONG instead of MAKEWORD.
Check WM_MOUSEMOVE.
I have a WPF app which snaps to screen edges (I just set the .Top or .Left of the window if you're within 20 pixels of the screen edge), but I recently added some code provided by the WPF SDK Team to "mess" with the window chrome, and although it's working great (screenshot), it's causing the "snapto" to move the window unexpectedly (e.g.: it jumps to the left when it should be snapping straight down to the bottom)
I've narrowed it down to their handling of the WM_NCCALCSIZE ... which is really odd because they basically don't do anything, they just say they handle it, and return 0.
According to the documentation of WM_NCCALCSIZE, this should just result in the whole window being treated as client (having no non-client edge), but somehow it also means that whenever my snap-to code moves the window down to the bottom of the screen, it also moves left about 134 pixels ... (moving to the other edges has similar side effects) and as long as I hold the mouse to drag it, it flickers back and forth from where it's supposed to be. If I comment the WM_NCCALCSIZE handling out, the snap-to works the way it should (but the form doesn't look right).
I've tried everything I can thing of in the WM_NCCALCSIZE handler, but I can't stop it from jumping left ... and of course, WM_NCCALCSIZE only gets called when the window size changes, so I don't understand how it causes this in the first place!
P.S. If you want to actually see the code, it's already on CodePlex, in two files, look for _HandleNCCalcSize and OnWindowLocationChanged
The reason this happens is that handling the WM_NCCALCSIZE changes the overall size of the window ... but if you're moving the window, changing your position during WM_MOVE or WM_WINDOWPOSCHANGED (which corresponds to the WPF WindowPositionChanged event) causes another WM_NCCALCSIZE message ...
Making changes during WM_NCCALCSIZE (even just asserting that you handled the message) causes another call to WM_MOVE ... which puts you into a loop where the "FROM" part of the positionchanged message stays the same (making the window "jump" from where it started to the position you adjust it to during WM_MOVE over and over as it changes back after WM_NCCALCSIZE).
The Correct Way
What you have to do is to obey Raymond Chen and handle WM_WINDOWPOSCHANGING instead. It happens before these other messages, and that way they do not interfere with each other!
The wParam always seems to be TRUE (1) and lParam is a NCCALCSIZE_PARAMS ...
The intent is to do exactly what you said: to force the whole window to be "client" and then use the Vista DWM apis to extend the frame into the client area. I just don't see why it's moving so far to the left...
If I trace or breakpoint the HandleNCCalcSize method, when I resize the window (while it's on the edge so the snap-to fires), the NCCalcSize gets called twice: once where it should be, and then off to the left, where it ends up.