CODEWITHSUNDEEP
c++winapi
CodeCat
CodeCat

Reputation: 171

How to move mouse in background window?

I want to use keyboard and mouse in background window(the window is a dx window).

HWND myhwnd = GetForegroundWindow();
PostMessage(myhwnd, WM_KEYDOWN, 0x33, 0); //press "3"
PostMessage(myhwnd, WM_KEYUP, 0x33, 0);
LPARAM lParam = MAKELPARAM(300,100);
PostMessage(myhwnd, WM_MOUSEMOVE, 0,lParam); // mouse move
PostMessage(myhwnd, WM_RBUTTONDOWN, 0,lParam); // mouse click
PostMessage(myhwnd, WM_RBUTTONUP, 0, lParam);

Press "3" and mouse click is success.But I failed in moving mouse.

Upvotes: 0

Views: 2892

Answers (2)

IInspectable
IInspectable

Reputation: 51503

WM_MOUSEMOVE messages are generated for the window underneath the mouse cursor regardless of whether it is the foreground window or not. WM_MOUSEMOVE (like WM_TIMER or WM_PAINT) messages are not posted to a thread's message queue. They are generated on the fly when a thread's message queue is empty and the thread calls GetMessage. If a window does not appear to be receiving WM_MOUSEMOVE messages it could be because the message queue is never fully drained.

Redirecting keyboard input is a very weird concept. Users expect keyboard input to go to the foreground window. In fact, the foreground window is defined as:

The window with which the user is currently working.

Redirecting keyboard input involves intercepting input using SetWindowsHookEx to install a keyboard hook or a low-level keyboard hook. The input has to be recorded and subsequently sent to the desired target. This is not supported by the OS and will fail in more or less subtle ways (for example see Replaying input is not the same as reprocessing it). The system controlled internal state will also be out of sync and functions like GetAsyncKeyState will return mismatching results.

Upvotes: 0

nanda
nanda

Reputation: 804

Moving mouse would cause windows to post messages to the input queue of the thread that owns the window that is directly beneath the mouse cursor (unless the mouse is captured using SetCapture). But posting a message would not cause the mouse to move. You might have to use SendInput windows API to achieve simulation of hardware input. Because of the way the mouse inputs are associated to the window that is directly beneath the mouse cursor, you might have to bring your window to front and then call SendInput. Keyboard input simulation would only go to the window that is in the foreground. And key board inputs can be simulated using SendInput too.

But often due to the way window control like EDIT and others process keyboard messages- by say moving the blinking cursor by one char down when they get WM_KEYDOWN - you can often short circuit them by manually posting messages. This kind of short circuiting often does not work for mouse messages because a window would not move the mouse to a position 10,20 when it receives WM_MOUSEMOVE for 10,20, rather they expect mouse to be at the position. And many other such reasons make post message approach not work for mouse input.

Upvotes: 2

Related Questions