Decimal separator

[Frank]

Dear all,

Is there any way to configure in MapInfo the default symbol (point/
comma) used as decimal separators?

I am using the MI2SVG.mbx tool (for exporting a map from MapInfo map
window to a SVG file) on two machines with different MapInfo language/
region configuration (ie one is in English and one in Dutch).
Exporting on the English machine doesn't show any problems, however
exporting on the Dutch machine results in comma's instead of points
used as decimal separator.
Eg. coordinate result from English MapInfo: 213615.2,-524509.4
Coordinate result from Dutch MapInfo: 213615,2,-524509,4
To make the MI2SVG tool work on Dutch machines as well I have to
somehow change the symbol used as decimal separator.

Regards,
Frank

[Uffe Kousgaard]

This should do the trick:

Set Format Date "US"

Regards
Uffe Kousgaard

[Uffe Kousgaard]

I was a little fast on the copying from the help file. This should be
better:

Set Format Number "9,999.9"

Regards
Uffe Kousgaard

[Zery]

I'm about to give you this
"....in your Dutch machine, go to "Regional and Language Settings", I believe it's in Control Panel (if your using XP), there's an option there to change decimal separator from comma to point. In Regional Options tab, click Costumize, you will find the option...."

Uffe's answer is better. :-)


Regards,
Zery

--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en

[Spencer Simpson]

Actually, your answer is better (Although more complicated than necessary),
and Uffe's answer won't actually work.

Why? Each running MapBasic application has its own collection of the values
you can change in MapBasic with "set" (Actually, there are two collections
each, one for the application and one for Run Command strings). The
MapBasic window has its own collection as well. If there are three MapBasic
applications running, that's seven different environments.

A "Set" command in one environment won't affect the settings in another
environment.

Since the original poster is running an MBX, there's no way into the MBX's
environment. He or she would have to add the "Set" comment in the source
code, recompile, and run the custom MBX.

However, since there's a difference on machines with different language
settings, changing your Windows Regional and Language Settings should give
you the results you are looking for.

A slightly simpler solution is to refrain from clicking on "Customize" in
Regional and Language Settings, instead selecting "English (United States)"
from the dropdown next to the button.

________________________________

Spencer

[Uffe Kousgaard]

Hi Spencer,

Since MI2SVG comes with source code, I sort of expected OP to add the
command and recompile.

http://www.gisnet.com/notebook/SVG_mapping.php

Actually Bill ought to update his tool.

Regards
Uffe

[Zery]

Thank you Spencer, it came across my mind before, "does the 'set' in mapbasic window will affect the entire mapinfo session or not?" I have not ask it yet because I don't have MI right now. Since you have explain it so I'll discuss then.

But let me first take this to a newbie level, so what you mean is that eventhough I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings?

Let say I have a little program that will update column with CentroidX() and CentroidY(), do by default it will update the column using "English" settings?

[Zery]

After taking a second look, forget this one

"Let say I have a little program that will update column with CentroidX() and CentroidY(), do by default it will update the column using "English" settings?"

It's not what I really mean.

Regards,
Zery

-----Original Message-----
From: "Spencer Simpson" <ssim...@baltometro.org>
Sender: mapi...@googlegroups.com

Date: Mon, 8 Nov 2010 09:35:21
To: <mapi...@googlegroups.com>
Reply-To: mapi...@googlegroups.com
Subject: RE: [MI-L] Decimal separator

[Spencer Simpson]

> But let me first take this to a newbie level, so what you mean is that

> even though I set the number settings first in mapbasic window then run

> the MBX, it would not do any effect on the MBX settings?

Exactly.

But that's the way it should be. Since numeric formatting preferences
aren't specifically a MapInfo thing, they're best controlled through the OS.

BTW, the flaw is in the application. Local number formatting conventions
are for text read by humans, not software applications (i.e. whatever the
SVG file is being used for). So Uffe's suggestion of rebuilding the app to
always US number formatting has a lot of merit.

[Eric Blasenheim]

Not quite right Spencer on the issue of the number of environments!

Each MapBasic application has an environment for "global settings"
like Set Coordsys, Set Format .. as you noted.
However, there is only one other environment. What you set in a
workspace, run in the MapBasic window and/or do as a run command in a
program affects the same environment, which is the global, user level
environment and you should always be careful about changing that
environment as it affects the end user experience in dialogs and
windows. Best practice is to query the current setting, change what
you need to and then set it back.

