MSLU and the Windows Common Controls

by Michael S. Kaplan, published on 2005/08/15 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/15/451653.aspx

Recently in the microsoft.public.platformsdk.mslayerforunicode, someone with the handle Alpha Siera posted the following:

Hi,

I have converted one application to use MSLayer for unicode for Win 9x. The application is staticaly linked with unicows.lib (Visual Studio 6.0).

**What I am doing ?

The application uses CTreeCtrl and I have derived one of my class from CTreeCtrl. Plus I am capturing message like TVN_ITEMEXPANDING and TVN_SELCHANGED in my derived class.

**My Problem

When the application was not using MS Layer for unicode derived class (derived from CTreeCtrl) was able to receive notifications messages. Wherease when the application is linked to use unicows.lib it does not receive any notification messages on 9x.

**What I have tried ?

If I remove unicows.lib from linking the application works fine and properly receives notification messages on Windows 9x but when unicows.lib is included it stops receiving any messages.

Please advice where i am wrong .. or any work around for the problem.

Regards

Alpha

The issue here is one that is discussed in the article Cathy and I wrote about the layer (MSLU: Develop Unicode Applications for Windows 9x Platforms with the Microsoft Layer for Unicode), in the section entitled What MSLU does and does not address:

MSLU was designed to be a translation layer for Windows NT-based Unicode APIs on Windows 9x. The layer, however, is not a complete rewrite of Windows 9x, nor is it some type of Windows NT emulator for the Windows 9x platform. It does not provide support for Unicode-only scripts like Devanagari or Georgian, or for any of the new supplementary characters that have been added to Unicode (specifically UTF-16) as surrogate pairs. It also cannot provide extended international support beyond the platform that it runs on, since it is relying on the operating system for any particular international functionality that developers may want to provide. For example, MSLU does not provide updated versions of the cp_*nls files that contain support for code pages, nor does it add support on Windows 95 for GetLocalInfo LCTypes for which the operating system has no specific information.
Instead, developers should consider MSLU as one part of a whole package of international or Unicode-focused components provided by Microsoft. These components include RichEdit, which provides rich text support and can also be used for more comprehensive support with plain text. Windows common controls provide a standard way to implement many commonly used interface components. Uniscribe allows the support and rendering of complex scripts (writing systems that need additional processing prior to display, such as Arabic, Devanagari, and Thai). GDI+ extends Uniscribe to provide easier developer integration and more consistent rendering for mixed scripts. MLang provides many features such as character encoding, string conversion, and font linking support, and the Text Services Framework (TSF) provides a common framework for text input and natural language technologies.
Since all of these components have a Unicode solution, MSLU does not attempt to provide overlapping functionality. With the use of these other components, you can go a step beyond MSLU's support for Unicode and handle multilingual input, processing, and rendering, so that applications can go beyond the codepage-based support provided by Windows 9x.
For more information on these other technologies, what versions to use, and how to implement and deploy them, go to the MSDN® Online homepage.

The topic being sort of referred to is in the Platform SDK and is entitled Other Existing Unicode Support, and it contains the following section:

Existing Unicode-enabling Technologies

The Microsoft Layer for Unicode does not duplicate the following Unicode-enabling technologies.

Technology	Description
Common Controls (commctrl32)	Supports Unicode through CCM_GETUNICODEFORMAT, CCM_SETUNICODEFORMAT, and WM_NOTIFYFORMAT and controls such as TreeView and ListView. On Windows Me/98/95, you must use comctl32.dll of version 5.80 or later. This ships with Microsoft Internet Explorer 5.0.
Input Method Editor (IME)	Allows users to enter complex characters and symbols, such as Japanese Kanji, by using a standard keyboard. Windows Me/98 supports the Unicode version of these functions except for ImmIsUIMessage. On Windows 95, these functions are stubbed, thus you can statically link to the Unicode versions.
MLang, the MultiLanguage Object	Provides services for applications on international issues, including conversion between code pages, font linking, code page "guessing", line breaking, and more.
Rich Edit 2.0 and later	Provides a programming interface for formatting text. Rich Edit 2.0 supports Unicode, and Rich Edit 3.0 has expanded support for complex scripts, partly due to Uniscribe.
Uniscribe	Supports the processing of complex scripts, that is, those scripts that need special processing to properly render them. It includes a subset of the features found in GDI+.

Now luckily one of our two internationalization MVPs (Ted, in this case) responded right away:

In your class that uses the CTreeCtrl (e.g. your CDialog) handle OnNotifyFormat (WM_NOTIFYFORMAT message) and return NFR_UNICODE.  Also, send a message CCM_SETUNICODEFORMAT with TRUE to the tree control.

And then Alpha responded that this did the trick, and also wondered why Microsoft did not document this issue, though I think the rest of the post kind of belies the premise of that question! :-)

Now I think MSLU was a cool project to work on, and it enables some incredible scenarios. But when you compare it to the items in the above table that actually do support Unicode versus just wrapping the non-Unicode functions and converting prn, it really does tend to pail a bit....

Hmmm.... I just noticed what seems to me like a doc bug, maybe -- since GDI+ is basically frozen from a language list standpoint, Uniscribe can truly be considered a superset of GDI+, not a subset (unless you think of international support as a subset of the other things GDI+ does like image-handling methods)....

This post brought to you by "ޜ" (U+079c, a.k.a. THAANA LETTER ZAA)

go to newer or older post, or back to index or month or day