Shape Provider modifies the CRT locale settings and destroys WMS Provider requests

[sgamperl]

When I use the WMS provider, the GetMap request is okay and I get a resulting image from the WMS Server. But in my test scenario i use the shape provider and the WMS provider to make a combined view of two featureclasses.

The ShapeProvider sets the locale (setlocale(LC_ALL,"")) in the ShapeCPG class. In the method SetCodePageESRIFromLocale the locale gets modified and later set back to the inital locale, if the locale wasn't "C" before. In the standard case, if no one modified the CRT locale it was "C".

After this modification the WMS provider build GetMap requests, with a decimal seperator in the BBOX key of "," instead of ".". The request produce an error, because in WMS the decimal seperator should always be "."

I access both provider through the managed API. Is there a workaround for this problem? Is it a bug or do i make a mistake in the usage of both providers?

[gregboone]

Can you share any example code on how you reproduced this issue?

[sgamperl]

This issue is a little bit tricky. For Austria we use the culture DE-AT where the decimal seperator is ','. A printf or sprintf should result in a string with ',' seperator for double values. If no one sets the current culture the "C" culture is used by the program. So the first Format() results in 120.0. This is correct because in the "C" locale the seperator is '.'. After the call to "ShapeCPG()" the locale gets modified to the machine's current culture. In my case DE-AT which means a ',' seperator.

If I then use the WMS provider I get an error because the GetMap request gets built with ',' as double seperator and that's not correct for the BBOX element of the GetMap request.

Sample:

double d = 120.0;

FdoStringP p = FdoStringP::Format(L"%lf",d);

ShapeCPG cpg = ShapeCPG();

_locale_t t = get_current_locale();

setlocale(LC_ALL,"C");

FdoStringP p2 = FdoStringP::Format(L"%lf",d);

In my opinion there are 2 problems: (1) if the shape provider modifies the locale for his work, the provider has to set it back to the initial state (2) the wms provider must use the '.' seperator in the requests. so the provider should use the "C" locale independent of the default culture on the machine.

The problem gets even trickier: When i modified the locale for the WMS provider setlocale(LC_ALL,"C") to ensure the right seperator, I didn't recognized a change in the behaviour. The problem is here, that if i mix CRT runtimes (e.g. release FDO build and debug test executable), i change only the locale for one CRT. If both are debug or release it works. The locale of the CRT is per process and per runtime (debug or release).

Hope this information can help.

[jng]

Fixed in r7017 for #881