Why the hell aren't there any wrappers built in for interoperating with human interface devices?

After fucking around with the RAWINPUT APIs I was able to implement all of the buttons on my MCE remote, except 2. Those would be the PC Power button and the MCE Start button. Most of the buttons are sent through a virtual keyboard driver, while some are sent through a consumer control HID driver.

Also, I don't seem to be able to receive the Alt key from my keyboard through the RAWINPUT APIs either.

When I say I can't use Alt keyboard key, the Start button on the remote, or the Power button on the remote, I mean I receive no WM_INPUT message when they are pressed.

How am I supposed to handle these? Is there anything built into the .NET CLR for interoperating with HIDs?

6/10/2009 7:13:17 PM

ibtnoen

6/10/2009 7:53:05 PM

The reason you aren't getting anything from WM_INPUT is that those buttons are not sending WM_INPUT messages.

They are likely sending accelerators via WM_COMMAND or WM_SYSCOMMAND. That's also why your Alt key isn't lighting up from RAWINPUT. Pressing ALT is not considered an input, it's an accelerator command element.

Hope that helps, there's definitely some trickery to specifically capturing ALT, SHIFT, and CTRL key presses. It's implemented that way for both security and consistency (accelerators are generally reserved for OS functions).

6/10/2009 8:17:29 PM

Ctrl, Shift, and Windows keys all send WM_INPUT though.

Debugging the WndProc on the form shows that no messages at all are received when I press these keys/buttons. If I press Alt while holding Control I get a WM_INPUT message with the virtual keycode 18.

I think some shenanigans are going on in .NET as neither forms nor controls seem to receive WM_SYSKEYDOWN, WM_SYSKEYUP, or WM_SYSCOMMAND ever. I wonder if these messages are dispatched by the CLR before they get to the WndProc. I imagine the CLR handles the real low level window procedure and then passes appropriate messages to the WndProc method. I wonder if the results would be any better if I actually Hooked the form's handle using the hooking APIs.

I know the Alt key can be captured with a low-level keyboard hook.

[Edited on June 10, 2009 at 9:22 PM. Reason : ]

6/10/2009 9:21:31 PM

You need to poll all the windows messages

http://www.pinvoke.net/default.aspx/Enums/WindowsMessages.html

To find out what message they are sending. Why do you want to capture Alt by itself? When do you ever NOT want to capture a combination with Alt?

6/11/2009 3:50:14 PM

maybe you haven't used windows lately - but when you press alt in just about every application - it jumps focus to and highlights the menu bar at the top

6/11/2009 4:16:16 PM

^ I assume that's a troll. Otherwise, you're an idiot and GTFO my thread.

^^ I know that already. When I say no messages are received when I press the Alt key, I mean no messages at all. I don't mean no WM_INPUT messages.

    Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
        Select Case m.Msg
            Case WindowMessages.WM_INPUT
                ProcessRawInput(m)
            Case Else
                Dim i As WindowMessages
                i = m.Msg
                Debug.Print(i.ToString & "  " & m.Msg)
                MyBase.WndProc(m)
        End Select
    End Sub

    Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)
#If DEBUG Then
#End If

        Select Case m.Msg
            Case WindowMessages.WM_INPUT
                ProcessRawInput(m)
            Case Else
                MyBase.WndProc(m)
        End Select
    End Sub

6/11/2009 6:55:56 PM

P.S. I'm doing this because I want to be able to receive arbitrary input and map it to whatever the hell I want, and send that to the active application. To do things like control VLC with a remote, etc.

And for the record, I don't give a shit about the Alt key, I was just pissed that it wasn't working and it should.

6/11/2009 7:33:35 PM