From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Fri Dec 12 2003 - 06:26:05 EST
jameskass@att.net wrote:
> Philippe Verdy wrote,
>
> > Note that Windows keyboard drivers do not support input of Unicode code
> > points.
>
> Keyboard DLLs for modern Windows systems are Unicode-based.
I did not say they were not... I know that they _generate_ Unicode code
points, this does not mean that they offer an input method to compose a
Unicode code point numerically. The question was related to the input
method, not to the output of the keyboard driver.
Within the default keyboard drivers, you compose transparently
AltGr+NumPad(decimal OEM code) or AltGr+NumPad(0+decimal ANSI code) but
there's no equivalent to compose hexadecimal Unicode code point values or
decimal Unicode code point values.
This support is added by applications or by input controls such as RichEdit,
which take sequences of keystrokes that are _not_ translated to Unicode code
points by the driver, and emulate the input method by overriding their
normal translation by the driver. So these controls do not use only the
WM_CHAR interface, but directly override the keystroke messages before they
are translated by the keyboard driver during the call of TranslateMessage()
which will process the keystrokes into WM_CHAR messages.
An application that uses the RichEdit control does not need to take into
account the WM_CHAR message or not even the WM_SYSCHAR or WM_KEYPRESSED
messages as this is processed by the control itself. The application then
just needs to read what has been processed by the control by looking at its
edit buffer.
__________________________________________________________________
<< ella for Spam Control >> has removed Spam messages and set aside
Newsletters for me
You can use it too - and it's FREE! http://www.ellaforspam.com
This archive was generated by hypermail 2.1.5 : Fri Dec 12 2003 - 07:03:51 EST