Opened 6 years ago

Closed 6 years ago

#9572 closed defect (fixed)

Incorrect displaying labels of controls that begins from 0xFF letter in ansi build

Reported by: kosenko Owned by: vadz
Priority: normal Milestone: future
Component: wxMSW Version:
Keywords: Cc:
Blocked By: Blocking:
Patch: yes

Description

wx 2.8.7 UNICODE=0
msvc 7.1, xp sp2
Tested on OS with codepage windows-1251
In this codepage 0xFF letter is cyrillic Ya http://en.wikipedia.org/wiki/Ya_%28Cyrillic%29
In windows-1252 codepage it looks like it is y with Umlaut (diacritic) letter http://en.wikipedia.org/wiki/Windows_1252, http://en.wikipedia.org/wiki/%C5%B8

Steps to reproduce:

  1. Apply samples.patch on minimal sample
  2. Run this sample
  3. Select Menu/Help/About

Expected result: six controls with XTest label, where X is 0xFF letter in your current codepage
Actual result: wxButton, wxCheckBox, wxStaticText and wxToggleButton has no label. wxTextCtrl has wrong label ([][]Edit). wxComboBox has label as expected.

Reason:
::CreateWindowEx do not sets correctly labels that begins with 0xFF letter. (But ::SetWindowText works as expected)

Proposed solution:
Make ::SetWindowText call after creation of all controls in ansi build to do not miss any one.

Attachments (3)

samples.patch download (1.5 KB) - added by kosenko 6 years ago.
Patch for minimal sample to reproduce this bug
0xff_letter.patch download (388 bytes) - added by kosenko 6 years ago.
Patch that fixes this bug
lists.zip download (2.4 KB) - added by kosenko 6 years ago.
Disassembled CreateWindowExA function with my comments

Download all attachments as: .zip

Change History (6)

Changed 6 years ago by kosenko

Patch for minimal sample to reproduce this bug

Changed 6 years ago by kosenko

Patch that fixes this bug

comment:1 follow-up: Changed 6 years ago by vadz

  • Owner set to vadz
  • Status changed from new to accepted

The good news is that it works just fine if you do

    wxString label(L"\u044fTest");

in the trunk which means that it probably also works in Unicode build of 2.8.

But I have really no idea why does CreateWindowExA() mishandle this. It seems (judging from its disassembly) to just call MultiByteToWideChar() and then CreateWindowExW() and MultiByteToWideChar() handles -1 just fine as can be demonstrated by this program:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int main()
{
    char buf[] = { 0xff, 0 };
    wchar_t wbuf[128];
    if ( !MultiByteToWideChar(1251, 0, buf, -1, wbuf,
                              sizeof(wbuf)/sizeof(wbuf[0])) ) {
        MessageBoxW(0, L"MultiByteToWideChar() failed", NULL, MB_ICONERROR);
        return 1;
    }

    MessageBoxW(0, wbuf, L"Unicode", MB_ICONINFORMATION);
    return 0;
}

(compile with cl mb2wc.cpp /link user32.lib).

So while the patch is probably harmless and should be applied, I'd like to understand what's going on before applying it...

comment:2 in reply to: ↑ 1 Changed 6 years ago by kosenko

The good news is that it works just fine if you do in the trunk which means that it probably also works in Unicode build of 2.8.

This bug exists in 2.8.7 and trunk 2008-06-14 rev. 54223 in ansi build only. Unicode build is not affected on both cases. I have just tested that.

(compile with cl mb2wc.cpp /link user32.lib).

MultiByteToWideChar call in your sample mb2wc.cpp works as expected and shows small Cyrillic letter ya at my computer.

But I have really no idea why does CreateWindowExA() mishandle this.

I have debugged CreateWindowExA functions and it looks like problem is related to loading "large ansi strings", i.e. _RtlInitLargeAnsiString@12 function is not called if label begins with 0xFF. But I do not know what that means. Disassembled list is in attachment.

Changed 6 years ago by kosenko

Disassembled CreateWindowExA function with my comments

comment:3 Changed 6 years ago by vadz

  • Resolution set to fixed
  • Status changed from accepted to closed

Thanks for your analysis! I've looked further at this and found that apparently the window name parameter to CreateWindowEx() can be something called "an ordinal" (whatever it is). There is no documentation whatsoever about it and even Google doesn't find anything but there is clearly code to handle ANSI string starting with 0xff and wide strings starting with 0xffff specially.

I don't think it makes sense to investigate this further, thanks for the effort you already put into this! I've applied your patch as r54331 to both branches, thanks!

Note: See TracTickets for help on using tickets.