Working with Unicode and MSLU - Common Problems

Introduction

The articles describes some of the common issues you'd come across while working with MSLU using MFC/Win32.

Background

Creating Unicode applications has always been an encouraging factor for developer and the users. However, the problem is the difficulty in supporting a Unicode application on Non-Unicode Windows Operating Systems (Windows 95/98/ME); developers had to support those customers as well. Because these platforms were not intended to support Unicode, which was introduced by the NT family of operating systems, the fallback was to write non-Unicode applications.

I have attempted to put across some of the common problems you would encounter, and how you can tackle them.

Working with MSLU — Common Problems

The CListCtrl controls in your application might not display the contents properly. this can happen with some other common windows controls. This is due to the fact that control notifications format for Unicode needs to be set specifically. We handled the WM_NOTIFYFORMAT message and explicitly return NFR_UNICODE for UNICODE configurations and returns NFR_ANSI for Non-UNICODE configurations.
```
LRESULT CSampleDlg :: OnNotifyFormat(WPARAM wParam, LPARAM lParam)
{
#ifdef _UNICODE
    return NFR_UNICODE;
#else
    return NFR_ANSI;
#endif
}
```
On Windows 98/ME, CRichEditCtrl doesn’t show the Unicode text, as it uses version 1.0 of CRichEditCtrl (window class RICHEDIT). The solution is to use version 2.0 (window class RICHEDIT20W). Changed the .rc file (resource script), so that "IDC_RICHEDIT_..." to refer to "RICHEDIT20W" class instead of "RICHEDIT".... Thats all....
On Windows 98 system, another issue was, we were not able to get the tool tips for some of the controls. This also needs NOTIFYFORMAT to be handled as described in point
Another problem is with the use of Set/GetMenuString and Set/GetMenuItemInfo functions on windows 98 system. This happens as the GetMenuItemInfoW function sometimes returns ANSI strings rather than Unicode ones. The workaround is to either use the GetMenuItemInfoA function or to use the MSLU GetMenuStringW function, which will work properly here. An error affecting InsertMenuItemW and SetMenuItemW was fixed at the same time (the MENUITEMINFO.cch member was being used to get the string length even though setting it is not required in those APIs).