WM_GETTEXTLENGTH returns double size
wine-devel at sun.consumer.org.il
Thu Jun 13 08:14:59 CDT 2002
I think the correct thing to do is return the output of *_tcslen*. Since
we don't have TCHARs inside wine, this translates to using wcslen if
wer'e a UNICODE function, or strlen if wer'e not (notice that while
_mbslen returns the number of characters in the string, strlen returns
the number of bytes in the string. See
Also, assuming you are implementing this over my GetFontLanguageInfo
patch (the title was "Extremely preliminary BiDi patch" - not commited
yet), you can use that function to find out whether special MBCS
processing is necessary for the current locale. Just like I said in that
email, I am not sure it is worth it, performance wise.
If you do decide to use my patch, notice that GetFontLanguageInfo is a
skeleton. I did include an MBCS pattern to those languages I happened to
know required MBCS, but as this is far from my main field of experties,
errors are not unlikely.
Andriy Palamarchuk wrote:
>Andriy Palamarchuk wrote:
>>This happens in code which unmaps message, mapped
>>ASCII to Unicode.
>>See windows/winproc.c, function
>> case WM_GETTEXTLENGTH:
>> case CB_GETLBTEXTLEN:
>> case LB_GETTEXTLEN:
>> /* there may be one DBCS char for each
>> return result * 2;
>>What is the correct way to handle double-byte
>>characters in this situation?
>The best approach I could think of is to send an
>internal message from this location which returns
>lengths of Unicode and ASCII strings. This message
>will be processed only by our controls.
>If lengths of the Unicode strings are the same this
>means that both are generated by our code for the same
>text and I return the A length. If the lengths are
>different this means length was generated not in our
>code and I keep existing behavior (return double
>original Unicode length).
>This method looks pretty safe and gives correct
>behavior in almost all cases.
>Do You Yahoo!?
>Yahoo! - Official partner of 2002 FIFA World Cup
More information about the wine-devel