http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Ayende- 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 http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment18http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment18Mon, 14 Sep 2009 23:09:36 GMTthanks http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment17http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment17Tue, 01 Sep 2009 18:43:34 GMTI've asked. I'll report here when I hear back from them. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment16http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment16Tue, 01 Sep 2009 18:40:06 GMTBertrand I would like to know if this really does affect only en-US, so yes, thank you http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment15http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment15Sun, 30 Aug 2009 07:02:40 GMTI wonder why Xaml parser is not using InvariantCulture for things that aren't supposed to be localized. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment14http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment14Fri, 28 Aug 2009 21:21:28 GMT@ Rik Hemsley Yeah, you're right, W3C requires period to be decimal indicator, see [http://www.w3.org/TR/xmlschema-2/#decimal](http://www.w3.org/TR/xmlschema-2/#decimal)http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment13http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment13Fri, 28 Aug 2009 08:24:23 GMTAh, 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. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment12http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment12Fri, 28 Aug 2009 05:02:08 GMTJohn, Thank you, I added the same condition http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment11http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment11Fri, 28 Aug 2009 04:56:37 GMTBertrand, 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. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment10http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment10Fri, 28 Aug 2009 04:55:50 GMTAs 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. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment9http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment9Thu, 27 Aug 2009 23:28:42 GMTSo, WPF does seem to have a bug in its internals where it doesn't use the invariant culture to parse XAML? Ouch. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment8http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment8Thu, 27 Aug 2009 18:45:15 GMTSince 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. http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment7http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment7Thu, 27 Aug 2009 18:30:55 GMTmmh. 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). http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment6http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment6Thu, 27 Aug 2009 17:52:37 GMTDoes 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... http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment5http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment5Thu, 27 Aug 2009 15:22:40 GMTIvan, isn't that because XML Schema requires dot to be decimal separator? Perhaps this is the case with XAML too? http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment4http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment4Thu, 27 Aug 2009 14:17:12 GMTHello, There might be a CultureInfo override where you can pass in CultureInfo.InvariantCulture, which is much cleaner. Thanks -Blake Niemyjski http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment3http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment3Thu, 27 Aug 2009 12:49:36 GMTSo 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 :\ http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment2http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment2Thu, 27 Aug 2009 12:39:38 GMTSo 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! http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment1http://ayende.com/4150/wpf-tripwires-beware-of-uncommon-culture-infos#comment1Thu, 27 Aug 2009 12:06:44 GMT