So there is the environment for each MB app and the one global, user
environment.

On the topic of the problem with this application, I am a bit confused
as to where this problem comes from. By default in Professional, all
conversion of numbers to strings happens in a non-locale specific way.
So, when you write out a file (like SVG) and gather location
information from ObjectNodeX or Y, ObjectGeography(), etc., whether
you use implicit or explicit (Str$) conversion to strings, the result
will always have no thousands separators and will use a period
character for the decimal point. The only way that I know of for
getting localized conversions is to explicitly use the FormatNumber$()
or the Format$() functions. If the SVG creation application is doing
so, then the program should be corrected. But by default, MapBasic
output would not vary with Windows Control panel settings.

The comment about CentroidX() and CentroidY() from Zery was also
answered incorrectly. Assuming that one is updating a numeric column,
the formating is of no interest and does not affect the Update Column
command at all.
What one sees in the browser would be affected by formating settings.
But the data would still be numbers.

Eric Blasenheim
PBBI (MapInfo)

> Frank- Hide quoted text -
>
> - Show quoted text -

[Lars I. Nielsen (GisPro)]

Now you mention it Eric, I've always thought it was odd, that Format$() produced localized strings.

As I see it, Format$() ought to be a controlled version of Str$(), yielding non-localized formatted strings i.e. for SVG output, while the FormatNumber$() and DeformatNumber$() functions should the only ones to use when handling localized strings.

I've been tripped by that inconsistency in the function library several times.

Best regards / Med venlig hilsen
Lars I. Nielsen
GIS & DB Integrator
GisPro

[Eric Blasenheim]

I don't personally disagree but Format$() is a real old function and
I think was documented to support localized formatting when that was
developed in MapInfo 3.0! I believe we did not even have the word
Professional then so the full name was probably MapInfo for Windows
(Mac, Unix... )
It is hard to change those things without breaking applications. I
guess one of the benefits of Set Format Number "9,999.9" is that you
can change the behavior of Format$(). And since you control the
thousands separator use or non-use via the format string, that should
not be a problem.

I realized within minutes of posting yesterday that indeed one reason
to use Format$() is to control the number of decimal places and as
Lars said, that should really be separate from locale sensitive
formatting. It all comes down to whether you are dealing with numbers
for display purposes (should ALWAYS be locale sensitive) or text data
transfer (should always be "." and no thousands separator).

So in the end the easiest fix for this issue would be to add the Set
Format Number "9,999.9" at the beginning of the app. It would solve
this problem.
Eric Blasenheim
PBBI (MapInfo)

On Nov 9, 12:42 am, "Lars I. Nielsen (GisPro)" <L...@gispro.dk> wrote:
> Now you mention it Eric, I've always thought it was odd, that Format$() produced localized strings.
> As I see it, Format$() ought to be a controlled version of Str$(), yielding non-localized formatted strings i.e. for SVG output, while the FormatNumber$() and DeformatNumber$() functions should the only ones to use when handling localized strings.

