Click here to Skip to main content
Click here to Skip to main content

Using Raw Input from C# to handle multiple keyboards

, , 8 Mar 2013
Rate this:
Please Sign up or sign in to vote.
Windows XP supports multiple keyboards, but by default, the .Net Framework will treat them all as one. This article explains how to use the Windows API Raw Input methods to support multiple keyboards from a C# application.

Sample Image - rawinput.jpg

Introduction
Background
Support for different devices
Using the code
Implementing a Windows API Raw Input handler

        Registering raw input devices
        Retrieving and processing raw input
        Retrieving the list of input devices
        Getting information on specific devices
        Reading device information from the Registry

Conclusion
Sources

Introduction

There was a time when you were lucky if a PC had so much as a mouse, but today, it is common to have a wide variety of Human Interface Devices (HIDs) ranging from game controllers to touch screens. In particular, users can connect more than one keyboard to their PCs. However, the usual keyboard programming methods in the .NET Framework offer no way to differentiate the input from different keyboards. Any application handling KeyPress events will receive the input from all connected keyboards as if they were a single device.

Windows XP and above now support a "raw input" API which allows programs to handle the input from any connected human interface devices directly. Intercepting this information and filtering it for keyboards enables an application to identify which device triggered the message. For example, this could allow two different windows to respond to input from different keyboards.

This article and the enclosed code demonstrate how to handle raw input in order to process keystrokes and identify which device they come from. The Rawinput.dll file in the attached zip contains the raw input API wrapper; copy this dll to your own project and follow the instructions in "Using the code" if you want to use it without running the sample application.

Background

I recently published an article on implementing a low-level keyboard hook in C#[^] using the SetWindowsHookEx and related methods from user32.dll. While looking for a solution to handle multiple keyboards, Steve Messer[^] came across my article and we discussed whether my code could be adapted to his needs. In fact, it turned out that it couldn't, and that the Raw Input API was the solution.

Unfortunately, there are very few keyboard-related Raw Input samples online, so when Steve had finished a working sample of his code, I offered to write this article so that future .NET developers faced with this problem wouldn't have to look far to find the solution. While I have made minor adjustments to the code, it is primarily Steve's work and I thank him for sharing it. Note: as of March 2007, you can also download Steve's WPF sample illustrating the use of WndProc in Windows Vista. However, this article only describes the Windows XP source code.

Please note that this will only work on Windows XP or later in a non-Terminal Server environment, and the attached sample projects are for Visual Studio 2005. The latest update was developed using Visual Studio 2012 on Windows 8 64 bit. I do not believe the update has any dependencies on anything higher that .Net 2.0 so you can simply add the files to any version of VS that you might have.

Support for different devices

The attached code is a generic solution that mostly mirrors the sample code given on MSDN. Different devices will work in different ways, and you may need to amend the code to suit the keyboards you are using. Unfortunately, we won't always be able to help with device-specific queries, as we won't have the same devices you have. Steve Messer has tested the code with different keyboards, however, and is confident that it will work with most devices provided they are correctly installed.

Using the code

Most of the code related to raw input handling is encapsulated in the RawKeyboard and RawInput classes which reside in the rawinput.dll. Using it is a matter of implementing three simple steps:

1. Add a reference to rawinput.dll to your project.

Then add the following using statement.

using RawInput_dll;

2. Instantiate an RawInput object

The RawInput class's constructor takes one argument, which is the handle to the current window.

RawInput rawinput = new RawInput(Handle);

The handle is required. When you register for rawinput the input is sent to the given handle. If you don't provide a handle then rawinput doesn't have a window to send messages to. The rawinput class now inherits from Native Window and overrides WndProc for you.

3. Handle the KeyPressed event

When a key is pressed, the RawKeyboard class raises a custom KeyPressed event containing an InputEventArgs. This needs to be handled by a method of the type DeviceEventHandler, which can be set up as follows:

rawinput.KeyPressed += OnKeyPressed;

The method that handles the event can then perform whatever actions are required based on the contents of the KeyControlEventArgs argument. The sample application attached to this article simply uses the values to populate a dialog box.

