Regional settings cause runtime crash

[Colmag]

I've written an application with vb.net 2003 (framework 1.1) which automates
a 3rd party viewing/printing application (via an activex control). I've
released several versions over the last year without problem, but since
getting a new laptop, people can't run the program since I built it with the
new machine. Even if I take the modified code and build it with my old
machine, it still crashes.

I thought maybe it was the code, but it runs fine on all of the machines I
have access to.

Then I got an email from someone in continental Europe (I live in the UK)
who said they could get it to work if they changed the decimal separator in
the regional options section in the contol panel. People from the US and New
Zealand also have problems running the program now.

The old machine has a copy of XP Home which I bought from a store and
installed myself, the new machine has XP home pre-installed. On both I have
windows set to English (UK) with the same separator etc., but I notice that
some options are different between the two machines. The new machine has
options for "Standard digits (0123456789)" and "Digit substitution (None)".
The selections on the list of Code page conversion tables are also different.

Both machines are running XP Home SP2.

The question is, can the regional settings cause runtime errors, and if so
how can I get around them? I'm not an advanced programmer, and don't know
what I'm doing that's causing the problems.

Thanks in advance.

[Marina]

If you are parsing dates or numeric values yourself, that might do it due to
differences in separator characters. You would need to get a stack trace of
where the problem happens to really pinpoint the source and then fix it.

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:65**********************************@microsof t.com...

I've written an application with vb.net 2003 (framework 1.1) which
automates
a 3rd party viewing/printing application (via an activex control). I've
released several versions over the last year without problem, but since
getting a new laptop, people can't run the program since I built it with
the
new machine. Even if I take the modified code and build it with my old
machine, it still crashes.

I thought maybe it was the code, but it runs fine on all of the machines I
have access to.

Then I got an email from someone in continental Europe (I live in the UK)
who said they could get it to work if they changed the decimal separator
in
the regional options section in the contol panel. People from the US and
New
Zealand also have problems running the program now.

The old machine has a copy of XP Home which I bought from a store and
installed myself, the new machine has XP home pre-installed. On both I
have
windows set to English (UK) with the same separator etc., but I notice
that
some options are different between the two machines. The new machine has
options for "Standard digits (0123456789)" and "Digit substitution
(None)".
The selections on the list of Code page conversion tables are also
different.

Both machines are running XP Home SP2.

The question is, can the regional settings cause runtime errors, and if so
how can I get around them? I'm not an advanced programmer, and don't know
what I'm doing that's causing the problems.

Thanks in advance.

[Colmag]

Thanks for the response.

I'm not doing anything with dates, and as far as I'm aware I'm not doing
anything out of the ordinary with numbers.

Since the problems started, I built in some logging, so I'll try and get the
stack trace you refer to. I can replicate the problem by changing my own
control panel setting, so I'll give that a go.

"Marina" wrote:

If you are parsing dates or numeric values yourself, that might do it due to
differences in separator characters. You would need to get a stack trace of
where the problem happens to really pinpoint the source and then fix it.

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:65**********************************@microsof t.com...

I've written an application with vb.net 2003 (framework 1.1) which
automates
a 3rd party viewing/printing application (via an activex control). I've
released several versions over the last year without problem, but since
getting a new laptop, people can't run the program since I built it with
the
new machine. Even if I take the modified code and build it with my old
machine, it still crashes.

I thought maybe it was the code, but it runs fine on all of the machines I
have access to.

Then I got an email from someone in continental Europe (I live in the UK)
who said they could get it to work if they changed the decimal separator
in
the regional options section in the contol panel. People from the US and
New
Zealand also have problems running the program now.

The old machine has a copy of XP Home which I bought from a store and
installed myself, the new machine has XP home pre-installed. On both I
have
windows set to English (UK) with the same separator etc., but I notice
that
some options are different between the two machines. The new machine has
options for "Standard digits (0123456789)" and "Digit substitution
(None)".
The selections on the list of Code page conversion tables are also
different.

Both machines are running XP Home SP2.

The question is, can the regional settings cause runtime errors, and if so
how can I get around them? I'm not an advanced programmer, and don't know
what I'm doing that's causing the problems.

Thanks in advance.

[Colmag]

Marina,

Thanks for the suggestion. It seems I'm doing something dodgy in converting
variable types.

Because there are so many places where people have restricted access rights,
I've avoided writing anything to the registry. To store application settings
such as window positions, I write a text file containing these settings when
the app closes, and read the config file when the app starts.