> I've been tripped by that inconsistency in the function library several times.Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro
> Den 08-11-2010 22:15, Eric Blasenheim skrev:Not quite right Spencer on the issue of the number of environments! Each MapBasic application has an environment for "global settings" like Set Coordsys, Set Format .. as you noted. However, there is only one other environment. What you set in a workspace, run in the MapBasic window and/or do as a run command in a program affects the same environment, which is the global, user level environment and you should always be careful about changing that environment as it affects the end user experience in dialogs and windows. Best practice is to query the current setting, change what you need to and then set it back. So there is the environment for each MB app and the one global, user environment. On the topic of the problem with this application, I am a bit confused as to where this problem comes from. By default in Professional, all conversion of numbers to strings happens in a non-locale specific way. So, when you write out a file (like SVG) and gather location information from ObjectNodeX or Y, ObjectGeography(), etc., whether you use implicit or explicit (Str$) conversion to strings, the result will always have no thousands separators and will use a period character for the decimal point. The only way that I know of for getting localized conversions is to explicitly use the FormatNumber$() or the Format$() functions. If the SVG creation application is doing so, then the program should be corrected. But by default, MapBasic output would not vary with Windows Control panel settings. The comment about CentroidX() and CentroidY() from Zery was also answered incorrectly. Assuming that one is updating a numeric column, the formating is of no interest and does not affect the Update Column command at all. What one sees in the browser would be affected by formating settings. But the data would still be numbers. Eric Blasenheim PBBI (MapInfo) On Nov 8, 12:49 pm, "Spencer Simpson"<ssimp...@baltometro.org>wrote:But let me first take this to a newbie level, so what you mean is that even though I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings?Exactly.   But that's the way it should be.  Since numeric formatting preferences aren't specifically a MapInfo thing, they're best controlled through the OS. BTW, the flaw is in the application.   Local number formatting conventions are for text read by humans, not software applications (i.e. whatever the SVG file is being used for).   So Uffe's suggestion of rebuilding the app to always US number formatting has a lot of merit. ________________________________ Spencer -----Original Message----- From: Zery [mailto:zery...@gmail.com] Sent: Monday, November 08, 2010 10:08 AM To:mapi...@googlegroups.comSubject: Re: [MI-L] Decimal separator Thank you Spencer, it came across my mind before, "does the 'set' in mapbasic window will affect the entire mapinfo session or not?" I have not ask it yet because I don't have MI right now. Since you have explain it so I'll discuss then. But let me first take this to a newbie level, so what you mean is that eventhough I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings? Let say I have a little program that will update column with CentroidX() and CentroidY(), do by default it will update the column using "English" settings? Regards, Zery -----Original Message----- From: "Spencer Simpson"<ssimp...@baltometro.org>Sender:mapi...@googlegroups.comDate: Mon, 8 Nov 2010 09:35:21 To:<mapi...@googlegroups.com>Reply-To:mapi...@googlegroups.comSubject: RE: [MI-L] Decimal separator Actually, your answer is better (Although more complicated than necessary), and Uffe's answer won't actually work. Why?  Each running MapBasic application has its own collection of the values you can change in MapBasic with "set" (Actually, there are two collections each, one for the application and one for Run Command strings).  The MapBasic window has its own collection as well.  If there are three MapBasic applications running, that's seven different environments. A "Set" command in one environment won't affect the settings in another environment.   Since the original poster is running an MBX, there's no way into the MBX's environment.  He or she would have to add the "Set" comment in the source code, recompile, and run the custom MBX. However, since there's a difference on machines with different language settings, changing your Windows Regional and Language Settings should give you the results you are looking for. A slightly simpler solution is to refrain from clicking on "Customize" in Regional and Language Settings, instead selecting "English (United States)" from the dropdown next to the button. ________________________________ Spencer -----Original Message----- From: Zery [mailto:zery...@gmail.com] Sent: Monday, November 08, 2010 5:37 AM To:mapi...@googlegroups.comSubject: Re: [MI-L] Decimal separator I'm about to give you this "....in your Dutch machine, go to "Regional and Language Settings", I believe it's in Control Panel (if your using XP), there's an option there to change decimal separator from comma to point. In Regional Options tab, click Costumize, you will find the option...." Uffe's answer is better. :-) Regards, Zery -----Original Message----- From: Frank<franksa...@gmail.com>Sender:mapi...@googlegroups.comDate: Mon, 8 Nov 2010 02:24:08 To: MapInfo-L<mapi...@googlegroups.com>Reply-To:mapi...@googlegroups.comSubject: [MI-L] Decimal separator Dear all, Is there any way to configure in MapInfo the default symbol (point/ comma) used as decimal separators? I am using the MI2SVG.mbx tool (for exporting a map from MapInfo map window to a SVG file) on two machines with different MapInfo language/ region configuration (ie one is in English and one in Dutch). Exporting on the English machine doesn't show any problems, however exporting on the Dutch machine results in comma's instead of points used as decimal separator. Eg. coordinate result from English MapInfo: 213615.2,-524509.4 Coordinate result from Dutch MapInfo: 213615,2,-524509,4 To make the MI2SVG tool work on Dutch machines as well I have to somehow change the symbol used as decimal separator. Regards, Frank- Hide quoted text - - Show quoted text -

[Spencer Simpson]

