Re: String codification

[Germán Arias]

On 2012-02-24 20:45:22 -0600 Ondřej Hošek <ondra.hosek@gmail.com> wrote:

> On Fri, Feb 24, 2012 at 06:25:05PM -0600, Germán Arias wrote:
>> Well, I tested today in a Windows 7, but with UTF16 don't works, so
>> I tried with  WindowsCP1252 and works fine. But I don't know if this
>> encoding can be problematic for other languages. I did this change
>> at line 302 in file WinNSMenu.m. Are there objection to do this
>> change?
> 
> While I am not a GNUstep developer (and my opinion may therefore be
> uncalled for)

Don't worry, your opinion is also important.

> 
> The reason UTF-16 didn't work is simple: Windows ships two versions of
> any function or struct that stores a string. One of them ends with A
> (for "ANSI"), the other with W (for "wide"). When the ANSI version of
> the function is called, whatever codepage the user has chosen is used.
> (For speakers of Spanish, French and Portuguese, this is CP1252.) The
> Wide version, on the other hand, allows UTF-16. The argument type,
> however, is also changed: where the ANSI version takes chars (and
> types derived from char), the wide version takes wchar_ts.
> 
> Now, by default, if you call a function without the character width
> suffix, the ANSI version is taken unless the macros UNICODE and
> _UNICODE are defined. Of course, the ANSI functions choke on UTF-16
> at least due to the NUL bytes they see.
> 
> The solution is to fetch the UTF-16 version of the string
> (NSUnicodeStringEncoding), type-pun it from a const char * to a
> const wchar_t *, and pass it to AppendMenu, changing the called
> function from AppendMenu to AppendMenuW. (By explicitly using the
> width suffix, it is guaranteed that the Wide version is called,
> regardless of whether UNICODE or _UNICODE are #defined.)

I will test this tomorrow. So thanks for the trick.

> 
> Hope that clears things up.
> 
> Cheers,
> ~~ Ondra