4. Optional Settings to control message handling and capture messages only if your application is top-most

_rawinput.CaptureOnlyIfTopMostWindow = true;    // Otherwise default behavior is to capture always
_rawinput.AddMessageFilter();                   // Adding a message filter will cause keypresses to be handled

Now, the RawInput class works by intercepting messages to the registered window handle in order to process the WM_INPUT messages containing raw input data. The window listening for raw input will therefore need to override its own WndProc and pass all its messages to the instantiated RawKeyboard object.

protected override void WndProc(ref Message message)
{
  switch(message.Msg)
  {
    case Win32.WM_INPUT:
    _keyboardDriver.ProcessRawInput(message.LParam);
    break;
  }
  base.WndProc(ref message);
}

The rest of this article describes how to handle "raw input" from a C# application, as illustrated by the RawInput and RawKeyboard class's in the sample application.

Implementing a Windows API Raw Input handler

MSDN identifies "raw input" [^] as being the raw data supplied by an interface device. In the case of a keyboard, this data is normally intercepted by Windows and translated into the information provided by Key events in the .NET Framework. For example, the Windows manager translates the device-specific data about keystrokes into virtual keys.

However, the normal Windows manager doesn't provide any information about which device received the keystroke; it just bundles events from all keyboards into one category and behaves as if there were just one keyboard.

This is where the Raw Input API is useful. It allows an application to receive data directly from the device, with minimal intervention from Windows. Part of the information it provides is the identity of the device that triggered the event.

The user32.dll in Windows XP, Vista, and Windows 8 contains the following methods for handling raw input:

  • RegisterRawInputDevices allows the application to register the input devices it wants to monitor.
  • GetRawInputData retrieves the data from the input device.
  • GetRawInputDeviceList retrieves the list of input devices attached to the system.
  • GetRawInputDeviceInfo retrieves information on a device.

The following sections give an overview of how these four methods are used to process raw data from keyboards.

Registering raw input devices

By default, no application receives raw input. The first step is therefore to register the input devices that will be providing the desired raw data, and associate them with the window that will be handling this data.

To do this, the RegisterRawInputDevices method is imported from user32.dll:

[DllImport("User32.dll")]
extern static bool RegisterRawInputDevices(RAWINPUTDEVICE[] pRawInputDevice, uint uiNumDevices, uint cbSize);

To determine which devices should be registered, the method accepts an array of RAWINPUTDEVICE structures. The other two arguments are the number of items in the array, and the number of bytes in a RAWINPUTDEVICE structure.

The RAWINPUTDEVICE structure is defined in Windows.h for C++ projects, here is has been redefined for use in C#.

[StructLayout(LayoutKind.Sequential)]
internal struct RawInputDevice
{
   internal HidUsagePage UsagePage;
   internal HidUsage Usage;
   internal RawInputDeviceFlags Flags;
   internal IntPtr Target;

   public override string ToString()
   {
      return string.Format("{0}/{1}, flags: {2}, target: {3}", UsagePage, Usage, Flags, Target);
   }
}

Each RAWINPUTDEVICE structure added to the array contains information on a type of device which interests the application. For example, it is possible to register keyboards and telephony devices. The structure uses the following information:

  • Usage Page: The top level HID "usage page". For most HIDs, including the keyboard, this is 0x01.
  • Usage ID: A number indicating which precise type of device should be monitored. For the keyboard, this is 0x06. (A list of Usage Page and Usage ID values can be found in this MSDN article on HIDs[^])
  • Flags: These determine how the data should be handled, and whether some types should be ignored. A list of possible values is given in the MSDN article[^], and the constants they represent are defined in Windows.h (there's a copy of it here[^] if you don't already have one).
  • Target Handle: The handle of the window which will be monitoring data from this particular type of device.

In this case, we are only interested in keyboards, so the array only has one member and is set up as follows:

RAWINPUTDEVICE[] rid = new RAWINPUTDEVICE[1];

