Alexandre Julliard escribió:
Alex Villacís Lasso <a_villacis(a)palosanto.com> writes:
@@ -4159,7 +4161,9 @@ { WCHAR buff[256];
+ setlocale(LC_ALL, "C"); sprintfW( buff, szFloatFormatW, fltIn ); + setlocale(LC_ALL, ""); return VarDecFromStr(buff, LOCALE_EN_US, 0, pDecOut);
You can't do that, setlocale() affects the whole process. In any case we shouldn't need to go through a string to convert a float to a decimal.
Module: wine Branch: master Commit: ed58b1bad0f565b8a609803e29dbadfff651b444 URL: http://source.winehq.org/git/wine.git/?a=commit;h=ed58b1bad0f565b8a609803e29... Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Nov 7 18:24:15 2006 +0100 kernel32: Better workaround for the lack of locale environment variables on MacOS. This patch added the setlocale(LC_ALL, "") line to dlls/kernel32/locale.c . The oleaut32 tests for vartype.c have been failing since that time on non-English locales. I see now that setting the locale around calls of sprintfW() is not thread-safe. However, I think there is no big problem on going through a string in order to convert a floating-point number into a DECIMAL, since otherwise, we would need to implement our own bit-splicer for floating-point numbers. As long as the starting locale for sprintfW() is known to be the LC_NUMERIC="C", all other parsing should work as before the MacOS patch. Therefore I propose the attached patch. This patch simply sets setlocale(LC_NUMERIC, "C") at the end of LOCALE_Init() in dlls/kernel32/locale.c in order to guarantee that sprintfW will always use periods as decimal separators. Changelog: * Add setlocale(LC_NUMERIC, "C") after locale init in order to guarantee that initial numeric strings use a period as decimal separator. Fixes oleaut32 tests in non-English locales. -- The following cryptic message was allegedly found in the inner edge of a Windows XP installation CD: 4F6E65204F5320746F2072756C65207468656D20616C6C2C204F6E65204F5320746F2066696E6420 7468656D2C0D0A4F6E65204F5320746F206272696E67207468656D20616C6C20616E6420696E2074 6865206461726B6E6573732062696E64207468656D2E0A It is rumored that only a true Unix Wizard can decypher this mysterious message, which supposedly encodes the true nature and purpose of the software.