I'm declaring a variable as a string which equals a line from the text file
and then applying that to my application. e.g:

Dim MainTop As String = streamtoread.ReadLine
Me.top = MainTop

With appropriate regional settings (decimal separator = .) .net converts the
string to an integer no problem, but as soon as I change the regional setting
to something like a comma, the conversion no longer works.

Any suggestions?
"Colmag" wrote:

Thanks for the response.

I'm not doing anything with dates, and as far as I'm aware I'm not doing
anything out of the ordinary with numbers.

Since the problems started, I built in some logging, so I'll try and get the
stack trace you refer to. I can replicate the problem by changing my own
control panel setting, so I'll give that a go.

"Marina" wrote:

If you are parsing dates or numeric values yourself, that might do it due to
differences in separator characters. You would need to get a stack trace of
where the problem happens to really pinpoint the source and then fix it.

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:65**********************************@microsof t.com...

I've written an application with vb.net 2003 (framework 1.1) which
automates
a 3rd party viewing/printing application (via an activex control). I've
released several versions over the last year without problem, but since
getting a new laptop, people can't run the program since I built it with
the
new machine. Even if I take the modified code and build it with my old
machine, it still crashes.

I thought maybe it was the code, but it runs fine on all of the machines I
have access to.

Then I got an email from someone in continental Europe (I live in the UK)
who said they could get it to work if they changed the decimal separator
in
the regional options section in the contol panel. People from the US and
New
Zealand also have problems running the program now.

The old machine has a copy of XP Home which I bought from a store and
installed myself, the new machine has XP home pre-installed. On both I
have
windows set to English (UK) with the same separator etc., but I notice
that
some options are different between the two machines. The new machine has
options for "Standard digits (0123456789)" and "Digit substitution
(None)".
The selections on the list of Code page conversion tables are also
different.

Both machines are running XP Home SP2.

The question is, can the regional settings cause runtime errors, and if so
how can I get around them? I'm not an advanced programmer, and don't know
what I'm doing that's causing the problems.

Thanks in advance.

[Homer J Simpson]

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:36**********************************@microsof t.com...

With appropriate regional settings (decimal separator = .) .net converts
the
string to an integer no problem, but as soon as I change the regional
setting
to something like a comma, the conversion no longer works.

Off hand, you should store the numbers in the application in the 'normal'
form and display them to users in internationalized forms. But that's just
my opinion.

Why not use the registry? All of 'your' settings will be isolated in a
section of it.

[Cor Ligthert [MVP]]

Colmag,

Be aware that as well CSV files have as delimiter between the fields not a
comma as seperator in countries which use the comma as decimal seperator.

Just a thought,

Cor

[Colmag]

Cheesr Homer.

I'm not sure what you mean in the first paragraph, because I don't know how
to create an internationalized form. I just thought windows and .net would
handle that kind of thing for me.

In your second paragraph, do you mean that restricted users can write to
"HKEY_CURRENT_USER/Software"? If that's the case then I'd definitely go that
route and stop writing text files. I'll setup a new limited account and
change the way the app works to test it. Do you know if a "Home" limited
account is the same as a "Pro" limited account in this respect?

"Homer J Simpson" wrote:

Off hand, you should store the numbers in the application in the 'normal'
form and display them to users in internationalized forms. But that's just
my opinion.

Why not use the registry? All of 'your' settings will be isolated in a
section of it.

[Colmag]

Hi Cor,

Thanks for the info, I didn't know that.

This kind of thing must be a real headache for coders writing apps that get
widespread use, such as Excel.

"Cor Ligthert [MVP]" wrote:

Colmag,

Be aware that as well CSV files have as delimiter between the fields not a
comma as seperator in countries which use the comma as decimal seperator.

Just a thought,

Cor

[Armin Zingler]

"Colmag" <Co****@discussions.microsoft.com> schrieb

Marina,

Thanks for the suggestion. It seems I'm doing something dodgy in
converting variable types.

Because there are so many places where people have restricted access
rights, I've avoided writing anything to the registry. To store
application settings such as window positions, I write a text file
containing these settings when the app closes, and read the config
file when the app starts.

I'm declaring a variable as a string which equals a line from the
text file and then applying that to my application. e.g:

