I have been thinking a lot over keyboard handling. How does it work? I can't seem to google me to a good explaining.
I know that a keyboard interrupt is made every time a key is pressed. The processor halts whatever it is processing and load the keyboard data from the keyboard buffer, storing it in a system level buffer.
But what happens next? Let's take a practical example. What happens when I run the following piece of code:
...
std::string s;
std::cin >> s;
....
Does the cin read from a user level representation of the system level keyboard buffer? That makes perfect sense in my head because then 2, or more processes can read from the same buffer, and by that way I don't loose any key presses. But does it work this way?
I know I'm talking in very general terms. The OS I'm using is OS X.
Except in rare situations, your keyboard and display are managed by a Window Manager: X11, Gnome, KDE, Carbon, Cocoa or Windows.
It works like this.
The keyboard driver is part of the OS.
The window manager is a privileged process, which acquires the device during startup. The window manager "owns" the device. Exclusively.
The interrupts go to OS.
The OS responds the interrupt by queueing. Eventually -- when there's nothing of a higher priority to do -- it captures the keyboard input from the interrupt and buffers it.
The owning process (the window manager) is reading this buffer. From this, it creates keyboard events.
Your application works through the window manager.
Example 1 -- You're running a command-line application. In a terminal window. When terminal window is front-most, the window manager directs events at the terminal window. Keyboard events become the stdin stream.
Example 2 -- you're running GUI application. In your own application's window. When your application's window is front-most, the window manager direct events at your application window. Keyboard events are available for your various GUI controls to process. Some keyboard events may cycle among the controls or active buttons.
Related
I'm in the middle of adding custom Windows Touchpad handling into my Windows C++ desktop application. From a high level, the app has its own cursor and objects that can be clicked. The cursor needs to be directly controlled by a Windows Precision Touchpad, and completely decoupled from the standard Windows mouse. I'm accomplishing this via processing raw input from WM_INPUT messages, and using low level mouse hooks to prevent controlling the normal mouse pointer.
I'm able to interpret single and multi-finger gestures just fine using the WM_INPUT data, but haven't figured out how to get "clicks" or "taps" from the touchpad. Legacy Mouse Input events will obviously not work for my use case since they:
Aren't global and require my app to be focused
Are generated by any connected mouse/pointing device, not just the touchpad I registered for.
Interact at the location of the Windows mouse pointer, which is not driving the cursor in my app.
Are clicks/taps contained in the WM_INPUT reports, and I'm just not able to find them, or is there another way I can capture raw clicks from only the touchpad in my application?
RAWMOUSE struct that comes with WM_INPUT mouse message contains usButtonFlags with mouse button up/down transition state.
You cannot get clicks/taps because AFAIK classic Win32 API is not suitable for touch input at all - it just emulating mouse in case of touchpad.
According to touchpad spec all compatible Windows Precision Touchpad's are HID devices that are sending touchpad data in their Input Reports. They should contain corresponding Top Level Collection Page 0x0D (Digitizers), Usage 0x05 (Touch Pad) - and this will be seen as separate HID device from Win32 user-mode. See sample HID Report Descriptor.
Knowing this you can register to receive touchpad data with RegisterRawInputDevices call. After that you'll receive WM_INPUT message with RAWHID struct for each tounchpad input report - this needs to be handled manually (according to device's Preparsed HID Report Descriptor Data etc).
It's not easy but doable.
See example code here.
Update: Also there are WM_TOUCH and WM_GESTURE messages available since Windows 7. Maybe its what you're looking for. Sample code.
you can use PostMessage(applicationWinhandle, WM_INPUT, wparam, mouseDeviceHandle) send WM_INPUT message to your application, and then hook GetRawInputData or GetRawInputBuffer to send data.
OK, I get it: focus stealing is evil. Or at least it is 99.9% of the time. But I really need to steal the focus reliably on Windows 8, and so far I'm thwarted by the hordes of people insisting focus stealing is always evil.
Scenario: we run a custom application on an ordinary PC running Windows 8.1 (soon to be Windows 10). The screen, keyboard and mouse sit roughly 5m off the ground up some stairs that the forklift operator really shouldn't climb. The one input device they have is a numeric keypad on an extender cable down at their level. Everything they need to do they can do from that keypad... so long as some evil program hasn't stolen our application's focus, or some remote user hasn't logged out and left another application with focus.
The application is essentially a maximised desktop application - it fills the screen (but is not strictly a "full screen" or "topmost" application), and therefore allows other applications to appear in front of it when required. But when the mouse goes idle, we want this application to resume its "normal" position in front of all other applications so that it gets focus and the numeric keypad input will work reliably.
On Windows 7, using SetForegroundWindow() (enabled by AllowSetForegroundWindow() works fine - the application can be brought back to the front and resume focus. On Windows 8, SetForegroundWindow() only results in the taskbar icon flashing, but the application does not regain focus, forcing our user to climb the stairs... where the full keyboard and mouse is too tempting for them not to press buttons they shouldn't, and chaos typically ensues.
So please sir: can our (MFC, desktop) application steal back the focus once the mouse has gone idle for 1 minute, because it is more or less the only application that should normally be running anyway. If that is permitted, how do we steal it reliably?
Configure hotkeys on numeric keypad (RegisterHotKey).
Pressing a registered hotkey gives you the foreground activation love by Raymond Chen
After you call the RegisterHotKey function to register a hotkey, the
window manager will send you a WM_HOTKEY message when the user presses
that hotkey, and along with it, you will get the foreground love. If
you call SetForegroundWindow from inside your hotkey handler, the
foreground window will change according to your instructions.
Possible solution (with major limitations): do nothing extra; wait.
One of our service technicians observed that on the third or fourth attempt to regain focus using AllowSetForegroundWindow() and SetForegroundWindow() as had been working on Windows 7, Windows 8 finally allowed our application to regain focus. It is not clear what the conditions are that make this work, or if it works reliably, but we have now observed our application regaining focus from beneath Chrome, from beneath another (self-developed) MFC application, and from beneath a third party application - all desktop applications. Approximately 3-4 minutes needed to elapse in each case before focus was surrendered back to our (desktop) application.
However, we have not witnessed it regain focus from beneath metro applications, and nor do we expect it (e.g. hit the Windows key and leave the system lingering on the Start screen).
In our (restricted) situation, we are willing to take the gamble that our users will not launch a metro application that obscures our desktop application, at least not without restoring our application, since their business relies on it. Our main concern is that one of our busy service technicians will log in remotely, get distracted, and carelessly leave one of our desktop utilities with the focus. Waiting 3-4 minutes appears to be a solution to this specific scenario.
I would try it in this way:
Setup a timer in you application. That checks GetForegroundWindow on a regular basis.
If GetForgroundWindow does not belong to your process (GetWindowThreadProcessId)
If a different process onws the foreground window use AttachThreadInput and attach your input queue to the input queue of the other process.
Now use SetForegoundWindow and detach the thread input again.
Now you can use SetFocus as needed to control the input focus of your program.
I have my own keyboard and an USB barcode scanner that works like a second keyboard.
I would like to use the main keyboard to control the computer (as you usually do) and the second keyboard (that is actually the barcode scanner) to log all the input into a file.
Is this possible to do?
The point is, I could be on the internet, word, excel or whatever. I would use the main keyboard to write to that processes while in the background the second keyboard (barcode scanner) could be at the same time writing but to a log file. The program that I could be using in the moment would never know about the second keyboard input.
Thanks, all suggestions are very welcome.
You can use the Raw Input API to monitor keyboard events before the OS processes them. The API will tell you which device is sending each event, so you can log events from just the scanner.
However, the Raw Input API does not allow you to block input, so to block the scanner's events from being processed as normal keyboard events, you would need to use SetWindowsHookEx() to setup a keyboard hook that dismisses the events.
However, SetWindowsHookEx() does not report which device is sending each event, so you will have to coordinate the two APIs manually. When Raw Input detects a keyboard event, set a flag based on which device the event came from. When the hook detects the cooresponding event, check the flag and dismiss the event if the flag indicates the scanner device.
See Combining Raw Input and keyboard Hook to selectively block input from multiple keyboards on CodeProject.
Does Windows provide some sort of mechanism to detect when an app running in fullscreen mode (e.g. games, media players, etc.) exits fullscreen mode, either returning to windowed mode or exiting its process?
There is no such thing as "fullscreen mode" or "windowed mode" as far as the OS is concerned. A window simply has dimensions, which may happen to be the same as the screen dimensions or not. The application that owns the window controls that behavior, not the OS, so only the application knows when it is displaying the window in "full screen" or "windowed" mode.
That being said, the application may optionally call ChangeDisplaySettings/Ex() with the CDS_FULLSCREEN or CDS_RESET flag when changing modes. That will send WM_DISPLAYCHANGE notifications to all top-level windows, but it will not tell them that a fullscreen window is being displayed or not.
As for detecting process termination, WMI has an event for that. See Receiving Event Notifications Through WMI.
A simple approach to this, and what I decided to go with, is using RegisterWaitForSingleObject on the created process as explained here: https://stackoverflow.com/a/22418949/1019385
I found it more approachable than the WMI solution.
I was using the PlaySound function in one C++ application under Windows.
When this application is running a local var command PlaySound and it starts to play a WAV file.
But when you click on the minimize dialog box of my application, the sound continues playing, when the logical rule must be silenced or muted until you maximize the application again.
The question is:
Is there application-state within Windows to detect when application is minimized?
In order to set the waveOutSetVolume function with 0x00 = mute.
Have your app's window catch the WM_SYSCOMMAND message and check it for the SC_MINIMIZE, SC_MAXIMIZE, and SC_RESTORE notifications.
Your application will receive a WM_WINDOWPOSCHANGED message when the application window has been minimized or maximized. Check the WINDOWPOS struct in lParam to determine the new state. You can then turn the sound off or on, respectively. (Note: this message is also sent when the window is moved, sent to back, etc. So check the lParam.)
If the application is currently minimized can be checked with IsIconic.
And I don't find it logical that the sound has to stop playing when the application is minimized. It's a multitasking OS after all. I want it to do things in parallel.