> The comment about CentroidX() and CentroidY() from Zery was also
> answered incorrectly.

I didn't actually address Zery's comment on this point; he sent another
message asking to ignore that comment. That's why I quoted those three
specific lines. Your reasoning is of course correct -- you shouldn't use
text columns to store coordinates. My comments about why the flaw is in the
application echo this.

Unfortunately, when exporting to an intermediate text format, str$() doesn't
keep enough decimal places. Because of that, it is necessary to use
Format$() to convert coordinates to strings.

Lars's idea that Format$ should ignore localized settings, leaving only
FormatNumber() for this functionality, has some merit.

My experience with 9.5 is that "Set format Number" starts with "Local". The
SVG conversion app should be changed to modify this to use "9,999.9", which
is the only other allowed value.

Looking at the original post, you can see that the thousands separator isn't
appearing, so the Format$ pattern doesn't include a ",". But the decimal
point is needed, so the app uses the local setting for that.

> However, there is only one other environment.

OK, but not all Run Command settings affect the MapBasic window environment.
This inconsistency may be what made me think there were extra environments.

One of these problematical settings is the number format! To prove it to
yourself, do the following:

1. Create an MBX from the following two lines:

run command "set format number ""9,999.9"""
run command "note format$(234567.891, ""#,###.#"")"

I used MapBasic 5.0.

2. Use Regional and language settings to customize your number format into
something weird. I used ! for a decimal point and ? for a thousands
separator. Remember to change your number format back when you're done.

