Prev: leak using Clipboard in Unicode with richedit
Next: Not able to save image using CWebBrowser2::ExecWB
From: Joseph M. Newcomer on 12 Dec 2006 16:47
See below...
On Tue, 12 Dec 2006 22:31:07 +0100, Norbert Unterberg <nunterberg(a)newsgroups.nospam>
wrote:

>
>I am German, so maybe I can help here a little bit.
>
>
>Elan Magavi schrieb:
>> I have been working with this app which allows users to type in a fixed
>> point value.. liike "1.045982"
>>
>> The files which are sent with the app as samples use a decimal, (English) as
>> the seperator. In Germany, it is a comma.
>>
>> I have used the GetNumberFormat api which will return that value as
>> 1,045982.
>>
>> That value is sent to a swscanf() like so
>>
>> swscanf(procStr,_T("%lf"),&dVal);
>
>Some general information about these functions and the German locales:
>
>* Code page and font settings have nothing to do with it. German uses the same
>windows character set and code page as the US version, as far as I know. It
>begins to get difficult if you move more to the east, there you get the eastern
>europe character sets. However, all characters that are used for number
>formatting are still the same (in the ASCII range).
>
>* GetNumberFormat() formats a numbers for sending them to the screen or to the
>printer to make it look nice. The output of GetNumberFormat can not be reliably
>parsed by any of the input functions, as far as I know of. The reason is that I
>don't know any input function that deals with the tousands separator or with a
>minus sign behind the number (-1245.6 could be displayed as "1.245,6-",
>depending on the language settings page in control panel.
>Even Excel does use the "nice" format for displaying the numbers in the data
>cells, but as soon as you edit a cell, you get the "simple" number format in the
>edit field.
>
>* So to send data to another application, you might better stick to the number
>formatting as done by the C/C++ runtime library. All the C/C++ runtime library
>functions obey the number format set by the current locale. HOWEVER, that locale
>is not automatically set to the current user's locale. For compatibility
>reasons, C programms are set to the "C" locale by default. If your application
>is locale-aware, you need to tell the library with a call to the setlocale()
>function.
****
AHA! That's what I was referring to, I just wasn't sure what was going on in the
libraries (see my earlier reply where I said that it wasn't what he was doing, but whether
or not the C libraries were seeing the right thing!)
****
>
>To set the printf/scanf formating to use the user's locale, you need to set at
>least the LC_NUMERIC locale:
> _tsetlocale(LC_NUMERIC, _T(""));
>
>A call to
> _tsetlocale(LC_ALL, _T(""));
>
>sets all locale info to the user's default language, that includes string
>sorting, date/time formatting and character handling functions.
>Note that you can explicitly set the German locale with something like
> _tsetlocale(LC_NUMERIC, _T("deu"));
>on any language version of Windows.
>
>Changing the number formating with LC_NUMERIC to German only changes the "." to
>",", so -1.2345 will be printed as "-1,2345".
>
>
>* Now you need to decide what output format you want to use for your files. It
>depends on what type of software will read the files.
> - The German version of Excel respects the user's locale, so it will read
>files with the German formatted numbers (1,23456).
> - On the other hand, most simple programs "hacked together" do not call
>setlocale(), so they need the American (international?) number format, i.e. in
>config files.
> - Well written programs that read numbers from the user or from a file ask the
>user if the number format is German or English, or try to auto-detect the number
>format.
>
>You see, there is no easy answer (as always)
>
>I hope I could help!
>
>Norbert Unterberg
>
****
Helped me, too. I've not used the C library formatting for international apps in a while,
so I wasn't aware of this! Thanks.
joe
****
>
>Norbert
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Elan Magavi on 12 Dec 2006 17:54

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:4e8un2pe0shlue8965tqtc6ecfb1af8mnc(a)4ax.com...
> See below...
> On Tue, 12 Dec 2006 20:02:31 GMT, "Elan Magavi" <Elan(a)nomailnospam.com>
> wrote:
>
>>
>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>>news:bdttn2pl25umnnikqddjoc769f9s26gcd4(a)4ax.com...
>>> See below...
>>> On Tue, 12 Dec 2006 16:59:29 GMT, "Elan Magavi" <Elan(a)nomailnospam.com>
>>> wrote:
>>>
>>>>I have been working with this app which allows users to type in a fixed
>>>>point value.. liike "1.045982"
>>>>
>>>>The files which are sent with the app as samples use a decimal,
>>>>(English)
>>>>as
>>>>the seperator. In Germany, it is a comma.
>>>>
>>>>I have used the GetNumberFormat api which will return that value as
>>>>1,045982.
>>>>
>>>>That value is sent to a swscanf() like so
>>>>
>>>>swscanf(procStr,_T("%lf"),&dVal);
>>> ****
>>> Why are you using such a complicated means of converting a decimal
>>> number
>>> to a double? If
>>> you are in VS.NET, it is a lot simpler to write
>>>
>>> dVal = _tstof(procStr);
>>
>>The app is a fairly simple MFC app. no .Net functionality.
> ****
> What does .NET have to do with it? The MFC unmanaged code feature in
> VS.NET implements
> _tstof, and it does not have anything whatsoever to do with ".NET"
> technology!


You mentioned VS.net.. I am using VS2003 so I assume that's what you were
referring to.



>
> Note that Unicode floating point conversion was apparently not supported
> in VS6, not in
> swscanf and not in wtof.
> ****
>>
>>>
>>> But you have clearly written this as Unicode-aware, but why are you
>>> calling a Unicode-only
>>> function? If you have to scan it using such a clumsy mechanism, at
>>> least
>>> use _stscanf.
>>> Otherwise, you should not use _T() around the formatting string, but
>>> just
>>> use L"%lf" since
>>> it is Unicode-only.
>>> ****
>>
>>God I luv ya Joe. ! Given me a few things to look at there. And a good
>>scolding to boot.
>>
>>
>>>>
>>>>My question is, how do I test this? I have another machine setup in the
>>>>shop
>>>>and it is sent to German number formatting. I believe I have done this
>>>>wrong
>>>>or do not understand how I should be handling this becauseI do get the
>>>>wrong
>>>>values back from the swscanf call. Specifically it doesn't interpret the
>>>>comma correctly.
>>> ***
>>> How did you "set" it to German? (This can make a difference;
>>> unfortunately, I don't know
>>> how to do this but it might help someone else with more experience tell
>>> if
>>> something is
>>> wrong)
>>
>>I have a machine with a fresh XP install.
>>I went into Regional Options and set German(GERMANY) in the 'Standards and
>>Formats' Tab.
> ****
> As I said, I can't comment on this, but it might help someone else
> diagnose the problem.
> ****
>>
>>
>>>
>>> I just read the code for swscanf, and it uses the symbol
>>> ___decimal_point,
>>> which is an
>>> alias for __decimal_point (note the 3_ vs. 2_ prefix, no I have no idea
>>> why there is a
>>> macro that defines the 3_ version to be the 2_ version). This variable
>>> is
>>> set in
>>> initum.c, which uses the locale to call __getlocaleinfo to obtain the
>>> LOCALE_SDECIMAL
>>> separator.
>>
>>Sounds like it ought to work then eh?
> ****
> That's why I'd be tempted to single-step through the code and see what it
> is trying to do.
> Ultimately, the floating point conversion done from the kernel is supposed
> to be
> locale-aware, so if everything looks good up to that point and it fails,
> at least you'll
> know why it is failing and can go after a very specific problem.
> ****
>>
>>
>>>
>>> So the first thing I'd check is what this value is set to. It should be
>>> a
>>> ',' in the
>>> German version, and if it isn't, it suggests that the locale is actually
>>> not properly set.
>>
>>Yes .. it is.
> ****
> Well, the issue is not whether or not you've done the right things, but
> whether or not the
> C library *sees* the right things, in the right way.
> ****
>>
>>
>>
>>> If you believe the locale is correctly set, set a breakpoint at the
>>> function
>>> __init_numeric and then start the program and study what is going on in
>>> the debugger.
>>
>>WIll do.
>>
>>
>>>
>>> If everything appears to be correct, the next step is the fact that
>>> having
>>> parsed the
>>> string, swscanf calls _fassign, which at that point I think disappears
>>> into the kernel. So
>>> if everything is correct up to that point, there's something deeper
>>> wrong.
>>> joe
>>> ****
>>
>>
>>wow.. joe.. thanks.. it will take me a while to crunch this..
>>
>>
> Joseph M. Newcomer [MVP]
> email: newcomer(a)flounder.com
> Web: http://www.flounder.com
> MVP Tips: http://www.flounder.com/mvp_tips.htm


From: Joseph M. Newcomer on 12 Dec 2006 19:44
Yes, VS 2003 is also known as VS.NET 2003.

When I had to use Unicode under VS6, to do floating conversions I had to first convert the
text to ANSI, because there was no support for Unicode floating point to double
conversion.
joe

On Tue, 12 Dec 2006 22:54:37 GMT, "Elan Magavi" <Elan(a)nomailnospam.com> wrote:

>
>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>news:4e8un2pe0shlue8965tqtc6ecfb1af8mnc(a)4ax.com...
>> See below...
>> On Tue, 12 Dec 2006 20:02:31 GMT, "Elan Magavi" <Elan(a)nomailnospam.com>
>> wrote:
>>
>>>
>>>"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
>>>news:bdttn2pl25umnnikqddjoc769f9s26gcd4(a)4ax.com...
>>>> See below...
>>>> On Tue, 12 Dec 2006 16:59:29 GMT, "Elan Magavi" <Elan(a)nomailnospam.com>
>>>> wrote:
>>>>
>>>>>I have been working with this app which allows users to type in a fixed
>>>>>point value.. liike "1.045982"
>>>>>
>>>>>The files which are sent with the app as samples use a decimal,
>>>>>(English)
>>>>>as
>>>>>the seperator. In Germany, it is a comma.
>>>>>
>>>>>I have used the GetNumberFormat api which will return that value as
>>>>>1,045982.
>>>>>
>>>>>That value is sent to a swscanf() like so
>>>>>
>>>>>swscanf(procStr,_T("%lf"),&dVal);
>>>> ****
>>>> Why are you using such a complicated means of converting a decimal
>>>> number
>>>> to a double? If
>>>> you are in VS.NET, it is a lot simpler to write
>>>>
>>>> dVal = _tstof(procStr);
>>>
>>>The app is a fairly simple MFC app. no .Net functionality.
>> ****
>> What does .NET have to do with it? The MFC unmanaged code feature in
>> VS.NET implements
>> _tstof, and it does not have anything whatsoever to do with ".NET"
>> technology!
>
>
>You mentioned VS.net.. I am using VS2003 so I assume that's what you were
>referring to.
>
>
>
>>
>> Note that Unicode floating point conversion was apparently not supported
>> in VS6, not in
>> swscanf and not in wtof.
>> ****
>>>
>>>>
>>>> But you have clearly written this as Unicode-aware, but why are you
>>>> calling a Unicode-only
>>>> function? If you have to scan it using such a clumsy mechanism, at
>>>> least
>>>> use _stscanf.
>>>> Otherwise, you should not use _T() around the formatting string, but
>>>> just
>>>> use L"%lf" since
>>>> it is Unicode-only.
>>>> ****
>>>
>>>God I luv ya Joe. ! Given me a few things to look at there. And a good
>>>scolding to boot.
>>>
>>>
>>>>>
>>>>>My question is, how do I test this? I have another machine setup in the
>>>>>shop
>>>>>and it is sent to German number formatting. I believe I have done this
>>>>>wrong
>>>>>or do not understand how I should be handling this becauseI do get the
>>>>>wrong
>>>>>values back from the swscanf call. Specifically it doesn't interpret the
>>>>>comma correctly.
>>>> ***
>>>> How did you "set" it to German? (This can make a difference;
>>>> unfortunately, I don't know
>>>> how to do this but it might help someone else with more experience tell
>>>> if
>>>> something is
>>>> wrong)
>>>
>>>I have a machine with a fresh XP install.
>>>I went into Regional Options and set German(GERMANY) in the 'Standards and
>>>Formats' Tab.
>> ****
>> As I said, I can't comment on this, but it might help someone else
>> diagnose the problem.
>> ****
>>>
>>>
>>>>
>>>> I just read the code for swscanf, and it uses the symbol
>>>> ___decimal_point,
>>>> which is an
>>>> alias for __decimal_point (note the 3_ vs. 2_ prefix, no I have no idea
>>>> why there is a
>>>> macro that defines the 3_ version to be the 2_ version). This variable
>>>> is
>>>> set in
>>>> initum.c, which uses the locale to call __getlocaleinfo to obtain the
>>>> LOCALE_SDECIMAL
>>>> separator.
>>>
>>>Sounds like it ought to work then eh?
>> ****
>> That's why I'd be tempted to single-step through the code and see what it
>> is trying to do.
>> Ultimately, the floating point conversion done from the kernel is supposed
>> to be
>> locale-aware, so if everything looks good up to that point and it fails,
>> at least you'll
>> know why it is failing and can go after a very specific problem.
>> ****
>>>
>>>
>>>>
>>>> So the first thing I'd check is what this value is set to. It should be
>>>> a
>>>> ',' in the
>>>> German version, and if it isn't, it suggests that the locale is actually
>>>> not properly set.
>>>
>>>Yes .. it is.
>> ****
>> Well, the issue is not whether or not you've done the right things, but
>> whether or not the
>> C library *sees* the right things, in the right way.
>> ****
>>>
>>>
>>>
>>>> If you believe the locale is correctly set, set a breakpoint at the
>>>> function
>>>> __init_numeric and then start the program and study what is going on in
>>>> the debugger.
>>>
>>>WIll do.
>>>
>>>
>>>>
>>>> If everything appears to be correct, the next step is the fact that
>>>> having
>>>> parsed the
>>>> string, swscanf calls _fassign, which at that point I think disappears
>>>> into the kernel. So
>>>> if everything is correct up to that point, there's something deeper
>>>> wrong.
>>>> joe
>>>> ****
>>>
>>>
>>>wow.. joe.. thanks.. it will take me a while to crunch this..
>>>
>>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer(a)flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
>
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Elan Magavi on 12 Dec 2006 21:10

"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message
news:l5jun2p1uke4jgmn97gtm1j8o27gh8ukum(a)4ax.com...
> Yes, VS 2003 is also known as VS.NET 2003.
>
> When I had to use Unicode under VS6, to do floating conversions I had to
> first convert the
> text to ANSI, because there was no support for Unicode floating point to
> double
> conversion.
> joe
>


The text is ANSI in this case. Sample files for the app. Values are
representes at n.nnnnnnn where the decimal point is a period. . Germans
trying to use them are having a problem where text to float conversions are
truncating everything beyond the decimal point. I am muttling through the
solution still...


From: Mihai N. on 12 Dec 2006 23:41
Everything 100% right until here, you stole my answer :-)
But for the stuff below I have something to say:

