|Sounds great in principle but I don't think it will fix the problem for Mac OS.|
For a start, I'm using old code (trying to get it working before I bring the source up to date) that looks like this:
void LocalEnvironment::GetNumberOfDecimalPlaces(UINT32* DecimalPlaces)
PORTNOTE("other","Removed GetProfileString usage")
GetProfileString("intl", "iDigits", "2", TS, sizeof(TS));
// Convert the string into a number that the string represents which we
// can then return to the caller.
*DecimalPlaces = tcstol( TS, &pszMark, 10 );
No use of localeconv, notice.
Secondly the HEAD version of localenv.cpp has conditional stuff that means that localeconv isn't being used.
(No wonder I couldn't find it when I search my xcode project! It really isn't there!)
On 26 Apr 2006, at 15:39, Alex Bligh wrote:
Phil Martin wrote:
That's exactly the question that I have been thinking about too.
I've searched the code but can't find anything directly referring to it. Not sure how to find where it's being pulled into the build.
In general: the more external libraries we pull in, the more difficult it is to build the program and in particular to build Universal Binaries on the Mac.
OK, it seems to me this is only being used by localenv.cpp. It uses
it for three things: returning the thousands separator, decimal
separator, and standard number of decimal places. The latter is
not very useful (it's only useful for currency), and indeed though
convert.cpp calls it, it discards the return value.
So I would like to propose converting this over to use
wxLocale::GetInfo(), which returns the former two OK, and
using the fixed value 2 (for the latter) on non-MSW platforms.
This should remove the libiconv dependency. Will this suit?