Ayende @ Rahien

It's a girl

WPF tripwires, beware of uncommon culture infos

I got a few bug reports about NH Prof giving an error that looks somewhat like this one:

System.Windows.Markup.XamlParseException: Cannot convert string '0.5,1' in attribute 'EndPoint' to object of type 'System.Windows.Point'. Input string was not in a correct format. 

It took a while to figure out exactly what is going on, but I finally was able to track it down to this hotfix (note that this hotfix only take cares of list separator, while the problem exists for the decimal separator as well. Since I can’t really install the hotfix for all the users of NH Prof, I was left with having to work around that.

I whimpered a bit when I wrote this, but it works:

private static void EnsureThatTheCultureInfoIsValidForXamlParsing()
{
	var numberFormat = CultureInfo.CurrentCulture.NumberFormat;
	if (numberFormat.NumberDecimalSeparator == "." && 
		numberFormat.NumberGroupSeparator == ",") 
		return;
	Thread.CurrentThread.CurrentCulture = CultureInfo.GetCultureInfo("en-US");
	Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo("en-US");
}

I wonder when I’ll get the bug report about NH Prof not respecting the user’s UI culture…

Comments

Krzysztof Kozmic
08/27/2009 12:06 PM by
Krzysztof Kozmic

So what you're telling me is that WPF can't parse floating point numbers if decimal separator is something else than a dot? You can't be serious!

Ivan
08/27/2009 12:39 PM by
Ivan

So funny, just yesterday I've found that XML Schema Validator in .NET uses hard-coded InvariantCulture number format which means it requires dot to be decimal separator when validating values of double type :\

Blake Niemyjski
08/27/2009 12:49 PM by
Blake Niemyjski

Hello,

There might be a CultureInfo override where you can pass in CultureInfo.InvariantCulture, which is much cleaner.

Thanks

-Blake Niemyjski

Rik Hemsley
08/27/2009 02:17 PM by
Rik Hemsley

Ivan, isn't that because XML Schema requires dot to be decimal separator?

Perhaps this is the case with XAML too?

Daniel
08/27/2009 03:22 PM by
Daniel

Does it work just to set CurrentCulture? It's been a while since I had to know the difference, but it seems like the parser would just use one or the other, and it would make sense if it used CurrentCulture and let your app use CurrentUICulture...

InvariantCulture would probably be better, and is really what the parser should be using, I would think...

Bertrand Le Roy
08/27/2009 05:52 PM by
Bertrand Le Roy

mmh. French is certainly less common than en-us but calling it uncommon seems like a stretch. It would be interesting to have more context around that as the sledgehammer solution of reverting to en-us seems a little heavy handed without it. It would also help understanding if that's a bug in framework code or in NH Prof... Or at all (the document may be plain invalid).

John Meyer
08/27/2009 06:30 PM by
John Meyer

Since the hotfix specifically states that it only applies to US English installations of Windows, shouldn't your function start with:

if (CultureInfo.CurrentCulture.Name != "en-US")

return;

as the idea isn't to change the culture, but only to get rid of any customizations the user might have done in their control panel settings. I've had to add those 2 culture lines to unit test setup methods as time strings have failed to match because I have my system set to display in 24 hour time instead of 12. This situation looks very similar.

Frank
08/27/2009 06:45 PM by
Frank

So, WPF does seem to have a bug in its internals where it doesn't use the invariant culture to parse XAML? Ouch.

Gerke Geurts
08/27/2009 11:28 PM by
Gerke Geurts

As far as I am aware WPF parses floating point values using invariant culture. Otherwise the use of a custom converter class would be a pretty clean option to perform conversion.

Ayende Rahien
08/28/2009 04:55 AM by
Ayende Rahien

Bertrand,

You are absolutely correct that this isn't an ideal solution, not by a long shot.

The bug seems to be in the framework, as specified in the hotfix.

I changed the code so it would only revert the culture when the root culture in en-US.

Ayende Rahien
08/28/2009 04:56 AM by
Ayende Rahien

John,

Thank you, I added the same condition

Bertrand Le Roy
08/28/2009 05:02 AM by
Bertrand Le Roy

Ah, so there is a hotfix then. That is encouraging as it means it will probably be fixed for good in 4.0. Does it make sense for me to follow-up on the part of the problem that is not addressed by the hotfix? We can follow-up offline if you want.

Sergey Shishkin
08/28/2009 09:21 PM by
Sergey Shishkin

I wonder why Xaml parser is not using InvariantCulture for things that aren't supposed to be localized.

Ayende Rahien
08/30/2009 07:02 AM by
Ayende Rahien

Bertrand

I would like to know if this really does affect only en-US, so yes, thank you

Bertrand Le Roy
09/01/2009 06:40 PM by
Bertrand Le Roy

I've asked. I'll report here when I hear back from them.

Rob Relyea
09/14/2009 11:09 PM by
Rob Relyea

Ayende-

Bertrand let us know about this issue you have found. Thanks Bertrand.

We did this QFE this year, and we intended to fix the entire issue...but we'll dig into your example, and go see what we find.

.NET 4 Beta2 will contain our .NET 4 version of this QFE.

Sounds, from your error string, that it is complaining about a LinearGradientBrush.EndPoint...which is of type Point, which means PointConverter is the one not working well.

We'll get back to you soon on that.

XAML parsing, since v3 uses en-us, and not invariant. Unfortunately, en-us can be customized by a user who changes settings in the control panel. Our QFE is to continue to use en-us (for best compat), but to make it so that user overrides will no longer apply.

It is possible that one of our type converters is still using the normal en-us, in which this problem would still show up.

Thanks for raising this issue...we realize it is a critical issue, which is why we worked on the earlier fix.

Thanks, Rob

Rob Relyea | WPF & Xaml Language Team

robrelyea.com | /blog | /wpf | /xaml

Comments have been closed on this topic.