3. In the MapBasic window (I'm using Pro 9.5), enter

set format number "9,999.9"
note format$(123456.789, "#,###.######")
set format number "Local"
note format$(123456.789, "#,###.######")

The first note should look like "123,456.789".
The second note will be based on the weird format you set (I got
123?456!789)

4. Run the MBX. You'll get "234,567.891"

5. Finally, run just the last "note format$()" command in the MapBasic
window. I still got "123?456!789" and so should you.

What's going on here? In this case, Run Command "set format number" is
affecting the MBX environment and not the MapBasic window environment.

Change your MB code to look like this:

set format number "local"
run command "set format number ""9,999.9"""
run command "note format$(234567.891, ""#,###.#"")"
note format$(234567.891, "#,###.#")

You'll get "234,567.891" both times! The Run Command affected the MBX
environment, not Run Command. To prove this, repeat step 5 to get a
"123?456!789"

________________________________

Eric Blasenheim
PBBI (MapInfo)

--

[Eric Blasenheim]

Good catch, Spencer. I don't have time today to give one of my longer
explanations but suffice it to say that Professional will often
processs a Run Command and because there is a RUNNING mapbasic
application, still apply that setting to the MapBasic application
environment rather than the global user one. I also would not be
surprised if this behavior is not 100% consistent. However, the idea
behind it from what I remember was the fact that people requested this
in cases where the command needed to be put together from interactive
user input and therefore could not be hard coded into the MapBasic
application and executed normally. A Run Command is oftent the only
way to do this.
You might want to try another way which instead of doing literal Run
Command in the MBX you launched a workspace with the same commands
from the MBX. Unless Professional is special casing the workspace
case, you probably would get the same behavior.

Eric Blasenheim
PBBI (MapInfo)

> ...
>
> read more »- Hide quoted text -

[Lars I. Nielsen (GisPro)]

Hi Eric, all,

Ok, historic baggage. At least it's easy to control.

I just ran into a similar problem in .net. Apparently all Parse() and ToString() methods use "lazy coding", meaning that they all adhere the local settings.

I.e., if I need to handles decimal value e.g. in an XML file, which is "US formatted" by default, I need to add these small contraptions:

theDouble = Double.Parse ( theString , System.Globalization.CultureInfo.InvariantCulture )

theString = theDouble.ToString ( System.Globalization.CultureInfo.InvariantCulture )

Just wanted to give y'all a heads up in our global community :-)

Best regards / Med venlig hilsen
Lars I. Nielsen
GIS & DB Integrator
GisPro

Now you mention it Eric, I've always thought it was odd, that Format$() produced localized strings.
As I see it, Format$() ought to be a controlled version of Str$(), yielding non-localized formatted strings i.e. for SVG output, while the FormatNumber$() and DeformatNumber$() functions should the only ones to use when handling localized strings.
I've been tripped by that inconsistency in the function library several times.Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro
Den 08-11-2010 22:15, Eric Blasenheim skrev:Not quite right Spencer on the issue of the number of environments! Each MapBasic application has an environment for "global settings" like Set Coordsys, Set Format .. as you noted. However, there is only one other environment. What you set in a workspace, run in the MapBasic window and/or do as a run command in a program affects the same environment, which is the global, user level environment and you should always be careful about changing that environment as it affects the end user experience in dialogs and windows. Best practice is to query the current setting, change what you need to and then set it back. So there is the environment for each MB app and the one global, user environment. On the topic of the problem with this application, I am a bit confused as to where this problem comes from. By default in Professional, all conversion of numbers to strings happens in a non-locale specific way. So, when you write out a file (lik
e SVG) and gather location information from ObjectNodeX or Y, ObjectGeography(), etc., whether you use implicit or explicit (Str$) conversion to strings, the result will always have no thousands separators and will use a period character for the decimal point. The only way that I know of for getting localized conversions is to explicitly use the FormatNumber$() or the Format$() functions. If the SVG creation application is doing so, then the program should be corrected. But by default, MapBasic output would not vary with Windows Control panel settings. The comment about CentroidX() and CentroidY() from Zery was also answered incorrectly. Assuming that one is updating a numeric column, the formating is of no interest and does not affect the Update Column command at all. What one sees in the browser would be affected by formating settings. But the data would still be numbers. Eric Blasenheim PBBI (MapInfo) On Nov 8, 12:49 pm, "Spencer Simpson"<ssimp...@baltometro.org>wrote:But let me first take this to a newbie level, so what you mean is that even though I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings?Exactly.   But that's the way it should be.  Since numeric formatting preferences aren't specifically a MapInfo thing, they're best controlled through the OS. BTW, the flaw is in the application.   Local number formatting conventions are for text read by humans, not software applications (i.e. whatever the SVG file is being used for).   So Uffe's suggestion of rebuilding the app to always US number formatting has a lot of merit. ________________________________ Spencer -----Original Message----- From: Zery [mailto:zery...@gmail.com] Sent: Monday, November 08, 2010 10:08 AM To:mapi...@googlegroups.comSubject: Re: [MI-L] Decimal separator Thank you Spencer, it came across my mind before, "does the 'set' in mapbasic window will affect the entire mapinfo session or not?" I have not ask it yet because I don't have MI right now. Since you have explain it so I'll discuss then. But let me first take this to a newbie level, so what you mean is that eventhough I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings? Let say I have a little program that will update column with CentroidX() and CentroidY(), do by default it will update the column using "English" settings? Regards, Zery -----Original Message----- From: "Spencer Simpson"<ssimp...@baltometro.org>Sender:mapinfo-l@go
oglegroups.comDate: Mon, 8 Nov 2010 09:35:21 To:<mapi...@googlegroups.com>Reply-To:mapi...@googlegroups.comSubject: RE: [MI-L] Decimal separator Actually, your answer is better (Although more complicated than necessary), and Uffe's answer won't actually work. Why?  Each running MapBasic application has its own collection of the values you can change in MapBasic with "set" (Actually, there are two collections each, one for the application and one for Run Command strings).  The MapBasic window has its own collection as well.  If there are three MapBasic applications running, that's seven different environments. A "Set" command in one environment won't affect the settings in another environment.   Since the original poster is running an MBX, there's no way into the MBX's e
nvironment.  He or she would have to add the "Set" comment in the source code, recompile, and run the custom MBX. However, since there's a difference on machines with different language settings, changing your Windows Regional and Language Settings should give you the results you are looking for. A slightly simpler solution is to refrain from clicking on "Customize" in Regional and Language Settings, instead selecting "English (United States)" from the dropdown next to the button. ________________________________ Spencer -----Original Message----- From: Zery [mailto:zery...@gmail.com] Sent: Monday, November 08, 2010 5:37 AM To:mapi...@googlegroups.comSubject: Re: [MI-L] Decimal separator I'm about to give you this "....in your Dutch machine, go to "Regional and Language Settings", I believe it's in Control Pane
l (if your using XP), there's an option there to change decimal separator from comma to point. In Regional Options tab, click Costumize, you will find the option...." Uffe's answer is better. :-) Regards, Zery -----Original Message----- From: Frank<franksa...@gmail.com>Sender:mapi...@googlegroups.comDate: Mon, 8 Nov 2010 02:24:08 To: MapInfo-L<mapi...@googlegroups.com>Reply-To:mapi...@googlegroups.comSubject: [MI-L] Decimal separator Dear all, Is there any way to configure in MapInfo the default symbol (point/ comma) used as decimal separators? I am using the MI2SVG.mbx tool (for exporting a map from MapInfo map window to a
 SVG file) on two machines with different MapInfo language/ region configuration (ie one is in English and one in Dutch). Exporting on the English machine doesn't show any problems, however exporting on the Dutch machine results in comma's instead of points used as decimal separator. Eg. coordinate result from English MapInfo: 213615.2,-524509.4 Coordinate result from Dutch MapInfo: 213615,2,-524509,4 To make the MI2SVG tool work on Dutch machines as well I have to somehow change the symbol used as decimal separator. Regards, Frank- Hide quoted text - - Show quoted text -

