[C++/Windows API] Edit Control characters not showing up

[boogerjones]

I have a simple dialog box with an edit control. The following text, "迴辭駔駪餵騠駢馝", shows up in the title bar just fine, but shows up as partial blocks in the edit control. Unicode enabled. The font for the dialog box is MS Shell Dlg. The same font for an edit control in C# displays the same text just fine. VS 2010. I can't figure this one out. Any ideas?

Here's my code:

#include "resource.h"
#include <Windows.h>

#pragma comment(linker,"\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' \
version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")

INT_PTR WINAPI DlgProc(HWND hDlg, UINT msg, WPARAM wParam, LPARAM lParam)
{
    switch(msg)
    {
    case WM_INITDIALOG:
            SetDlgItemText(hDlg, IDC_EDIT1, L"迴辭駔駪餵騠駢馝");
            SetWindowText(hDlg, L"迴辭駔駪餵騠駢馝");
            break;
    case WM_COMMAND:
            if (wParam == IDOK) return EndDialog(hDlg, 0);
    }

    return 0;
}

int WINAPI wWinMain(HINSTANCE hInst, HINSTANCE hPrev, LPWSTR strCmdLine, int show)
{
    return DialogBox(hInst, MAKEINTRESOURCE(IDD_DIALOG1), 0, DlgProc);
}

And the dialog:

IDD_DIALOG1 DIALOGEX 0, 0, 316, 183
STYLE DS_SETFONT | DS_MODALFRAME | DS_FIXEDSYS | WS_POPUP | WS_CAPTION | WS_SYSMENU
FONT 8, "MS Shell Dlg", 400, 0, 0x1
BEGIN
    DEFPUSHBUTTON   "OK",IDOK,205,162,50,14
    PUSHBUTTON      "Cancel",IDCANCEL,259,162,50,14
    EDITTEXT        IDC_EDIT1,95,77,214,12,ES_AUTOHSCROLL
END

Here's the window:

[boogerjones]

Now I'm getting nothing. This is really driving me nuts. Does anyone have any idea what's happening here? And I don't know why the snipping tool is clipping the windows.

[tareqsiraj]

did you set UNICODE and _UNICODE in your pre-processor defines?

[boogerjones]

  On 31/08/2010 at 12:30, tareqsiraj said:

did you set UNICODE and _UNICODE in your pre-processor defines?

Yep. The file is saved in unicode (I've tried both UTF-8 and UCS-2) format, too.

[boogerjones]

And 10 minutes later, without modifying anything (on my computer or in Visual Studio), just recompiling:

Edit: I've got an idea of what's going on: Visual Studio is saving the *.cpp files in some kind of funny format. Depending on the time of day (or something else that I can't figure out), the text gets encoded correctly or not.

[Andre S. Veteran]

Yeah it's probably something like that. Store your strings in an external text file with the correct encoding and see if it fixes that.

  Quote

In addition to the letters of the English alphabet ("A" through "Z" and "a" through "z"), the digits ("0" through "9"), and the space, only the following characters are portable:

% & + , - . : = _

When naming files, variables, and other objects, only these characters should be considered for use.

https://www.securecoding.cert.org/confluence/display/cplusplus/MSC09-CPP.+Character+Encoding+-+Use+Subset+of+ASCII+for+Safety

This quite clearly applies to string literals.

[hdood]

Strings should really be stored in a resource file too. You can easily make a (RAII) class that allocates/loads/frees a resource string, like resstring sdf(IDS_SDF).

Also, the native Unicode format on Windows is little-endian UTF-16.

[boogerjones]

The point of this is not to develop secure coding practices or make a string-loading class. I'm simply interested in why a valid wide-character string is being displayed in an edit control incorrectly. I actually think it's an operating system problem now because after restarting my computer, the boxes are back. If I switch the Windows 7 display language to, say, German, and back to US English then things work fine. So it has something to do with how Windows is translating the text or mapping the dialog font. But according to MSDN, the MS Shell Dlg font and it's variant, which usually maps to Tahoma, should display the text correctly no matter what display language I'm using in Windows.

I'll try loading the string from a resource file to see what happens.

[hdood]

  On 01/09/2010 at 19:31, boogerjones said:

I actually think it's an operating system problem now because after restarting my computer, the boxes are back. If I switch the Windows 7 display language to, say, German, and back to US English then things work fine.

Have you checked what it's mapping to on your system (HKLM\Software\Microsoft\Windows NT\CurrentVersion\FontSubstitutes) when it's screwing up? It sounds like it might be mapping to a font that doesn't contain the characters, although with the one picture you have that shows both the boxes and correct characters, maybe not.

  On 01/09/2010 at 19:31, boogerjones said:

should display the text correctly no matter what display language I'm using in Windows.

Isn't it only designed to map to a font that can support the characters used in the currently selected language for non-unicode programs under the region and language control panel? I'm pretty sure this is Microsoft Sans Serif in most western languages.

Have you tried asking on the Microsoft forum? Maybe the UI development section?

[boogerjones]

Thanks for your help, guys. Actually, I think my Windows installation was simply hosed. I'm somewhat embarrassed to admit that I had a ton of software installed on it for testing purposes, much of it in beta stages and some of it Visual Studio addins, and there was probably some conflict I'll never figure out. I zeroed my hard drive (to be sure), restored to a backup base Windows installation, installed Visual Studio, and now I haven't seen the problem again. It just seemed too weird of a problem to be related to my code.

How frustrating. But I guess that shows how important it is to be working with a clean system; you'll never know the cause of some strange phenomenon. I'll post back here if I still have trouble, but I think this was a case of Browser Toolbar Syndrome.