On 04/07/2001 08:46:41 AM unicode-bounce wrote:
>> (b) If you install the new version of richedit20.dll, does that actually
>> add the WM_UNICHAR functionality automatically to applications that
>> previously were using richedit20 v.3? (e.g. Outlook Express...?)
>
>Only applications that have code to use the message can... thats how
>messages work under Windows.
The RichEdit control itself has code to interpret the message. That's why
it works in WordPad on Win98: you don't need to update WordPad itself; just
adding the new version of RichEdit allows WordPad to receive any Unicode
character (including supplementary plane characters) from Keyman.
Office 2000 apps also use RichEdit for various text controls, e.g. in the
search dialog, and updating RichEdit causes them to also automatically
respond to WM_UNICHAR without the app having been re-written.
>> (c) Has anybody got a list of existing Win98 applications that can make
>use
>> of the WM_UNICHAR functionality?
>
>I doubt there are very many at all, yet. People have to write them (see
>(b)).
As Marc mentioned, there are no shipping apps yet, at least that I know of.
Once you install something with the new version of RichEdit (like Office
XP), then any apps that use RichEdit should respond to WM_UNICHAR. The
question is then what apps use RichEdit (and can handle Unicode).
Other apps can also put support for WM_UNICHAR into their window
procedures, which is what Michael had in mind. Our WorldPad editor (which
in it's first version will use Graphite for rendering; OT support will
probably be added later) does so. It may be a few months away from
shipping, though.
If you're writing an app and want to make use of WM_UNICHAR, it is now
documented in the MSDN library:
http://msdn.microsoft.com/library/psdk/winui/keybinpt_4q42.htm. Note one
thing, though: this documentation indicates that it is available only on
Whistler (Windows XP). In fact, it can be used on all other flavours of
Win32. It is specifically the action that DefWindowProc takes in converting
a WM_UNICHAR to one or more WM_CHARs that is supported only in Windows XP.
On earlier versions of Windows, WM_UNICHAR is basically ignored
(DefWindowProc takes the default action of returning false).
An input method can determine whether or not the app will support
WM_UNICHAR (0x0109, by the way) by first *sending* (not posting)
UNICODE_NOCHAR (0xFFFF). If the app *does* support WM_UNICHAR, then it
processes the message containing UNICODE_NOCHAR by returning true, and
that's a signal to the IM that the app does support WM_UNICHAR. The action
that DefWindowProc takes on receiving a WM_UNICHAR containing
UNICODE_NOCHAR is to return false, so if the app ignores the message, the
input method will get back false. The IM should interpret that to mean that
the app doesn't support WM_UNICHAR. (Again, that action for DefWindowProc
is the default action that it takes for any message that it is not aware
of, and so this works on down-level versions of Win32.) At that point, the
IM needs to choose some graceful fallback, like sending WM_CHAR instead.
Note also that the wParam contains a Unicode character expressed in UTF-32.
The documentation doesn't make this clear.
- Peter
---------------------------------------------------------------------------
Peter Constable
Non-Roman Script Initiative, SIL International
7500 W. Camp Wisdom Rd., Dallas, TX 75236, USA
Tel: +1 972 708 7485
E-mail: <peter_constable@sil.org>
This archive was generated by hypermail 2.1.2 : Fri Jul 06 2001 - 00:17:15 EDT