[Mono-dev] [PATCH] ASP.NET - make FontUnit NOT use locale-dependent decimal separator
Gert Driesen
gert.driesen at telenet.be
Mon Feb 12 16:02:28 EST 2007
> -----Original Message-----
> From: Marek Habersack [mailto:grendello at gmail.com]
> Sent: maandag 12 februari 2007 14:32
> To: Gert Driesen
> Cc: 'Mono Development List'
> Subject: Re: [Mono-dev] [PATCH] ASP.NET - make FontUnit NOT use locale-
> dependent decimal separator
>
> On Sat, 10 Feb 2007 14:28:54 +0100, "Gert Driesen"
> <gert.driesen at telenet.be>
> scribbled:
>
> > > -----Original Message-----
> > > From: mono-devel-list-bounces at lists.ximian.com
> > > [mailto:mono-devel-list- bounces at lists.ximian.com] On Behalf Of
> > > Marek Habersack
> > > Sent: zaterdag 10 februari 2007 6:20
> > > To: Mono Development List
> > > Subject: [Mono-dev] [PATCH] ASP.NET - make FontUnit NOT use locale-
> > > dependent decimal separator
> > >
> > > Hello,
> > >
> > > The attached diff fixes the issue mentioned in the subject.
> > > Currently mono will fail to parse font-size=0.Xem (etc) correctly
> if
> > > the current thread culture is set to a locale that uses , as the
> > > decimal point separator (e.g. de, pl). Please review, thanks
> >
> > This does not match the MS behavior. I've added a unit test to
> > FontUnitTest.cs to verify this, and fixed FontUnit.ToString() to use
> > the current locale.
> Alas, this doesn't fix the problem. Please run xsp2 with the attached
> test file
> - you will get an exception thrown, because the Unit constructor cannot
> parse the passed 0.9em value with cultures which have a decimal
> separator different to a dot. In other words, Unit (and FontUnit) in
> mono right now expect culture-dependent input while it gets the CSS
> decimal font size, which will always use the dot as a separator.
> ASP.NET parser uses the FontUnit(string) constructor - and that one, in
> turn, invokes the FontUnit(string, CultureInfo) one. By saying that the
> behavior is not MS-compatible, are you claiming that Microsoft parse
> the 0.9em value and turn it into locale-specific form (e.g.
> 0,9em) before passing it to the first FontUnit constructor above?
Apparently, MS uses FontUnitConverter.ConvertFromInvariantString to parse
the value:
[FormatException]: The numeric part ('3,5') of '3,5em' cannot be parsed as a
numeric part of a Em unit.
at System.Web.UI.WebControls.Unit..ctor(String value, CultureInfo
culture, UnitType defaultType)
at System.Web.UI.WebControls.FontUnit..ctor(String value, CultureInfo
culture)
at System.Web.UI.WebControls.FontUnit.Parse(String s, CultureInfo
culture)
at
System.Web.UI.WebControls.FontUnitConverter.ConvertFrom(ITypeDescriptorConte
xt context, CultureInfo culture, Object value)
at System.ComponentModel.TypeConverter.ConvertFromInvariantString(String
text)
at System.Web.UI.PropertyConverter.ObjectFromString(Type objType,
MemberInfo propertyInfo, String value)
at System.Web.UI.PropertySetter.AddPropertyInternal(String name, String
value, ControlBuilder builder, Boolean fItemProp)
at System.Web.UI.ControlBuilder.PreprocessAttribute(String attribname,
String attribvalue)
at System.Web.UI.ControlBuilder.PreprocessAttributes(IDictionary attribs)
at System.Web.UI.ControlBuilder.Init(TemplateParser parser,
ControlBuilder parentBuilder, Type type, String tagName, String id,
IDictionary attribs)
at System.Web.UI.ControlBuilder.CreateBuilderFromType(TemplateParser
parser, ControlBuilder parentBuilder, Type type, String tagName, String id,
IDictionary attribs, Int32 line, String sourceFileName)
at System.Web.UI.ControlBuilder.CreateChildBuilder(String tagName,
IDictionary attribs, TemplateParser parser, ControlBuilder parentBuilder,
String id, Int32 line, String sourceFileName, Type& childType)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean&
completedSynchronously)
at System.Web.UI.TemplateParser.ProcessBeginTag(Match match, String
inputText)
at System.Web.UI.TemplateParser.ParseStringInternal(String text)
at System.Web.UI.TemplateParser.ParseString(String text, String
virtualPath, String basePhysicalDir)
Gert
More information about the Mono-devel-list
mailing list