On 08/31/2002 04:50:48 PM "Doug Ewell" wrote:
>> Of course, one limitation is that apps can alter
>> the data before they put it on the clipboard; in fact, an app might
>> opt to convert everything to some default codepage and put only that
>> on the clipboard.
>
>It would make sense for a Unicode-specific tool such as this to only
>accept data in WM_UNICHAR format, not WM_CHAR. Unicode data in WM_CHAR
>format is pretty much guaranteed to have gone through some conversion
>step.
A couple of corrections. First, if an app supports only WM_CHAR and not
also WM_UNICHAR, that does not imply that it uses a legacy encoding. If
running on NT/2K/XP and registered as a wide (Unicode) app, the WM_CHAR
messages will supply UTF-16 code units. If running on Win9x/Me and
registered as an ANSI app, the WM_CHAR messages supply codepoints in some
Windows codepage, but the app can still store text as Unicode if it takes
the WM_CHAR data and immediately converts it.
Secondly, the question of whether an app supports WM_UNICHAR in addition to
WM_CHAR has no direct bearing on what it puts onto the clipboard -- the two
are independent. If an app encodes text as Unicode, though, it is true that
it would probably include Unicode-encoded plain text among the formats it
copies to the clipboard.
- 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 : Sun Sep 01 2002 - 08:37:26 EDT