From: Elan Magavi on
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);

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.

I am assuming that the functions used for swscanf() are different in
Germany? Is this a code page issue? I am sort of lost!

I am certainly doing this wrong.

Thanks

Elan


From: Joseph M. Newcomer on
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);

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.
****
>
>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 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.

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.
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.

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
****
>
>I am assuming that the functions used for swscanf() are different in
>Germany? Is this a code page issue? I am sort of lost!
>
>I am certainly doing this wrong.
>
>Thanks
>
>Elan
>
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

"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.

>
> 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.


>
> 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?


>
> 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.



> 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..



From: Norbert Unterberg on

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.

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


Norbert
From: Joseph M. Newcomer on
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!

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