And down the rabbit hole I go… So the .ToString() method is in C:\MicroFramework43\Framework\Subset_of_CorLib\System\Single.cs. That calls a method in more generic class called Number.Format() (Number.cs file). Number.Format calls “FormatNative” which is in a C++ file here: C:\MicroFramework43\CLR\Libraries\CorLib\corlib_native_System_Number.cpp. I took that file and diffed it with the one from 4.2 and there were many changes in 4.3. Ah ha! I figured MS just introduced a bug, but when I put the older version in and rebuilt the firmware, it still had the same problem :(. All other files have inconsequential differences with the 4.2 firmware.
So, now I will just modify the Number.Format() method to replace spaces with Zeros. Not ideal, but oh well. That’s what you get when you venture off on your own with firmware… you’re the only tester!
So I changed a lower level method called from the Format() method. Here is what I hacked in:
private static String PostProcessFloat(String original, char format, NumberFormatInfo info)
String result = original;
if (format == 'N')
result = InsertGroupSeperators(result, info);
result = ReplaceDecimalSeperator(result, info);
result = ReplaceNegativeSign(result, info);
// *** BEGIN UGLY WORKAROUND ***
// Replace spaces with zeros. But, why would there be spaces?
// This is a workaround for a bug of unknown origin.
// Debug.Print("Bad Parsing: " + (24.0625f).ToString("F3"));
// would output "Bad Parsing: 24. 62"
var resultChars = result.ToCharArray();
for (var i = 0; i < resultChars.Length; i++)
if (resultChars[i] == ' ') resultChars[i] = '0';
return new string(resultChars);
// *** END EGLY WORKAROUND ***
That gave me this result:
Bad Parsing: 24.062500000
It’s a bit troubling that I don’t know the cause, but I’ve got bigger fish to fry!