Prev: Advice on an Undo/Redo feature
Next: Custom Retail Kiosk hardware & Software Solution
From: senn on 23 Jun 2010 01:27

"Helmut Meukel" <Helmut_Meukel(a)NoProvider.de> skrev i meddelelsen
news:hvreh2$g5m$1(a)news.eternal-september.org...
> "senn" <senn(a)homeplace&.fix> schrieb im Newsbeitrag
> news:uj1BAGlELHA.4816(a)TK2MSFTNGP04.phx.gbl...
>> Is there any api that can set the decimal separator to
>> point in the current running program/or thread - not the system setting.
>> I don't think so. The imposter has a declaration to it. This should
>> be placed in the Procedure/or Function to be effective. But vb6 ? Any
>> circumvention?. /se
>>
>
>
> Hmm,
>
> why?
> Isn't this why M$ created locale aware functions like CDbl to convert
> text values correctly to floatingpoint numbers?
> If you need to read values from text files with a decimal point in a
> locale with the comma as decimal separator, you can always use the
> old Val("textvalue with decimal point").
>
> But I would consider an app, that insists the user has to enter
> floatingpoint
> values with an point while the local setting is a comma, as a gross
> violation
> of usability standards. On my keayboard I would be handicapped in using
> the numeric keypad, because due to my locale the decimal separator
> generated there is the comma.
>
> Helmut.

Answer addresses Ralph too,

Doing vb6 math on a machine having the system
set to comma as the decimal seperator, the result on
left side of an assignment is always coerced to use of comma.
It's very annoying. Consider using the result from
the first assignment on the right side of the next assignment,
like this, as a simple example with variants:

A=2.7+ 5.843 'A will have the comma separator, as 8,543
B=A+4.38 'An error will araise here.
C=A+B

Apparently, to circumvent this, one can do:

A=Str$(2.7+5.843) 'A will now at least have the point "8.543"
B= Str$(Val(A)+4.38)
C=Str$(Val(A)+Val(B)) 'C is read out to a textbox having a point.

You may think, why should C be read out having a point.
The answer; a lot of machine tools in european countries
with comma as native, operate those machines as using
point in data in/outputs. Consider writing programmel for use
in this area in those countries. It would be unnatural
using commas, right. For instance the Okuma Lathe is used
all over in europe. Though, this lathe also can be bought equiped
with the Swedish language (a comma country). The normal is to
operate this brand with a control having data in/output use of
point as the decimal separator.
/se


From: Kevin Provance on 23 Jun 2010 02:02
"senn" <senn(a)homeplace&.fix> wrote in message
news:%2336TySpELHA.4816(a)TK2MSFTNGP04.phx.gbl...
:
:
: Answer addresses Ralph too,
:
: Doing vb6 math on a machine having the system
: set to comma as the decimal seperator, the result on
: left side of an assignment is always coerced to use of comma.
: It's very annoying. Consider using the result from
: the first assignment on the right side of the next assignment,
: like this, as a simple example with variants:
:
: A=2.7+ 5.843 'A will have the comma separator, as 8,543
: B=A+4.38 'An error will araise here.
: C=A+B
:
: Apparently, to circumvent this, one can do:
:
: A=Str$(2.7+5.843) 'A will now at least have the point "8.543"
: B= Str$(Val(A)+4.38)
: C=Str$(Val(A)+Val(B)) 'C is read out to a textbox having a point.
:
: You may think, why should C be read out having a point.
: The answer; a lot of machine tools in european countries
: with comma as native, operate those machines as using
: point in data in/outputs. Consider writing programmel for use
: in this area in those countries. It would be unnatural
: using commas, right. For instance the Okuma Lathe is used
: all over in europe. Though, this lathe also can be bought equiped
: with the Swedish language (a comma country). The normal is to
: operate this brand with a control having data in/output use of
: point as the decimal separator.

cenn, cenn, cenn

You've made no indication as to what the actual error number or message is.
Are we supposed to guess?


From: senn on 23 Jun 2010 02:17

