From: Dee Earley on
On 23/06/2010 11:54, senn wrote:
> 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.

Remember that the tool tip shows the number converted to a text using
YOUR locale.
This will not effect how it is used or handled internally.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
From: senn on

"ralph" <nt_consulting64(a)yahoo.net> skrev i en meddelelse
news:71u226pv19qks3ce2ebqppurpvk1u680ud(a)4ax.com...
> On Tue, 22 Jun 2010 23:26:01 +0200, "senn" <senn(a)homeplace&.fix>
> wrote:
>
>>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
>>
>
> You probably need to supply more information on where and why this is
> a particular problem in your domain.
>
> To a 'running' program or within 'code' a *number* is just a number -
> there are no decimal separators, plus/minus signs, leading/trailing
> placeholders, currency symbols, etc.. These only appear when a number
> is formatted for display. So tell us something about how and when you
> are desiring a specific format.
>
> -ralph

I think MS made a sabotage by letting vb6 and lower
handle the coersion like it does. Perhaps that's why they
made a declaration in newer programming tools, so that
the programmer have the option to decide, whether he
wants a coercion between the point and comma in the
assignments without alter the system setting of this.
As I mentioned, I want to work with the
point as a decimal separator in my in/output data still
my system setting are in comma. The reason for this are
as mentioned earlier, I have an Okuma lathe simulator.
It is simply too much replacing the evil auto comma producing
with the point before sending out the calculated data to a
textbox or other outputbox. And it is also not reasonable
requireing the lathe operator working with comma in the
lathe simulator, and afterwards working with point on
the lathe control as point here is the native. Using Val()
on string input-data on the right side of the assignments
does not solve the output problem of having these with points.
The way I showed it above also takes too much. I wonder
if it's possible to build-in a declaration from VBA. I think
it has such a declaration.
/se




From: ralph on
On Wed, 23 Jun 2010 19:31:34 +0200, "senn" <senn(a)homeplace&.fix>
wrote:

>
>"ralph" <nt_consulting64(a)yahoo.net> skrev i en meddelelse
>news:71u226pv19qks3ce2ebqppurpvk1u680ud(a)4ax.com...
>> On Tue, 22 Jun 2010 23:26:01 +0200, "senn" <senn(a)homeplace&.fix>
>> wrote:
>>
>>>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
>>>
>>
>> You probably need to supply more information on where and why this is
>> a particular problem in your domain.
>>
>> To a 'running' program or within 'code' a *number* is just a number -
>> there are no decimal separators, plus/minus signs, leading/trailing
>> placeholders, currency symbols, etc.. These only appear when a number
>> is formatted for display. So tell us something about how and when you
>> are desiring a specific format.
>>
>> -ralph
>
>I think MS made a sabotage by letting vb6 and lower
>handle the coersion like it does. Perhaps that's why they
>made a declaration in newer programming tools, so that
>the programmer have the option to decide, whether he
>wants a coercion between the point and comma in the
>assignments without alter the system setting of this.
>As I mentioned, I want to work with the
>point as a decimal separator in my in/output data still
>my system setting are in comma. The reason for this are
>as mentioned earlier, I have an Okuma lathe simulator.
>It is simply too much replacing the evil auto comma producing
>with the point before sending out the calculated data to a
>textbox or other outputbox. And it is also not reasonable
>requireing the lathe operator working with comma in the
>lathe simulator, and afterwards working with point on
>the lathe control as point here is the native. Using Val()
>on string input-data on the right side of the assignmen
>does not solve the output problem of having these with points.
>The way I showed it above also takes too much. I wonder
>if it's possible to build-in a declaration from VBA. I think
>it has such a declaration.
>/se
>

I'm still confused (which unfortunately is not uncommon for me <g>) by
all this "MS stabotage", newer tools "declarations" (*below), VB5 vs
VB6, O/S? vs O/S?, threads<?>, ... , and then you really threw me off
when "VBA" made an appearence. <g>

A number is just a number as far as your code is concerned. Issues
always come up, and always have come up, when you attempt to format a
number into a string or "de-format" a string into a number. And it
isn't just the decimal separator - you can have equal issues with HEX
strings or strings that happen to look like HEX, or SciNotation, for
example.

There is no hidden mystery here. No sabotage. No vast right-wing
conspiracy. That is just the way it is, and shouldn't come as a
surprise to any programmer.

What IS a surprise to me is that you are somehow expecting ANY string
to number converstion process to automatically know what you want it
to do! (Been watching too much TV I think.)

Admittedly things were simpler at the beginning of i18n - you set the
locale and you were done - programmers were given separate routines
(those that read the locale settings, and those that took a default)
and a programmer only had to learn who was going to use it and choose
one or the other routine accordingly.

[* .Nxt (and other languages) due to 'values' treated as objects with
contained methods supplies a middle ground - allowing you to pick a
"default" for essentially the same routine. You might even consider
writing your own 'value class' to do the same. But that is a story
best discussed elsewhere.]

My best guess for a solution to your problem is to follow the advice
others have already given you. Perhaps, changing the "code behind" a
TextBox or "OutputBox" to accept a global flag and act accordingly, or
simply modify the entry process so that 'decimals' are handled
separately as someone suggested. Either way you have to step in and
tell 'it' what you want to happen when and where, and give up looking
for bogeymen.

-ralph
From: senn on

"ralph" <nt_consulting64(a)yahoo.net> skrev i meddelelsen
news:7th426p0ep7d8bs89631ha1b4ofkcpa6fm(a)4ax.com...
>
> What IS a surprise to me is that you are somehow expecting ANY string
> to number converstion process to automatically know what you want it
> to do! (Been watching too much TV I think.)
>
>
> -ralph

Do I detect a freudian slip here - a ralp.
And a guessing in a conversion process. <g>






From: ralph on
On Wed, 23 Jun 2010 22:08:53 +0200, "senn" <senn(a)homeplace&.fix>
wrote:

>
>"ralph" <nt_consulting64(a)yahoo.net> skrev i meddelelsen
>news:7th426p0ep7d8bs89631ha1b4ofkcpa6fm(a)4ax.com...
>>
>> What IS a surprise to me is that you are somehow expecting ANY string
>> to number converstion process to automatically know what you want it
>> to do! (Been watching too much TV I think.)
>>
>>
>> -ralph
>
>Do I detect a freudian slip here - a ralp.
>And a guessing in a conversion process. <g>
>

Naw. My mobility scooter has been acting up all day, and those d*mn
kids have been playing in the yard again.

-ralph