[fdo-users] FDO SHP + dotNet help : managing the decimal separator

[Dan Stoica]

Hmm, managed code calling unmanaged code... it might explain.

In any case, here is what I suggest to do instead of setting the locale on the connection.

In idea is that the provider should be able to figure out the correct/consistent string format for decimals. That is, given the LDID (see EsriCodePageMapper[] in ShapeDBF.h) you  can tell if the '.' or ',' should be used. This would make the provider locale independent.

Therefore:
- on insert/update:  check the sprintf() return value. In case the delimiter is different from the correct one, do a substitution before writing to file.
- on select: check atof() output. In case it's 0.0 and the input is not "0..." then we know we have a locale mismatch and perform a substitution '.' <-> ',' before trying atof() again.

I believe this would work with no side effects.

What do you think?

Dan.



-----Original Message-----
From: fdo-users-bounces at lists.osgeo.org [mailto:fdo-users-bounces at lists.osgeo.org] On Behalf Of ytse
Sent: Tuesday, November 13, 2007 3:16 AM
To: fdo-users at lists.osgeo.org
Subject: RE: [fdo-users] FDO SHP + dotNet help : managing the decimal separator




Dan Stoica wrote:
>
> The LDID indicates ANSI. This is good...
>
> I remember some discussions around decimals and I think it has been
> decided that setting the locale in the provider is not the way to go. The
> thing is SHP is self-contained when comes to localization (through LDID
> and CPG mechanishms). That is, it should be immune to any setlocale().
>
> Unfortunately, you are right, this doesn't apply to decimals since atof()
> and sprintf() are used. I'll file a ticket in this regard to be fixed in
> 3.3.
>
> I have an idea how to fix it without setting the locale in provider, but
> first I would like to know why it doesn't work when your application is
> setting the LC_NUMERIC to English... Because this would fix your
> particular problem in short term.
>
> Dan.
>

Well, last time I encountered this issue (earlier this year or late 2006,
can't remember exactly, there's already a topic of mine on the fdo board) I
decided to alter the sources because noone were able to give me any
indications. Your answer is this time of much greater help :)
I'm using FDO within a C# ASP.NET application, which refers the managed
OSGeo DLLs.
I know how to set the current thread's culture in C# (using System.Threading
and CultureInfo) but it looks like it is not "transfered" to the unmanaged
C++ FDO dlls. I don't know more about Windows threading technology, so I
don't know exactly what happens and how to deal with it.
It looks like the unmanaged dlls runs it its own thread (or at least
context) and therefore uses the server's regional settings when you use
atof/sprintf and other locale related functions.

I can try to create a small code sample if you want


--
View this message in context: http://www.nabble.com/FDO-SHP-%2B-dotNet-help-%3A-managing-the-decimal-separator-tf4766129s18162.html#a13721501
Sent from the fdo-users mailing list archive at Nabble.com.

_______________________________________________
fdo-users mailing list
fdo-users at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-users