[Eric Blasenheim]

Yes one must "Invariant Culture" in all the parse and related methods
for data. Once again .NET does not know whether you are doing these
operations for data purposes or end user interaction. If I had
designed it, I probably would have defaulted to invariant and made the
programmer specify the current culture when doing locale sensitive
conversions.

Eric Blasenheim
PBBI (MapInfo).

On Nov 10, 9:37 am, "Lars I. Nielsen (GisPro)" <L...@gispro.dk> wrote:
> Hi Eric, all,
> Ok, historic baggage. At least it's easy to control.
> I just ran into a similar problem in .net. Apparently all Parse() and ToString() methods use "lazy coding", meaning that they all adhere the local settings.
> I.e., if I need to handles decimal value e.g. in an XML file, which is "US formatted" by default, I need to add these small contraptions:
> theDouble = Double.Parse ( theString , System.Globalization.CultureInfo.InvariantCulture )
> theString = theDouble.ToString ( System.Globalization.CultureInfo.InvariantCulture )

> Just wanted to give y'all a heads up in our global community :-)Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro
> Den 09-11-2010 15:00, Eric Blasenheim skrev:I don't personally disagree but Format$() is a real old function and I think was documented to support localized formatting when that was developed in MapInfo 3.0! I believe we did not even have the word Professional then so the full name was probably MapInfo for Windows (Mac, Unix... ) It is hard to change those things without breaking applications. I guess one of the benefits of Set Format Number "9,999.9" is that you can change the behavior of Format$(). And since you control the thousands separator use or non-use via the format string, that should not be a problem. I realized within minutes of posting yesterday that indeed one reason to use Format$() is to control the number of decimal places and as Lars said, that should really be separate from locale sensitive formatting. It all comes down to whether you are dealing with numbers for display purposes (should ALWAYS be locale sensitive) or text data transfer (should always be "." and no thousands separator). So in the end the easiest fix for this issue would be to add the Set Format Number "9,999.9" at the beginning of the app. It would solve this problem. Eric Blasenheim PBBI (MapInfo) On Nov 9, 12:42 am, "Lars I. Nielsen (GisPro)"<L...@gispro.dk>wrote:Now you mention it Eric, I've always thought it was odd, that Format$() produced localized strings. As I see it, Format$() ought to be a controlled version of Str$(), yielding non-localized formatted strings i.e. for SVG output, while the FormatNumber$() and DeformatNumber$() functions should the only ones to use when handling localized strings. I've been tripped by that inconsistency in the function library several times.Best regards / Med venlig hilsen Lars I. Nielsen GIS & DB Integrator GisPro Den 08-11-2010 22:15, Eric Blasenheim skrev:Not quite right Spencer on the issue of the number of environments! Each MapBasic application has an environment for "global settings" like Set Coordsys, Set Format .. as you noted. However, there is only one other environment. What you set in a workspace, run in the MapBasic window and/or do as a run command in a program affects the same environment, which is the global, user level environment and you should always be careful about changing that environment as it affects the end user experience in dialogs and windows. Best practice is to query the current setting, change what you need to and then set it back. So there is the environment for each MB app and the one global, user environment. On the topic of the problem with this application, I am a bit confused as to where this problem comes from. By default in Professional, all conversion of numbers to strings happens in a non-locale specific way. So, when you write out a file (lik e SVG) and gather location information from ObjectNodeX or Y, ObjectGeography(), etc., whether you use implicit or explicit (Str$) conversion to strings, the result will always have no thousands separators and will use a period character for the decimal point. The only way that I know of for getting localized conversions is to explicitly use the FormatNumber$() or the Format$() functions. If the SVG creation application is doing so, then the program should be corrected. But by default, MapBasic output would not vary with Windows Control panel settings. The comment about CentroidX() and CentroidY() from Zery was also answered incorrectly. Assuming that one is updating a numeric column, the formating is of no interest and does not affect the Update Column command at all. What one sees in the browser would be affected by formating settings. But the data would still be numbers. Eric Blasenheim PBBI (MapInfo) On Nov 8, 12:49 pm, "Spencer Simpson"<ssimp...@baltometro.org>wrote:But let me first take this to a newbie level, so what you mean is that even though I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings?Exactly.   But that's the way it should be.  Since numeric formatting preferences aren't specifically a MapInfo thing, they're best controlled through the OS. BTW, the flaw is in the application.   Local number formatting conventions are for text read by humans, not software applications (i.e. whatever the SVG file is being used for).   So Uffe's suggestion of rebuilding the app to always US number formatting has a lot of merit. ________________________________ Spencer -----Original Message----- From: Zery [mailto:zery...@gmail.com] Sent: Monday, November 08, 2010 10:08 AMTo:mapi...@googlegroups.comSubject:Re: [MI-L] Decimal separator Thank you Spencer, it came across my mind before, "does the 'set' in mapbasic window will affect the entire mapinfo session or not?" I have not ask it yet because I don't have MI right now. Since you have explain it so I'll discuss then. But let me first take this to a newbie level, so what you mean is that eventhough I set the number settings first in mapbasic window then run the MBX, it would not do any effect on the MBX settings? Let say I have a little program that will update column with CentroidX() and CentroidY(), do by default it will update the column using "English" settings? Regards, Zery -----Original Message----- From: "Spencer Simpson"<ssimp...@baltometro.org>Sender:mapinfo-l@go oglegroups.comDate:Mon, 8 Nov 2010 09:35:21 To:<mapi...@googlegroups.com>Reply-To:mapi...@googlegroups.comSubject:RE: [MI-L] Decimal separator Actually, your answer is better (Although more complicated than necessary), and Uffe's answer won't actually work. Why?  Each running MapBasic application has its own collection of the values you can change in MapBasic with "set" (Actually, there are two collections each, one for the application and one for Run Command strings).  The MapBasic window has its own collection as well.  If there are three MapBasic applications running, that's seven different environments. A "Set" command in one environment won't affect the settings in another environment.   Since the original poster is running an MBX, there's no way into the MBX's e nvironment.  He or she would have to add the "Set" comment in the source code, recompile, and run the custom MBX. However, since there's a difference on machines with different language settings, changing your Windows Regional and Language Settings should give you the results you are looking for. A slightly simpler solution is to refrain from clicking on "Customize" in Regional and Language Settings, instead selecting "English (United States)" from the dropdown next to the button. ________________________________ Spencer -----Original Message----- From: Zery [mailto:zery...@gmail.com] Sent: Monday, November 08, 2010 5:37 AMTo:mapi...@googlegroups.comSubject:Re: [MI-L] Decimal separator I'm about to give you this "....in your Dutch machine, go to "Regional and Language Settings", I believe it's in Control Pane l (if your using XP), there's an option there to change decimal separator from comma to point. In Regional Options tab, click Costumize, you will find the option...." Uffe's answer is better. :-) Regards, Zery -----Original Message----- From: Frank<franksa...@gmail.com>Sender:mapi...@googlegroups.comDate:Mon, 8 Nov 2010 02:24:08 To: MapInfo-L<mapi...@googlegroups.com>Reply-To:mapi...@googlegroups.comSubject:[MI-L] Decimal separator Dear all, Is there any way to configure in MapInfo the default symbol (point/ comma) used as...
>
> read more »