This project is read-only.

Injecting Keyboard Events

Jul 14, 2010 at 9:13 PM



I've been doing some work on using this wrapper to embed a browser in a WPF application.  It was all going smoothly until I ran into a problem with injecting keyboard events.  I try to call inject keyboard events from System.Windows.Input key up and key down event handlers.  This all seems OK as the injection seems to be going well-- when I created a test webpage, I was able to see that the webpage was indeed receiving the proper key codes but only the Return and Tab keys are actually working.  I can tab from link to link and then follow a link by pressing Return, but if I focus on a textarea or text input, it won't input the characters I type.  Has anyone had this problem?


Here's an example of my KeyDown code...

void Container_KeyDown(object sender, System.Windows.Input.KeyEventArgs e){
      int a = KeyInterop.VirtualKeyFromKey(e.Key);
      _webView.InjectKeyboardEvent(new System.IntPtr(), AwesomiumDotNet.WM.KeyDown, (uint) a, a);
      e.Handled = true;

Jul 14, 2010 at 9:22 PM

What version of Awesomium are you using?

I'm using 1.08 and wasn't able to get keyboard presses to work either (although I never tested tab or return).

If you figure it out, I'd love to know what you did.

Jul 14, 2010 at 9:32 PM
Edited Jul 14, 2010 at 9:39 PM

I'm using 1.08 as well.


Jul 15, 2010 at 12:13 AM
Edited Jul 15, 2010 at 12:16 AM
Take a look at the latest change in WpfSample for how to hook the keyboard messages:
Jul 15, 2010 at 3:07 AM

So I'm having the same problem: tab and return work but other keys don't.

And it appears that the code sample is for Awesomium 1.5 and above as I don't think WebKeyboardEvent is in 1.08.

Perhaps this is a bug in 1.08 ?


Here's the code that I'm using that works for tab and return only:

    Public Sub SendKeys(ByVal Mess As Windows.Forms.Message)

            webView.InjectKeyboardEvent(New System.IntPtr(0), CUInt(Mess.Msg), CUInt(Mess.WParam), 0)

    End Sub

Jul 15, 2010 at 10:17 PM
@Dan, I haven't seen the rest of your code, but you seem to be missing LParam, which is also a significant parameter.

@Matthew, Using KeyDown and KeyUp events is not the best idea. KeyDown/KeyUp mean very different things in WPF and Win32. For each KeyDown event in WPF you would first have to send a WM.KeyDown message, then check if the virtual key corresponds to a unicode character and send a WM.Char message if it does. For correct behaviour, you would also need to reconstruct the LParam, which is difficult to do based only on the information available in KeyEventArgs (and it's not the same as WParam like in your code, see

The code I linked above shows how to get the window messages before they get to WPF and are abstracted. In 1.08, instead of using the WebKeyboardEvent, just pass the msg, wparam and lparam to InjectKeyboardEvent like this (in C#):

webView.InjectKeyboardEvent(IntPtr.Zero, (uint)msg, (uint)wParam, (int)lParam);

This works for me in 1.08. I don't know of any easier way to correctly handle keyboard input in WPF.
Jul 16, 2010 at 1:01 AM
Anybody have any good methods for doing this within XNA? I can somewhat get it working, but only in caps and it puts at least four characters in every time I press a key.
Jul 17, 2010 at 1:00 AM
Edited Jul 17, 2010 at 1:01 AM
For XNA, add this class:

and use it to hook keyboard messages like this:
textInputHandler = new MessageHook(Window.Handle);
textInputHandler.MessageReceived += new EventHandler(textInputHandler_MessageReceived);

void textInputHandler_MessageReceived(object sender, EventArgs e)
    if (isKeyBoardFocused)
Jul 19, 2010 at 5:50 PM



I had copied that code exactly before, but it doesn't quite work for me.  I should mention that I'm developing for the Microsoft Surface...perhaps ScatterView and the other surface classes don't align perfectly with WPF?  Anyway, I wrote up a little JavaScript method to check for keyboard input and the webview is definitely receiving the input with what I'm assuming are the proper keycodes.  Unfortunately, it fails to handle them properly.   Now I'm wondering if perhaps there is a bug within Awesomium that prevents the value attribute in text inputs from being altered because I can't even visibly change the input values by direct JavaScript injection.

I should mention that the enter key works properly and submits forms when they are in focus...but that won't be much use until the other keys are working.  Rather mysterious, eh?

Jul 19, 2010 at 9:42 PM

As it turns out, I was just missing the mysterious icudt38.dll.  Everything works like a charm now.


@Dan:  Find the icudt38 dll on your computer and add it to your output directory, since it sounds like we had identical problems.

Jul 19, 2010 at 10:11 PM
Edited Jul 19, 2010 at 10:15 PM
matthew_smith wrote:

As it turns out, I was just missing the mysterious icudt38.dll.  Everything works like a charm now.


Oh yeah...

"Awesomium works fine without icudt38.dll, except that you cannot send keyboard events to text areas."

Wow... 8 MB just for keyboard input. Although on the page above is a reduced size icudt38.dll from Adam that's only 4 MB uncompressed.

Thanks for the info Matthew and Anthrax11.


Oct 12, 2010 at 9:20 PM

UPX now works properly on icudt and others, so you can compress the library to about 35-40%.