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

[ytse]

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.