> * Now you need to decide what output format you want to use for your files.
It
> depends on what type of software will read the files.
> - The German version of Excel respects the user's locale, so it will read
> files with the German formatted numbers (1,23456).
> - On the other hand, most simple programs "hacked together" do not call
> setlocale(), so they need the American (international?) number format, i.e.
in
> config files.
> - Well written programs that read numbers from the user or from a file
ask the
> user if the number format is German or English, or try to auto-detect the
number
> format.



1. If you read/write from/to files (serialization, save/load),
then you want to have the file locale independent (otherwise a file saved
by your application on English system will be misinterpreted by your
application loading it on a German system).
Storage and comunication (new, clipboard, etc) should be locale independent.

"All language editions can read one another's documents"
("Microsoft Win32 Internationalization Checklist" from
Nadine Kano's book, http://www.microsoft.com/globaldev/dis_v1/disv1.asp)
And see also http://www.mihai-nita.net/20051025a.shtml

2. Talking to the user (let's say you scanf a string from a dialog box)
should use the user locale. All internal data representation is
locale-independet, you convert to/from user format "at the border"
(when you take data from the user or when you present data to the user).

3. Talking with buggy applications, you emulate what they do (although
they do it wrong). This area of Excel is a good example of how NOT to do
things. For instance, if I would have to "talk" to Excel, I would stay
away from CSV and go with XML.
(See http://blogs.msdn.com/michkap/archive/2005/09/17/470413.aspx
including the comments)

--
Mihai Nita [Microsoft MVP, Windows - SDK]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: leak using Clipboard in Unicode with richedit
Next: Not able to save image using CWebBrowser2::ExecWB