Raw input not reliably receiving all input - winapi

I'm using raw input in my application to handle global hotkeys, but I'm running in to some funky behavior. Under normal circumstances, if I press the PrintScreen key on my keyboard, my application sees the following raw input events (scancodes):
2a (down) -> 37 (down) -> 37 (up) -> 2a (up)
However, if I run a fullscreen game, such as Team Fortress 2, and then press the PrintScreen, I see the following raw input events:
2a (down) -> 37 (up) -> 2a (up)
What happened to 37 (down)? It's like something is swallowing the input event.

Related

Is a Gdk::ModifierType computer dependent?

I can capture Gdk::ModifierType. When I do mouse button events the modifier emits
272 for a left click
1040 for a right click
16 for a button release
If I run my program on another computer will it emit the same signals for mouse events?

What are all of the bits for in Winapi button states?

The MSDN documentation says that the elements of button state are focus, push, and check.
Looking into the header we see:
BST_CHECKED 0x0001
BST_INDETERMINATE 0x0002
BST_PUSHED 0x0004
BST_FOCUS 0x0008
but when I push a button in my application Button_GetState yields the integer value 108 (then 104 if I drag outside of the button). So here we have the first four bits accounted for, but what about after that? What about 16,32, 64? My button is not one that uses check state as far as I can tell, yet I still see these being used.
In short, what are the other individual bits doing?

GetLastInputInfo changes with no input

I'm using GetLastInputInfo to track user idle time in a desktop mixed mode C++ / C# application.
On one user's machine, GetLastInputInfo will advance its time, even when I register no low level keyboard or mouse input via this method.
The user (a coworker so I have access to the machine) runs Windows 10 on a Lenovo Yoga.
Below is sample output from my program to poll on GetLastInputInfo and display low level mouse and keyboard events:
Mouse: 57 wParam:512 flags:0 pt:1366,57 14750640 12:06:37.0864968
Mouse: 58 wParam:512 flags:0 pt:1366,60 14750656 12:06:37.0964981
Mouse: 59 wParam:512 flags:0 pt:1365,60 14750671 12:06:37.1064994
GetLastInputInfo 60 gliiRet:True cbSize:8 dwTime:14750671 12:06:37.2465354
GetLastInputInfo 61 gliiRet:True cbSize:8 dwTime:15063750 12:11:50.2038808
which implies that mouse events at 12:06:37.1064994 caused GetLastInputInfo #60 at 12:06:37.2465354, but between 12:06:37.2465354 and 12:11:50.2038808, no mouse or keyboard user input events occurred, but still GetLastInputInfo advanced to a new dwTime.
I'd like to determine the root cause of this problem. Is this a faulty device driver? Are there other trappable user input events that affect GetLastInputInfo that I'm missing?
Thanks.

UNIX - Handle terminale window state change

I would like to detect when the window running my CLI-program becomes active/inactive.
In concrete terms, my program receives regularly data from a server and displays them on the terminal window. Whenever new data are received I change the title of the window to notify the user. What I want to do is to reset the name of the window once he saw those new data.
I'm using python but I think I can go ahead if you have a generic solution.
Some terminals such as xterm let you get that information as focus events. If you enable DEC mode 1004
CSI ? 1004 h
then you'll get focus in / focus out events sent as
CSI I # focus in
CSI O # focus out

iPad/iPhone CoreMidi - Mackie Control Emulation (stop, play buttons)

I faced with very hard problem.
My task is to emulate Mackie Control Pro - Stop and Play buttons.
I know that Note93 (A5) - it is stop encoder. Note 94 (A5#) this is Play encoder.
Basically I'm sending Note On 93, 127 velocity then Note Off 93, 0 velocity, and Logic receive stop message, but after this he just went crazy, he sending many midi messages (note on,off 93) in loop, when I click play, it went more crazy. ((((
That how I'm sending message to Network Session:
Touch Down
UInt8 midiData[] = { 0x90, 93, 127};
[midi sendBytes:midiData size:sizeof(midiData)];
Touch Up
UInt8 midiData[] = { 0x80, 93, 0};
[midi sendBytes:midiData size:sizeof(midiData)];
The most interesting that when I play not A5, A5# in ThumbJam app (for iPad/iPhone), it works good. The same in eyoControl app, it works. But when I play A5, A5# key in TouchOSC or TB MIDI Stuff or Midi Designer, etc - then Logic went again to loop. And in the Midi Monitor messages the same in all applications. CRAZY... I can't understand this ((
What the difference, all applications connected and working seems via CoreMidi.
p.s. with Ableton Live, Reason everething ok. Buttons works.
Found solution. Instead of sending Note Off, application should send note on but with zero velocity.
instead {0x80, keynumber, 0} use {0x90, keynumber, 0}

Resources