rid[0].usUsagePage  = 0x01;
rid[0].usUsage      = 0x06;
rid[0].dwFlags      = RIDEV_INPUTSINK; 
rid[0].hwndTarget   = hwnd;

Here, the code only defines the RIDEV_INPUTSINK flag, which means that the window will always receive the input messages, even if it is no longer has the focus. This will enable two windows to respond to events from different keyboards, even though at least one of them won't be active.

With the array ready to be used, the method can be called to register the window's interest in any devices which identify themselves as keyboards:

RegisterRawInputDevices(rid, (uint)rid.Length, (uint)Marshal.SizeOf(rid[0]))

Once the type of device has been registered this way, the application can begin to process the data using the GetRawInputData method described in the next section.

Retrieving and processing raw input

When the type of device is registered, the application begins to receive raw input. Whenever a registered device is used, Windows generates a WM_INPUT message containing the unprocessed data from the device.

Each window whose handle is associated with a registered device as described in the previous section must therefore check the messages it receives and take appropriate action when a WM_INPUT one is detected. In the sample application, the Rawnput class takes care of checking for WM_INPUT messages, so all the native window does is override its base WndProc method to get access to the messages, and pass the handle that generated the input to the RawKeyboard object's ProcessRawInput for processing:

 protected override void WndProc(ref Message message)
 {
    switch (message.Msg)
    {
       case Win32.WM_INPUT:
       {
           // Should never get here if you are using PreMessageFiltering
           _keyboardDriver.ProcessRawInput(message.LParam);
       }
       break;
       
       base.WndProc(ref message);
 }

The WndProc method in RawInput filters the messages, calling ProcessRawInput whenever a WM_INPUT is received. Any other type of message will fall through to the call to the base WndProc, so the application will respond to other events normally.

ProcessRawInput then uses the GetRawInputData method to retrieve the contents of the message and translate it into meaningful information.

Retrieving the information from the message

In order to process the data in WM_INPUT messages, the GetRawInputData method is imported from user32.dll:

[DllImport("User32.dll")]
internal static extern int GetRawInputData(IntPtr hRawInput, DataCommand command, {Out] IntPtr pData, ref uint size, int sizeHeader);

The method uses the following parameters:

  • hRawInput
    The handle to the RAWINPUT structure containing the data, as provided by the lParam in a WM_INPUT message.
  • command
    A flag which sets whether to retrieve the input data or the header information from the RAWINPUT structure. Possible values are RID_INPUT (0x10000003) or RID_HEADER (0x10000005) respectively.
  • pData:
    Depending on the desired result, this can be one of two things:
    • If pData is set to IntrPtr.Zero, the size of the buffer required to contain the data is returned in the pcbSize variable.
    • Otherwise, pData must be a pointer to allocated memory that can hold the RAWINPUT structure provided by the WM_INPUT message. When the method call returns, the contents of the allocated memory will be either the message's header information or input data, depending on the value of uiCommand.
  • size
    A variable that returns or specifies the size of the data pointed to by pData.
  • sizeHeader
    The size of a RAWINPUTHEADER structure.

In order to ensure that enough memory is allocated to store the desired information, the GetRawInputData method should first be called with pData set to IntPtr.Zero.

int dwSize = 0;

Win32.GetRawInputData( hdevice, DataCommand.RID_INPUT, IntPtr.Zero, ref dwSize, Marshal.SizeOf(typeof(Rawinputheader)));

Following this call, the value of dwSize will correspond to the number of bytes needed to store the raw input data (as indicated by the use of the RID_INPUT flag).

Now that the size of the inputdata , GetRawInputData can be called again to populate the _rawBuffer with the RAWINPUT structure from the current message. If it succeeds, the method returns the size of the data it retrieved, so it is worth checking that this matches the result of the previous call before continuing.

if( Win32.GetRawInputData(hdevice, DataCommand.RID_INPUT, out _rawBuffer, ref dwSize, Marshal.SizeOf(typeof(RAWINPUTHEADER))) == dwSize)
//do something with the data

 Processing the data

As mentioned above, the WM_INPUT message contains raw data encapsulated in a RAWINPUT structure. As with the RAWINPUTDEVICE structure described in the previous section, this structure is redefined in the RawInput dll as follows.

[StructLayout(LayoutKind.Explicit)]
public struct RawData
{
   [FieldOffset(0)]
   internal Rawmouse mouse;
   [FieldOffset(0)]
   internal Rawkeyboard keyboard;
   [FieldOffset(0)]
   internal Rawhid hid;
}

[StructLayout(LayoutKind.Sequential)]
public struct  InputData
{
   public Rawinputheader header;           // 64 bit header size is 24  32 bit the header size is 16
   public RawData data;                    // Creating the rest in a struct allows the header size to align correctly for 32 or 64 bit
}

[StructLayout(LayoutKind.Sequential)]
public struct Rawinputheader
{
   public uint dwType;                     // Type of raw input (RIM_TYPEHID 2, RIM_TYPEKEYBOARD 1, RIM_TYPEMOUSE 0)
   public uint dwSize;                     // Size in bytes of the entire input packet of data. This includes RAWINPUT plus possible extra input reports in the RAWHID variable length array. 
   public IntPtr hDevice;                  // A handle to the device generating the raw input data. 
   public IntPtr wParam;                   // RIM_INPUT 0 if input occurred while application was in the foreground else RIM_INPUTSINK 1 if it was not.

   public override string ToString()
   {
       return string.Format("RawInputHeader\n dwType : {0}\n dwSize : {1}\n hDevice : {2}\n wParam : {3}", dwType, dwSize, hDevice, wParam);
   }
}

Following the second call to GetRawInputData (see previous section), the raw structure will contain the following information:

A RAWINPUTHEADER structure called header, which contains information on the message and the device that triggered it.

A second structure of type RAWKEYBOARD called keyboard. This could also be a RAWMOUSE or RAWHID structure called mouse or hid, depending on the type of device.

Its members return the following information:

  • dwType
    The type of raw input the message represents. The values can be RIM_TYPEHID (2), RIM_TYPEKEYBOARD (1), or RIM_TYPEMOUSE (0).
  • dwSize
    The size of all the information in the message (header and input data included).
  • hDevice
    The handle of the device which triggered the message.
  • wParam
    The wParam data from the WM_INPUT message.

The second structure will be a RAWMOUSE, a RAWKEYBOARD, or a RAWHID type. For the sake of completeness, the Rawinput dll does contain definitions for RAWMOUSE and RAWHID, though it is only designed to process keyboard information.

The keyboard information is provided by a RAWKEYBOARD structure, laid out as follows.

[StructLayout(LayoutKind.Sequential)]
internal struct Rawkeyboard
{
   public ushort Makecode;                 // Scan code from the key depression
   public ushort Flags;                    // One or more of RI_KEY_MAKE, RI_KEY_BREAK, RI_KEY_E0, RI_KEY_E1
   public ushort Reserved;                 // Always 0    
   public ushort VKey;                     // Virtual Key Code
   public uint Message;                    // Corresponding Windows message for exmaple (WM_KEYDOWN, WM_SYASKEYDOWN etc)
   public uint ExtraInformation;           // The device-specific addition information for the event (seems to always be zero for keyboards)

   public override string ToString()
   {
       return string.Format("Rawkeyboard\n Makecode: {0}\n Makecode(hex) : {0:X}\n Flags: {1}\n Reserved: {2}\n VKeyName: {3}\n Message: {4}\n ExtraInformation {5}\n", 
                                           Makecode, Flags, Reserved, VKey, Message, ExtraInformation);
   }
}

The next step is to filter the message to see if it is a key down event. This could just as easily be a check for a key up event; the point here is to filter the messages so that the same keystroke isn't processed for both key down and key up events.

private const int WM_KEYDOWN     = 0x0100;
private const int WM_SYSKEYDOWN  = 0x0104;
...
if (raw.keyboard.Message == WM_KEYDOWN || 
    raw.keyboard.Message == WM_SYSKEYDOWN)
{
  //Do something like...
  int vkey = raw.keyboard.vkey;
  MessageBox.Show(vkey.ToString());
}

At this point, the RawKeyboard class retrieves further information about the message and the device that triggered it, and raises its custom KeyPressed event. The following sections describe how to get information on the devices.

Retrieving the list of input devices

Although this step isn't required to handle raw input, the list of input devices can be useful. The sample application retrieves a list of devices, filters it for keyboards, and then returns the number of keyboards. This is part of the information returned by the InputEventArgs in the RawKeyboard class's KeyPressed event.

The first step is to import the necessary method from user32.dll:

[DllImport("User32.dll")]
extern static uint GetRawInputDeviceList(IntPtr pRawInputDeviceList, ref uint uiNumDevices, uint cbSize);

The method's arguments are as follows:

  • pRawInputDeviceList: Depending on the desired result, this can be one of two things:
    • IntPtr.Zero if the purpose is only to retrieve the number of devices.
    • A pointer to an array of RAWINPUTDEVICELIST structures if the purpose of the method call is to retrieve the complete list of devices.
  • uiNumDevices: A reference to an unsigned integer to store the number of devices.
    • If the pRawInputDeviceList argument is IntPtr.Zero, then this variable will return the number of devices.
    • If the pRawInputDeviceList argument is a pointer to an array, then this variable must contain the size of the array. This allows the method to allocate memory appropriately. If uiNumDevices is less than the size of the array in this case, the method will return the size of the array, but an "insufficient buffer" error will occur and the method will fail.
  • cbSize: The size of a RAWINPUTDEVICELIST structure.

In order to ensure that the first and second arguments are correctly configured when the list of devices is required, the method should be set up in three stages.

First, it should be called with pRawInputDeviceList set to IntPtr.Zero. This will ensure that the variable in the second argument (deviceCount here) is filled with the correct number of devices. The result of this call should be checked, as an error means that the code can proceed no further.

uint deviceCount = 0;
int dwSize = (Marshal.SizeOf( typeof( RAWINPUTDEVICELIST )));

if( GetRawInputDeviceList( IntPtr.Zero, ref deviceCount, (uint)dwSize ) == 0 )
{
  //continue retrieving the information (see below)
}
else
{
  //handle the error or throw an exception
}

Once the deviceCount variable contains the right value, the correct amount of memory can be allocated and associated with a pointer:

IntPtr pRawInputDeviceList = Marshal.AllocHGlobal((int)(dwSize * deviceCount ));

And the method can be called again, this time to fill the allocated memory with an array of RAWINPUTDEVICELIST structures:

GetRawInputDeviceList( pRawInputDeviceList, ref deviceCount, (uint)dwSize );

The pRawInputDeviceList data can then be converted into individual RAWINPUTDEVICELIST structures. In the example below, a for loop has been used to iterate through the devices, so i represents the position of the current device in the array.

for( int i = 0; i < deviceCount; i++ )
{
  RAWINPUTDEVICELIST rid = (RAWINPUTDEVICELIST)Marshal.PtrToStructure(
         new IntPtr(( pRawInputDeviceList.ToInt32() + ( dwSize * i ))), 
         typeof( RAWINPUTDEVICELIST ));
//do something with the information (see section on GetRawInputDeviceInfo)
}

When any subsequent processing is completed, the memory should be deallocated.

Marshal.FreeHGlobal( pRawInputDeviceList );

Getting information on specific devices

Once GetRawInputDeviceList has been used to retrieve an array of RAWINPUTDEVICELIST structures as well as the number of items in the array, it is possible to use GetRawInputDeviceInfo to retrieve specific information on each device.

First, the method is imported from user32.dll:

[DllImport("User32.dll")]
extern static uint GetRawInputDeviceInfo(IntPtr hDevice, uint uiCommand, IntPtr pData, ref uint pcbSize);

Its arguments are as follows:

  • hDevice
    The device handle returned in the corresponding RAWINPUTDEVICELIST structure.
  • uiCommand A flag to set what type of data will be returned in pData. Possible values are RIDI_PREPARSEDDATA (0x20000005 - returns previously parsed data), RIDI_DEVICENAME (0x20000007 - a string containing the device name), or RIDI_DEVICEINFO (0x2000000b - an RIDI_DEVICE_INFO structure)
  • pData: Depending on the desired result, this can be one of two things:
    • If pData is set to IntrPtr.Zero, the size of the buffer required to contain the data is returned in the pcbSize variable.
    • Otherwise, pData must be a pointer to allocated memory that can hold the type of data specified by uiCommand.
      (Note: if uiCommand is set to RIDI_DEVICEINFO, then the cbSize member of the RIDI_DEVICE_INFO structure must be set to the size of the structure)
  • pcbSize
    A variable that returns or specifies the size of the data pointed to by pData. If uiCommand is RIDI_DEVICENAME, pcbSize will indicate the number of characters in the string. Otherwise, it indicates the number of bytes in the data.

The example code uses a for loop to iterate through the available devices as indicated by the deviceCount variable. At the start of each loop, a RAWINPUTDEVICELIST structure called rid is filled with the information on the current device (see GetRawInputDeviceList section above).

In order to ensure that enough memory is allocated to store the desired information, the GetRawInputDeviceInfo method should first be called with pData set to IntPtr.Zero. The handle in the hDevice parameter is provided by the rid structure containing information on the current device in the loop.

uint pcbSize = 0;

GetRawInputDeviceInfo( rid.hDevice, RIDI_DEVICENAME, IntPtr.Zero, ref pcbSize );

In this example, the purpose is to find out the device name, which will be used to look up information on the device in the Registry.

Following this call, the value of pcbSize will correspond to the number of characters needed to store the device name. Once the code has checked that pcbSize is greater than 0, the appropriate amount of memory can be allocated.

IntPtr pData = Marshal.AllocHGlobal( (int)pcbSize );

And the method can be called again, this time to fill the allocated memory with the device name. The data can then be converted into a C# string for ease of use.

string deviceName; 

GetRawInputDeviceInfo( rid.hDevice, RIDI_DEVICENAME, pData, ref pcbSize );
deviceName = (string)Marshal.PtrToStringAnsi( pData );

The rest of the code then retrieves information about the device and checks the Registry to retrieve device information.

Reading device information from the Registry

Following the above code, deviceName will have a value similar to the following:

\\??\\ACPI#PNP0303#3&13c0b0c5&0#{884b96c3-56ef-11d1-bc8c-00a0c91405dd}

This string mirrors the device's entry in the Registry; parsing it therefore allows us to find the relevant Registry key, which contains further information on the device. So the first step is to break down the relevant part of the string:

// remove the \??\
item = item.Substring( 4 ); 

string[] split = item.Split( '#' );

string id_01 = split[0];    // ACPI (Class code)
string id_02 = split[1];    // PNP0303 (SubClass code)
string id_03 = split[2];    // 3&13c0b0c5&0 (Protocol code)
// The final part is the class GUID and is not needed here

The Class code, SubClass code and Protocol retrieved this way correspond to the device's path under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet, so the next stage is to open that key:

RegistryKey OurKey = Registry.LocalMachine;

string findme = string.Format(@"System\CurrentControlSet\Enum\{0}\{1}\{2}", id_01, id_02, id_03 );

The information we are interested in is the device's friendly description:

string deviceDesc  = (string)OurKey.GetValue( "DeviceDesc" );

All that is left then is to deallocate any allocated memory and do something with the data that has been retrieved.

What's new? 

 1. Pre message filtering. The allows the messages that aren't WM_INPUT messages to behave normally.  ProcessRawInput returns true if it successfully decodes a keypress event else false. Returning true causing the message to not be sent to the WndProc method.       

private class PreMessageFilter : IMessageFilter
{
    public bool PreFilterMessage(ref Message m)
    {
        if (m.Msg != Win32.WM_INPUT)
        {
           // Allow any non WM_INPUT message to pass through
           return false;
        }
        
        return _keyboardDriver.ProcessRawInput(m.LParam);
    }
}

It is activated by the following code in the RawInput class

public void AddMessageFilter()
{
   if (null != _filter) return;

   _filter = new PreMessageFilter();
    Application.AddMessageFilter(_filter);
}

 2. Capture keypresses if top-most window. The wParam of the _rawBuffer.header tells us if the input occurred while the application was in the foreground. 

public static bool InputInForeground(IntPtr wparam)
{
   return wparam.ToInt32() == RIM_INPUT;
}

 3. Determine if the ctrl and alt keypress are the left or right version. When the RI_KEY_E0 flag is set it said that the EO bit is set, which means the right version of a key was pressed. The shift key is a little different. It is a right shift if the makecode has the SC_SHIFT_R bit set.

var isE0BitSet = ((flags & Win32.RI_KEY_E0) != 0);

private static int VirtualKeyCorrection(int virtualKey, bool isE0BitSet, int makeCode)
{
   var correctedVKey = virtualKey;

   if (_rawBuffer.header.hDevice == IntPtr.Zero)
   {
        // When hDevice is 0 and the vkey is VK_CONTROL indicates the ZOOM key
        if (_rawBuffer.data.keyboard.VKey == Win32.VK_CONTROL)
        {
	   correctedVKey = Win32.VK_ZOOM;
        }
   }
   else
   {
       switch (virtualKey)
       {
	   // Right-hand CTRL and ALT have their e0 bit set 
	   case Win32.VK_CONTROL:
	   	correctedVKey = isE0BitSet ? Win32.VK_RCONTROL : Win32.VK_LCONTROL;
		break;
	   case Win32.VK_MENU:
		correctedVKey = isE0BitSet ? Win32.VK_RMENU : Win32.VK_LMENU;
		break;
	   case Win32.VK_SHIFT:
		correctedVKey = makeCode == Win32.SC_SHIFT_R ? Win32.VK_RSHIFT : Win32.VK_LSHIFT;
		break;
	   default:
		correctedVKey = virtualKey;
		break;
	}
    }
   
    return correctedVKey;
}

Conclusion

Although the .NET Framework offers methods for most common purposes, the Raw Input API offers a more flexible approach to device data. The enclosed code and the explanations in this article will hopefully prove a useful starting point for anyone looking to handle multiple keyboards in an XP or Vista based application.

Sources

This article gives an overview of the different steps required to implement the Raw Input API. For further information on handling raw input:

History

  • March 2013 - Updated with most of the requested features added (VS2012)
    • Added handling of keypresses
    • Update devices on USB insertion/removal
    • Added proper 32/64bit support
    • Added option to capture keypresses if topmost window
    • Now gets device type from the raw data instead of the registry
    • Inherits from Native Window which makes the rawinput dll easier to consume
    • Detects the L/R versions of shift, control, and alt.
    • Developed on Windows 8 64bit
    • Add a Device Audit which writes to file all the information about the attached devices provided by RawInput.
  • March 2007 - Added WPF sample in response to user request
  • January 2007 - Original version 

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Authors

Steve Messer
Software Developer (Senior)
United States United States
No Biography provided

Emma Burrows
Software Developer
United Kingdom United Kingdom
Emma's first steps in programming took place at primary school over thirty years ago, thanks to a TI-99/4A and the LOGO language. Following a Master's degree in English Studies (obtained, strangely enough, with a paper on the birth of the microcomputer), Emma started her career in IT.
 
Over the last ten years, she has worked as a localiser, technical writer, editor, web designer, systems administrator, team leader and support engineer, before finally making the move into software development a few years ago. She is now thrilled on a daily basis that she is getting paid for writing code after doing it for free half her life!

Comments and Discussions

 
QuestionNewbie wants to run backgroundworker in 'Mouse' version PinmemberMember 935782130-Aug-12 3:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web03 | 2.8.140709.1 | Last Updated 9 Mar 2013
Article Copyright 2007 by Steve Messer, Emma Burrows
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid