Well, "$10" or "10 USD" should clearly be invalid strings for an euro locale. I wouldn't mind "10 EUR" being invalid for the default format too since using currency codes is quite specific. Actually, all these could be configurable parameters (requiring, ignoring or refusing currency symbols and/or currency codes). What I don't find correct is to always require a " €".. the user can't even type a ...
Not being able to use NumberFormat to parse currency values would be a pity. I would expect to be able to use the same format both ways (formatting and parsing). And well, if this choice is made "by design", shouldn't it be documented? The exception "X does not have either positive or negative affixes" doesn't have anything to do with the actual issue. " €" is not a "positiveSuffix". Thanks On Dec 16, 9:41 am, Thomas Broyer <[email protected]> wrote: > Not sure this is a bug, maybe by-design (i.e. don't use the currency format > for parsing). > If you want to parse a number, don't use a currency format. > If you expect the user to (optionally) type in the currency symbol, you'd > better pre-process the value (what if the user types "$10" in a € locale? > how about "10 USD" or "10 EUR"? -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
