Re: SetThemeAppProperties and SetWindow Theme do not effect Unicode data handling

Ivo,

I am quite sure that is not true that controls in Windows 2000 and on always
use Unicode. Most controls if you create them with CreateWindowA, store
their data in Multibyte form. This is not true for some of the common
controls such as listviews and treeviews, but it is true for older controls
like push buttons, edit fields, and listboxes.

Our product uses a special character set. Our characters are not in any of
the Windows multibyte codepages. So, when running in Multibyte mode, we use
Multibyte fonts which have our glyphs at the codepoints normally used for
national language characters in the upper half of the 256 character
codepage. This has worked fine up until I enabled XP Visual Styles; then it
stopped working for our Japanese customers.

Most controls store their data in Multibyte and write the data to the screen
using TextOutA (or some other ANSI API) and the characters appear correctly.
Since our fonts are Symbol charset, when drawing the data, GDI uses the
single byte codepoints rather than treating the Multibyte data as 2 byte
Japanese characters.

However, on XP machines with the input language for non-Unicode programs set
to Japanese and XP Visual Styles enabled, the characters do not appear
correctly. I believe that the controls are converting the data to Unicode
and searching for the Unicode codepoints in our fonts. The conversion
process ignores the font's charset and determines the Multibyte codepoints
are Japanese characters. Since our fonts do not include Japanese glyphs,
some other font is substituted and our characters are not displayed.

After a fair amount of research and empirical testing, I believe when XP
visual styles are enabled and the input language for non-Unicode programs is
set to Japanese, there is no way to force controls store their data in
multibyte. Therefore, I plan to provide my customers with another version
of my product which does not have XP visual styles enabled.

If someone can provide some other work-around, I would greatly appreciate
hearing about it.

BTW I can not modify my product to do the conversion myself and use the
Widechar versions of the GDI APIs. My product is a development language and
our interfaces are documented to use the ANSI APIs and provide the normal
ANSI behavior. Furthermore, even if I could figure out how to get the
correct behavior, we do not have the resources to rewrite our entire
interface to Windows APIs simply to work around this oddity in Windows
behavior.

Thank you.

David Liebtag
IBM APL Products and Services


.

Loading