"Helmut Meukel" <Helmut_Meukel(a)NoProvider.de> skrev i meddelelsen
news:hvreh2$g5m$1(a)news.eternal-september.org...
> "senn" <senn(a)homeplace&.fix> schrieb im Newsbeitrag
> news:uj1BAGlELHA.4816(a)TK2MSFTNGP04.phx.gbl...
>> Is there any api that can set the decimal separator to
>> point in the current running program/or thread - not the system setting.
>> I don't think so. The imposter has a declaration to it. This should
>> be placed in the Procedure/or Function to be effective. But vb6 ? Any
>> circumvention?. /se
>>
>
>
> Hmm,
>
> why?
> Isn't this why M$ created locale aware functions like CDbl to convert
> text values correctly to floatingpoint numbers?

MS also, as I mentioned, in their newer programming tools (the dotnet)
created a declaration to force the current thread using (en-us).
What MS do always seems to be either right or wrong. In latest times
mostly wrong. A PC standing in a class-rum on a technical educational
school equiped with a dedicated program and for a dedicated use, does
not need to consider any problem in changing the system setting to point.
In fact my own PCs, all of them, uses point setting. I never noticed any
problem with it, but have problem with a comma setting when developing
math parser in vb5. It would be foolish asking customers to change the
system settings. Perhaps that's why MS made a dedicated declaration
for changing it in a programs current thread, instead.
/se

> If you need to read values from text files with a decimal point in a
> locale with the comma as decimal separator, you can always use the
> old Val("textvalue with decimal point").
>
> But I would consider an app, that insists the user has to enter
> floatingpoint
> values with an point while the local setting is a comma, as a gross
> violation
> of usability standards. On my keayboard I would be handicapped in using
> the numeric keypad, because due to my locale the decimal separator
> generated there is the comma.
>
> Helmut.

From: Helmut Meukel on 23 Jun 2010 05:29
"senn" <senn(a)homeplace&.fix> schrieb im Newsbeitrag
news:%2336TySpELHA.4816(a)TK2MSFTNGP04.phx.gbl...
>
> Doing vb6 math on a machine having the system
> set to comma as the decimal seperator, the result on
> left side of an assignment is always coerced to use of comma.
> It's very annoying. Consider using the result from
> the first assignment on the right side of the next assignment,
> like this, as a simple example with variants:
>
> A=2.7+ 5.843 'A will have the comma separator, as 8,543
> B=A+4.38 'An error will araise here.
> C=A+B
>


Hi, Senn.

My systems are all set to German, German keyboard.
So Windows is using a comma as decimal separator.
With all three variables dimmed as Variants, the code
above runs just fine.
VB treats the result of 2.7 + 5.843 as a number (actually
a double) when storing it in A.
Debug.Print VarType(A) will return 5 (= vbDouble)
If you step though your code and hover over A with the
Mouse pointer VB will display 8,543 or 8.543 depending
on your system settings, but that's just display, because
- as ralph already wrote - there is no decimal separator
in the internal representation of numbers.
The next line B=A+4.38 will NOT cause any error
VB will happily add 4.38 to 8.543 and store 12.923 in B.
You can check the VarType of B and it will be 5 again,
regardless of the setting of your system.
Same for the third line of your code: the result in C will be
21.466 and again a Double.

If you however Dim all three variables as string,
you'll still get no error, and for the first 2 lines the code
works just fine.
In A is the result of numerical add stored as string:
"8,543" or "8.543" depending on your system settings.
In B is then "12,923" or "12.923" depending on your
settings. That's because of the '+' operator and the second
value being a number VB tries first to perform an add
and coerce the string value back to a number.
The sesulting numeric value of 12.923 is then stored
in B as a string with the appropriate decimal separator.

The result of the third line C=A+B however is different:
VB checks the type of both operants and both are strings,
so it treats the '+' operator not as add but as concatenate
(same as '&'). This behavior is "by design", because in
early basics there was no '&' operator and '+' was used
for both - adding numerical values and concatenating
strings.
When M$ added '&' to the language, they didn't change
the behavior of the '+' operator for backward compatibility.
(in VB-DOS and VB1 there was no '&' operator, don't
know for VB2, in VB3 it was there, and the manual
cautioned against usage of '+' with strings).

So adding 2 strings using '+' will concatenate the strings
regardless of the values they contain.
You will get "8,54312,932" or "8.54312.932" depending
on youe system settings.

Your problem however isn't the internal representation
of a floating point value in VB6, it's how to transfer it to
and fro an external device. This is best done using strings
due to the different internal representation of numbers
between Intel CPUs and most CPUs used in external
devices like lathes and most types of PLCs like Siemens
S5 or S7. (big endian vs. little endian).