Dim MainTop As String = streamtoread.ReadLine
Me.top = MainTop
The main problem seems to be that you don't use Option Strict. If you used
it you would be aware of all conversions taking place.
With appropriate regional settings (decimal separator = .) .net
converts the string to an integer no problem, but as soon as I
change the regional setting to something like a comma, the
conversion no longer works.

Are you sure at this line? I haven't seen an integer using a decimal
separator, ever. ;-) How do you /write/ the line into the file?
Whenever you use the text representation of a value you must be aware of the
format being used. Internally, one should store all values in it's native
format, i.e. date values in DateTime variables etc. If you convert a value
from it's native format to string or vice versa, the string format must be
taken into account. To store and read application settings, you should use a
fixed format. You can use the InvariantCulture to do this. Your application
will run independent from the regional settings of the machine where it is
running on. To present data to the user, use the regional settings that are
usually used automatically used if you use ToString or Parse without
additional formatting information.


Armin

[Homer J Simpson]

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:F7**********************************@microsof t.com...

I'm not sure what you mean in the first paragraph, because I don't know
how
to create an internationalized form. I just thought windows and .net
would
handle that kind of thing for me.
I got the impression that you were coercing the numbers to some special
form, perhaps US only. If not, this is a real bug.
In your second paragraph, do you mean that restricted users can write to
"HKEY_CURRENT_USER/Software"? If that's the case then I'd definitely go
that
route and stop writing text files. I'll setup a new limited account and
change the way the app works to test it. Do you know if a "Home" limited
account is the same as a "Pro" limited account in this respect?

I haven't really concerned myself with registry access as yet, but in VB6
anything you saved was saved under a registry branch named for your
software. You COULD break out and read/write elsewhere, but it took extra
coding. I'd be surprised if that had changed much.

[Homer J Simpson]

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:40**********************************@microsof t.com...

Hi Cor,

Thanks for the info, I didn't know that.

This kind of thing must be a real headache for coders writing apps that
get
widespread use, such as Excel.

That's why they have giant throbbing brains - like Venusians <G>

[Colmag]

Thanks for the info Armin, I'm learning all the time!

The main problem seems to be that you don't use Option Strict. If you used
it you would be aware of all conversions taking place.

I just turned on Option Strict for this project and immediately had 100
build errors. I've been letting vb.net convert data between variable types
happily for over a year for this given app, and have only recently run into
problems. I'll try and eliminate these errors and see how that goes.

Are you sure at this line? I haven't seen an integer using a decimal
separator, ever. ;-) How do you /write/ the line into the file?

It's OK Armin, I don't have a decimal point in an integer! The whole
decimal separator relates purely to the settings in the control panel, under
"Regional and Language Options", and is the settings labelled "Decimal
symbol".

I write the line by first opening a file with "FileOpen(1, inipath,
OpenMode.Output)", and then use "PrintLine(1, Me.Top)".

Whenever you use the text representation of a value you must be aware of the
format being used. Internally, one should store all values in it's native
format, i.e. date values in DateTime variables etc. If you convert a value
from it's native format to string or vice versa, the string format must be
taken into account. To store and read application settings, you should use a
fixed format. You can use the InvariantCulture to do this. Your application
will run independent from the regional settings of the machine where it is
running on. To present data to the user, use the regional settings that are
usually used automatically used if you use ToString or Parse without
additional formatting information.


This sounds very useful, I'll give this a go.


Armin

[Colmag]

"Homer J Simpson" wrote:

I got the impression that you were coercing the numbers to some special
form, perhaps US only. If not, this is a real bug.

I haven't knowingly done anything like this, but that's not to say I haven't!

[Colmag]

I just felt the last bit of mine leak out, so they're in no danger from me...
;)

"Homer J Simpson" wrote:

"Colmag" <Co****@discussions.microsoft.com> wrote in message
news:40**********************************@microsof t.com...

Hi Cor,

Thanks for the info, I didn't know that.

This kind of thing must be a real headache for coders writing apps that
get
widespread use, such as Excel.

That's why they have giant throbbing brains - like Venusians <G>

[Colmag]

Armin,

I think that using your suggestion of InvariantCulture may be the answer to
the problem of the decimal separator.

Changing my original streamtoread line to the following works, regardless of
the regional setting:

Dim MainTop As Integer = Int32.Parse(streamtoread.ReadLine,
CultureInfo.InvariantCulture)

Thanks.

"Armin Zingler" wrote:

Whenever you use the text representation of a value you must be aware of the
format being used. Internally, one should store all values in it's native
format, i.e. date values in DateTime variables etc. If you convert a value
from it's native format to string or vice versa, the string format must be
taken into account. To store and read application settings, you should use a
fixed format. You can use the InvariantCulture to do this. Your application
will run independent from the regional settings of the machine where it is
running on. To present data to the user, use the regional settings that are
usually used automatically used if you use ToString or Parse without
additional formatting information.

[Uncle Leo]

On Sun, 15 Jan 2006 09:13:01 -0800, Colmag
<Co****@discussions.microsoft.com> wrote:

Thanks for the info Armin, I'm learning all the time!

The main problem seems to be that you don't use Option Strict. If you used
it you would be aware of all conversions taking place.

I just turned on Option Strict for this project and immediately had 100
build errors. I've been letting vb.net convert data between variable types
happily for over a year for this given app, and have only recently run into
problems. I'll try and eliminate these errors and see how that goes.

I got the same errors you're running into now, also because of the
decimal seperator. What I found out, with the help of people here, was
that any parsing of variables in textboxes on forms, in .ini files
etc. using CInt or CDbl would crash my app. I've solved it using
Integer.Parse, Double.Parse etc.
The IsNumeric function also was broken.
Note that converting dimmed integers to doubles using CInt didn't
crash my app.
You can read the thread here:
http://groups.google.com/group/micro...5cb39071c08336

Are you sure at this line? I haven't seen an integer using a decimal
separator, ever. ;-) How do you /write/ the line into the file?

It's OK Armin, I don't have a decimal point in an integer! The whole
decimal separator relates purely to the settings in the control panel, under
"Regional and Language Options", and is the settings labelled "Decimal
symbol".

I write the line by first opening a file with "FileOpen(1, inipath,
OpenMode.Output)", and then use "PrintLine(1, Me.Top)".

Whenever you use the text representation of a value you must be aware of the
format being used. Internally, one should store all values in it's native
format, i.e. date values in DateTime variables etc. If you convert a value
from it's native format to string or vice versa, the string format must be
taken into account. To store and read application settings, you should use a
fixed format. You can use the InvariantCulture to do this. Your application
will run independent from the regional settings of the machine where it is
running on. To present data to the user, use the regional settings that are
usually used automatically used if you use ToString or Parse without
additional formatting information.

This sounds very useful, I'll give this a go.

Armin

[Colmag]

Leo,

Thanks for the info and link, that's a very useful thread. Not wishing ill
on anyone else, but I'm glad I'm not the only one!

"Uncle Leo" wrote:

On Sun, 15 Jan 2006 09:13:01 -0800, Colmag
<Co****@discussions.microsoft.com> wrote:

Thanks for the info Armin, I'm learning all the time!

The main problem seems to be that you don't use Option Strict. If you used
it you would be aware of all conversions taking place.

I just turned on Option Strict for this project and immediately had 100
build errors. I've been letting vb.net convert data between variable types
happily for over a year for this given app, and have only recently run into
problems. I'll try and eliminate these errors and see how that goes.

I got the same errors you're running into now, also because of the
decimal seperator. What I found out, with the help of people here, was
that any parsing of variables in textboxes on forms, in .ini files
etc. using CInt or CDbl would crash my app. I've solved it using
Integer.Parse, Double.Parse etc.
The IsNumeric function also was broken.
Note that converting dimmed integers to doubles using CInt didn't
crash my app.
You can read the thread here:
http://groups.google.com/group/micro...5cb39071c08336

Are you sure at this line? I haven't seen an integer using a decimal
separator, ever. ;-) How do you /write/ the line into the file?

It's OK Armin, I don't have a decimal point in an integer! The whole
decimal separator relates purely to the settings in the control panel, under
"Regional and Language Options", and is the settings labelled "Decimal
symbol".

I write the line by first opening a file with "FileOpen(1, inipath,
OpenMode.Output)", and then use "PrintLine(1, Me.Top)".

Whenever you use the text representation of a value you must be aware of the
format being used. Internally, one should store all values in it's native
format, i.e. date values in DateTime variables etc. If you convert a value
from it's native format to string or vice versa, the string format must be
taken into account. To store and read application settings, you should use a
fixed format. You can use the InvariantCulture to do this. Your application
will run independent from the regional settings of the machine where it is
running on. To present data to the user, use the regional settings that are
usually used automatically used if you use ToString or Parse without
additional formatting information.

This sounds very useful, I'll give this a go.

Armin