How do I simulate input without SendInput?

Michal Zygmunt wants to create a system where multiple applications can have focus, with different users generating input and directing them at their target applications. Attempting to simulate this by posting input messages didn't work. "Can you tell us maybe how SendInput is internally implemented so that we can use it to simulate only part of the actions (like without acquiring focus)?"

SendInput operates at the bottom level of the input stack. It is just a backdoor into the same input mechanism that the keyboard and mouse drivers use to tell the window manager that the user has generated input. The SendInput function doesn't know what will happen to the input. That is handled by much higher levels of the window manager, like the components which hit-test mouse input to see which window the message should initially be delivered to. So if your goal is to change the way you call SendInput so it changes the focus management rules, you're barking up the wrong tree. It's like asking, "Please tell me how RAM chips work so I can use it to change the way Lotus 1-2-3 resolves circular references."

Comments (15)
  1. Pierre B. says:

    Simpler rebuttal: "what if two application did this?, with a twist". If two users simultaneously start a drag-and-drop, using a scroll bar, or any other action that grabs the mouse, what would happen?

  2. kinokijuf says:

    He is not  Michal, but Michał (the last letter is lslash). I'm Polish, so I know:-)

  3. kinokijuf says:

    He is not  Michal, but Michał (the last letter is lslash). I'm Polish, so I know:-)

  4. Joshua says:


    X11 can actually do it, but that depends on the specifics of event message passing in X11. I'm not sure if Win32 can do it.

    In some cases posting (not sending) messages to the right windows will do what you want but not in other cases. I've used the technique. It's a bit too tricky for my liking.

  5. Ben Voigt says:

    Now that Windows has a multi-user UI (Terminal Services, deployed in non-server editions as Fast User Switching), most of the pieces are in place.  It's quite likely that if this feature were ever enabled, it would be limited to Ultimate edition (which already lets you run the same Windows license in several virtual machines simultaneously, this appears similar from user-license-counting perspective). Since each virtual machine has its own notion of focus, that might even be one way to achieve the desired behavior while waiting for Microsoft to implement it.

    [Though if you ran each program in a different VM, most users would want focus to be unified across the virtual machines so the experience is the same as running them all locally. -Raymond]
  6. Gabe says:

    Many years ago, one of the first C# programs I wrote was an app that did this. The computer was a kiosk that had 5 or 6 monitors and mice, and the app put up a different window on each monitor. Each mouse cursor was restricted to the monitor assigned to that mouse.

    The system just posted mouse messages to whatever window each cursor was over. Since I was designing the complete UI I was able to avoid situations where a window tried to capture mouse input. Focus wasn't an issue because there were no keyboards (text input was via on-screen number pad).

    Of course this is completely different from the typical use of multiple input devices, which is collaborative environments where everybody shares the same screen.

  7. Ben Voigt says:

    @Raymond: Yes, the normal use case for VMs is one user administering many machines.  But binding a monitor, mouse and keyboard to each VM (driver paravirtualization or some fancy IO-V tricks necessary to have one video card running monitors for different VMs simultaneously with full acceleration) could be useful in some circumstances.  For example, multi-player gaming.  Using one computer for multiple players yields far less messaging latency than any network.  And enabling multiple console sessions for TS/FUS, again with individually bound monitor, mouse and keyboard (at least) would be superior to full virtualization.

  8. John Muller says:

    The solution he wants sounds like virtual Human Interface Device (HID) drivers, so he should look into the windows DDK.

  9. distracted says:

    Microsoft does have a product that allows the use of mutiple input devices and displays: Windows Multipoint Server.…/default.aspx

    It doesn't really seem to fit what this customer was asking though, because it looks like they want multiple windows on the same screen.

  10. Brian G. says:

    @Pierre B.

    I read this as the developer is looking for each input device to control its own cursors.  Presumably this would be used in a tightly-controlled environment with specific hardware and software installed, and multiple keyboard-type devices each directing to their own application or instance of the same application.

    *shrug*  It seems like a reasonable thing to want to implement.  I know I'm wanting to get Win7's Media Center application running fullscreen on the second monitor (an HDTV) controlled by a remote while the PC is fully usable by mouse and keyboard on primary monitor.  I'm waiting for the remote to come in the mail, but I'm hoping it'll sort of automagically work where Media Center can get the input from the remote control without needing focus.

  11. Danny says:

    <quote>..system where multiple applications can have focus, with different users generating input and directing them at their target applications</quote>.

    This is simple and already exists. Multiple users defined in Windows, each user is logged via a terminal, each terminal has it's own input devices (most common are keyboard and mouse), and each terminal is talking to his focused application. What's the big deal? I don't get it..this exists since Windows 2000, meaning for more then 10 years ago.

    What he want's in plus? That each user to see what other users applications are doing? Hooks lads and gents, hooks will simply give you everything. What else? The screens of each user? Write a screen capture app that will launch at each user log on and will give you that user screen (plus make the hooks in here too). Or sound? Expand the capture app to do that too. Or get one from internet, there are plenty written already, google ftw.

    Boy o boy, you try to rediscover the wheel when it was already invented by Micro$oft and furthermore is already giving you documentation for freeeeeee!. Or you want Micro$oft to sell brains on their site too?

  12. Cheong says:

    My solution to the problem would be he have to run multiple instance of VPC XP mode and each instance clipped to application size. Now you just have to forward request of "method to direct input to individual instance of VPC" / "method to create virtual driver for attachment as USB device on each instance of VPC" and question solved.

  13. Solution says:

    It seems that he only needs to download and use the Microsoft Mouse Multipoint SDK. See its blog announcement at:…/windows-multipoint-sdk-1-5-is-released.aspx

    Also see the Microsoft Mouse Mischief application for an example program:…/default.aspx

  14. David says:

    Raymond doesn't say it isn't possible. His statement was that the questioner is looking in the wrong direction.

    Without testing I think it's possible to create some kind of a global hook and handle all the input messages you want.

  15. Cheong says:

    @Solution: It's not that simple. Not only you have to get multiple mouse cursor, you'd also need multiple "activated window" for the solution to work (not many message would be sent to window that don't have focus if you rely on Windows mouse behavior).

Comments are closed.

Skip to main content