"Colmag" <Col***@discussions.microsoft.com> wrote in message
news:65BCF442-FC9F-4BCB-A966-399B848621B0@microsoft.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.

"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" <Col***@discussions.microsoft.com> wrote in message
> news:65BCF442-FC9F-4BCB-A966-399B848621B0@microsoft.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" 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" <Col***@discussions.microsoft.com> wrote in message
> > news:65BCF442-FC9F-4BCB-A966-399B848621B0@microsoft.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" 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" <Col***@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

>
>
> Armin
>
>

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

"Uncle Leo" wrote:

> On Sun, 15 Jan 2006 09:13:01 -0800, Colmag
> <Col***@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/microsoft.public.dotnet.languages.vb/browse_thread/thread/7636bd2b9728bde/355cb39071c08336?lnk=st&q=decimal+seperator+group%3A*.dotnet.*&rnum=26&hl=en#355cb39071c08336
>
> >>
> >> 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
> >>
> >>
>

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

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

"Homer J Simpson" wrote:

>
> "Colmag" <Col***@discussions.microsoft.com> wrote in message
> news:409C01A7-8C81-4A59-9B50-696FC6459A73@microsoft.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>
>
>
>
>