Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,128 | Comments: 45,551

filter by tags archive

WPF tripwires, beware of uncommon culture infos

time to read 1 min | 183 words

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 == ",") 
	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…


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!


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


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


-Blake Niemyjski

Rik Hemsley

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

Perhaps this is the case with XAML too?


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

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

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")


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.


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

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


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


Thank you, I added the same condition

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

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

Ayende Rahien


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

Bertrand Le Roy

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

Rob Relyea


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

Comment preview

Comments have been closed on this topic.


  1. The worker pattern - 6 hours from now

There are posts all the way to May 30, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats