Member Avatar for shawnisalk

Hi,

I'm trying to write a program for Windows that will control the mouse with the keyboard, but I'm not sure I understand how Windows works.

My theory is that I will need to send mouse event messages for the mouse and hook the messages from the keys that are used to control the mouse. And I thought that I was going to need to send those messages to the in-focus window via a handle, but there isn't a handle parameter in the message sending function...

So, the question is, "Do I send the messages with no destination?" and "Does the OS grab messages and route them itself?"

Can anyone tell me how that works?

Thanks,
Shawn

  • 4 Contributors
  • 6 Replies
  • 368 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by shawnisalk

Dani AI

Generated

Short answer: don’t Post/Send WM_MOUSE* messages to some window if the goal is to replace the real mouse. For system‑wide behavior the OS must see real input — use a global keyboard hook to capture keys and inject real mouse input (the OS will then route it to whatever window is active). No HWND is required when synthesizing input.

Recommended approach (practical steps)

  • Capture keys system‑wide with a low‑level hook (SetWindowsHookEx with WH_KEYBOARD_LL) or use RegisterHotKey for a few modifier+key combos. WH_KEYBOARD_LL works even when other apps have focus; other hook types often require a DLL.
  • Translate key events to mouse actions and inject them with SendInput (preferred) or SetCursorPos + SendInput for clicks. SendInput generates real mouse events the OS routes normally.
  • If the goal is only to target a single application window (not move the real cursor), PostMessage/SendMessage with WM_MOUSE* can be used, but that won’t update the system cursor or behave like physical input.

Minimal sketch (conceptual)

HHOOK h = SetWindowsHookEx(WH_KEYBOARD_LL, LowLevelKeyboardProc, GetModuleHandle(NULL), 0);

LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam) {
    if (nCode >= 0 && (wParam == WM_KEYDOWN || wParam == WM_SYSKEYDOWN)) {
        KBDLLHOOKSTRUCT *k = (KBDLLHOOKSTRUCT*)lParam;
        if (k->vkCode == VK_LEFT) {
            INPUT in = {0};
            in.type = INPUT_MOUSE;
            in.mi.dwFlags = MOUSEEVENTF_MOVE;
            in.mi.dx = -10; // relative move
            SendInput(1, &in, sizeof(in));
            return 1; // swallow original key
        }
    }
    return CallNextHookEx(NULL, nCode, wParam, lParam);
}

Practical cautions and tips

  • Filter out injected events (hook flags include an “injected” bit) to avoid feedback loops.
  • Keep hook handlers tiny and fast; call CallNextHookEx for unhandled keys.
  • Run as a user process (not a session‑0 service) so the hook sees interactive input.
  • Secure sequences (Ctrl+Alt+Del) and the secure desktop cannot be intercepted.
  • ’s window‑proc idea works only when that window has focus; is right that a visible GUI isn’t required but a user‑session process is; ’s point about MouseKeys is useful for quick tests but not flexible for custom devices.

Recommended Answers

All 6 Replies

Member Avatar for LevyDee

If you want to move the mouse, for example using your arrow keys, you would set up event handling using your windows procedure fuction, and depending on what key is pressed(determined throuhg a switch statement of your lParam), you move the mouse. Im not sure if there is a windows function you can call to move the mouse, but if you do some research Im sure you could figure it out.

Member Avatar for shawnisalk

I appreciate the response, but it doesn't seem like you answered the question I asked.
My question was more like, how does Windows work?

The intent behind my program is to replace all the functionality of the mouse with key presses. It will not have a graphical component. It will be a keyboard mouse.

As far as I understand it, an application receives events from the OS and it receives them only when it is "in-focus". If that's correct (maybe it's not), then when another program is in-focus, the key-combo's will not work.

My understanding is that the Windows Proc function of my program will have to hook the appropriate messages from the keyboard and replace them with mouse event messages.

Do you know if this is this correct?

Edited by shawnisalk because: n/a
Member Avatar for hag++

My question was more like, how does Windows work?

WTF?? This question is going to take a lot longer to answer than you think lol

The intent behind my program is to replace all the functionality of the mouse with key presses. It will not have a graphical component. It will be a keyboard mouse.

My understanding is that the Windows Proc function of my program will have to hook the appropriate messages from the keyboard and replace them with mouse event messages.

If your program isn't going to be graphical then why are you programming with the Win32 API?

Member Avatar for shawnisalk

re: WTF -- Well, do you know? Can you give me brief overview?

re: Why Windows -- because most people use Windows... *shrug* ...and because you/I have to in order to control the mouse pointer/buttons.

Edited by shawnisalk because: n/a
Member Avatar for shawnisalk

Because I hope to replace the mouse with a different device which will not be using Windows accessibility options (although I appreciate the link...I did not know about Windows accessibility option).

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.