skip to main | skip to sidebar
Yort on .NET
This is where ‘Yort’ praises, rants, raves and other wise talks nonsense about Microsoft .NET and Visual Studio. Or anything else related to software development or Microsoft that he feels like throwing in. It’s his blog after all…

Saturday, November 18, 2006
On-screen Keyboards
Recently, I wanted to create an on screen keyboard for use with our POS. Actually, I wanted a full keyboard for our ‘kiosk’ mode, and either a full keyboard or more likely a numeric keypad for the POS mode when running with a touch screen.

So, how do you create a virtual, on screen keyboard ? Creating a form/usercontrol with buttons or some other control(s) on it to represent the keyboard is relatively simple. What’s difficult is knowing where to send the key data when the control is clicked, because when you click on the virtual keyboard it tends to get focus, taking it away from the input field that needs the data.

Googling the problem I found several samples that simply raised an event from the on screen keyboard form/control, but that still leaves you with the issue of passing on the key data to some unknown edit field. Most of these samples assumed the keyboard control was either on the same form as the field receiving the key data, or that a reference to the control could be provided, which is fine if you only want to deal with forms within your own application, but sucks otherwise.

A few other samples worked by using API’s to obtain the handle of the control that currently has focus before the keyboard form/control is activated. When the buttons on the virtual keyboard are clicked, the key data is sent to the ‘remembered’ window handle and then the original window is refocused using API’s, or the window is refocused first and then SendKeys is used. This doesn’t work very well though. If the virtual keyboard window overlaps the client window then you get ‘flickering’ as the focus changes between the windows. Also it seems some key data just gets ‘lost’ if you hit buttons on the virtual keyboard quickly, although I’m not sure why.

In the end, thanks to two http://www.codeproject.com/ articles and another Google search, as well as some trial and error on my part, I managed to find the 3 magic things you must do to make an on screen keyboard work. These are;

Show your virtual keyboard form without ‘activation’, so it doesn’t get focus when the keyboard is shown.
Intercept the WM_MOUSEACTIVATE message and return MA_NOACTIVATE as the result.
Most important of all – you must NOT use controls that can get focus to represent your buttons.
The third point is the one that I missed for quite a while. Say you place a button control on your form for every ‘key’ on the virtual keyboard. You’ve overridden the WM_MOUSEACTIVATE event so clicking on the form won’t activate it – but you haven’t overridden the individual button control’s so they can still get focus, and when they do they will cause the parent form to be activated as well. If you use a label, picture box or some other control that can’t get focus though, then the form won’t get activated even when the control is clicked – which means you’re free to use SendKeys to pass on the keystrokes. This works exceedingly well, there is no flickering, and none of the keystrokes seem to get lost. Best yet, the code is relatively simple.
So, how exactly do you build the virtual keyboard ?
I recommend you grab a copy of FoxholeWilly’s keyboard control from CodeProject at http://www.codeproject.com/cs/miscctrl/touchscreenkeyboard.asp
This gives you a nice looking, resizable, keyboard. It also supports both alphabetical and QWERTY layouts, as well as a ‘kids’ version. It doesn’t have the Numeric Keypad like I wanted, but with a little image editing and some tweaking of the code it’s easy enough to add.
Unfortunately, this control doesn’t take care of points 1 and 2 from before, or actually pass on the key data for you. To do this, place the control on a host form and connect the control’s
UserKeyPressed event to an event handler. In that event handler place the following line of code;
SendKeys.Send(e.KeyboardKeyPressed);
Because FoxholeWilly’s control already provides a SendKeys formatted string as an event argument, that’s the only line of code needed to pass on the key data.
Now, to prevent the form receiving focus or being activated when it’s shown, simply override the CreateParams property on the host form, like this;
private const int WS_EX_NOACTIVATE = 0×08000000;

protected override CreateParams CreateParams
{
get
{
CreateParams createParams = base.CreateParams;
createParams.ExStyle = createParams.ExStyle & WS_EX_NOACTIVATE;
return createParams;
}
}
Finally, you need to prevent the form getting focus or being activated when it or the keyboard control are clicked on. This is as easy as adding the following code to the host form;
private const int WM_MOUSEACTIVATE = 0×0021;
private const int MA_NOACTIVATE = 0×0003;
protected override void WndProc(ref Message m)
{
//If we’re being activated because the mouse clicked on us…
if (m.Msg == WM_MOUSEACTIVATE)
{
//Then refuse to be activated, but allow the click event to pass through (don’t use MA_NOACTIVATEEAT)
m.Result = (IntPtr)MA_NOACTIVATE;
}
else
base.WndProc(ref m);
}
This code actually came from a comment posted by Dirk Moshage, on Randy More’s CodeProject article (http://www.codeproject.com/samples/onscreenkeyboard.asp) about creating an on screen keyboard. However, because Randy’s keyboard project uses button controls to represent the buttons on screen, most people found the above code didn’t work properly because the child windows (buttons) still got activated, and then activated the parent anyway. In our case, neither FoxholeWilly’s keyboard control or the picturebox it uses to show the keyboard can get focus, which means the WM_MOUSEACTIVATE code actually works the way it’s intended.
That’s all there is to it. Once you have your host form and control configured, you can run the project. Simply put keyboard focus in any control on any window, and use the mouse (or your touch screen) to click on your virtual keyboard. As you click each virtual button, the appropriate key stroke is sent to the control that currently has focus, and the focus remains where it is.
Of course there’s a lot more you can do to improve your keyboard, such as adding a sound when keys are clicked on or implementing ‘type rate’ so keystrokes are sent repeatedly while the mouse button is held down over a particular key. For a basic keyboard though, you should have all you need.
Posted by Yort at 11/18/2006 03:01:00 PM