And those external devices are *not* locale aware, they
use always the decimal point.
But that's no problem, just use Val for converting string
values you get from the external device to numerical data
and Str$ for converting numerical data to strings to send
to the external device.

Helmut.



From: senn on 23 Jun 2010 06:54

"Helmut Meukel" <Helmut_Meukel(a)NoProvider.de> skrev i meddelelsen
news:hvsk5a$vqv$1(a)news.eternal-september.org...
> "senn" <senn(a)homeplace&.fix> schrieb im Newsbeitrag
> news:%2336TySpELHA.4816(a)TK2MSFTNGP04.phx.gbl...
>>
>> Doing vb6 math on a machine having the system
>> set to comma as the decimal seperator, the result on
>> left side of an assignment is always coerced to use of comma.
>> It's very annoying. Consider using the result from
>> the first assignment on the right side of the next assignment,
>> like this, as a simple example with variants:
>>
>> A=2.7+ 5.843 'A will have the comma separator, as 8,543
>> B=A+4.38 'An error will araise here.
>> C=A+B
>>
>
>
> Hi, Senn.
>
> My systems are all set to German, German keyboard.
> So Windows is using a comma as decimal separator.
> With all three variables dimmed as Variants, the code
> above runs just fine.
> VB treats the result of 2.7 + 5.843 as a number (actually
> a double) when storing it in A.
> Debug.Print VarType(A) will return 5 (= vbDouble)
> If you step though your code and hover over A with the
> Mouse pointer VB will display 8,543 or 8.543 depending
> on your system settings, but that's just display, because
> - as ralph already wrote - there is no decimal separator
> in the internal representation of numbers.
> The next line B=A+4.38 will NOT cause any error
> VB will happily add 4.38 to 8.543 and store 12.923 in B.
> You can check the VarType of B and it will be 5 again,
> regardless of the setting of your system.
> Same for the third line of your code: the result in C will be
> 21.466 and again a Double.
>
> If you however Dim all three variables as string,
> you'll still get no error, and for the first 2 lines the code
> works just fine.
> In A is the result of numerical add stored as string:
> "8,543" or "8.543" depending on your system settings.
> In B is then "12,923" or "12.923" depending on your
> settings. That's because of the '+' operator and the second
> value being a number VB tries first to perform an add
> and coerce the string value back to a number.
> The sesulting numeric value of 12.923 is then stored
> in B as a string with the appropriate decimal separator.
>
> The result of the third line C=A+B however is different:
> VB checks the type of both operants and both are strings,
> so it treats the '+' operator not as add but as concatenate
> (same as '&'). This behavior is "by design", because in
> early basics there was no '&' operator and '+' was used
> for both - adding numerical values and concatenating
> strings.
> When M$ added '&' to the language, they didn't change
> the behavior of the '+' operator for backward compatibility.
> (in VB-DOS and VB1 there was no '&' operator, don't
> know for VB2, in VB3 it was there, and the manual
> cautioned against usage of '+' with strings).
>
> So adding 2 strings using '+' will concatenate the strings
> regardless of the values they contain.
> You will get "8,54312,932" or "8.54312.932" depending
> on youe system settings.
>
> Your problem however isn't the internal representation
> of a floating point value in VB6, it's how to transfer it to
> and fro an external device. This is best done using strings
> due to the different internal representation of numbers
> between Intel CPUs and most CPUs used in external
> devices like lathes and most types of PLCs like Siemens
> S5 or S7. (big endian vs. little endian).
>
> And those external devices are *not* locale aware, they
> use always the decimal point.
> But that's no problem, just use Val for converting string
> values you get from the external device to numerical data
> and Str$ for converting numerical data to strings to send
> to the external device.
>
> Helmut.
>
What you write aren't the case on my XP-machine with installed
vb5. Of course I hovered over the variables in the assignments
in the IDE of vb5.
I'll see if I can take a screen-shot when doing the hover. I can quite
understand it's difficult for you to believe, when it's different on your
end.
But I'm asking myself now; if vb5 could be
different to vb6 in this respect. I'll be back with a screen-shot.

Until then thanks for participating - constructionally - in this problem.
/se

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Advice on an Undo/Redo feature
Next: Custom Retail Kiosk hardware & Software Solution