Page 1
Page 2
Page 3
Design decisions
Microsoft's preferred route for implementing
any new user input method is to attach to the SIP interface,
thus making the keyboard available to all applications.
Now as a general rule I'll try anything once, but registering
a new SIP input method via eVB is just going too far!
The replacement keyboard has been primarily
designed for use in locked-down industrial data capture
applications, where the user is restricted from accessing
any other built-in software. I therefore decided to keep
things as simple as possible.
The new keyboard is solely for use with
eVB applications, and we're going to build it using standard
forms and components (plus a little bit of tweaking via
the APIs).
Implementation (Problems, problems,
problems...)
In the accompanying eVB project you
should find the form mdiKeyboard. On the face of
it this is just a standard form with a PictureBox control
being used to display an image of our new keyboard. There
are unfortunately a few problems with this.
1) The keyboard form must appear and
then stay on top of any other forms you are currently displaying.
Otherwise it would be hidden as soon as you click back on
your application form.
2) The keyboard form must not ever receive
the focus. Normally the focus would shift to the new form,
but if that happens where would you send the keystrokes?
A couple of tweaks to the form's extended
property flags during the Load event makes sure these first
two problems aren't an issue for us. For good measure the
form is also prevented from generating any Activate events.
3) Which key is the user clicking?
Detecting which key has been pressed
is easy. We simply use the PictureBox's Click event coordinates,
divided by the key size, to look up the desired character
in the KeyMatrix array. The key definitions are set
up during the forms Load event.
4) We need to let the user know when
they've hit a key.
For visual feedback there is a black
key-sized command button hidden behind the PictureBox. Whenever
the user hits a key the button's coordinates and Z-Order
are changed, bringing it into view positioned over the key
that has just been clicked. A timer is use to hide the button
again after a short delay.
5) One of eVB's more unexpected 'features'
is its ability to ignore rapid click events. Although this
seems to be by design in order to prevent over-clicking,
it unfortunately means that our keyboard cannot cope with
fast keystrokes. So typing "Mississippi" becomes
"Misisipi".
Fortunately this can be solved using
the same black button we used for the visual feedback. Since
the button can also respond to Click events it can be used
to fire repeat key presses, allowing faster typing.
6) Finally we need to simulate SIP key
presses and send them to wherever the focus currently resides.
Although not commonly used the PostKeybdMessage
API call enables applications to generate virtual key press
events. Once generated, the operating system happily routes
these event messages to whichever control currently has
the focus.
Previous Page
Next Page