Setting CurrentCulture Property not working

Topics: Help
Jan 13, 2012 at 12:51 PM
Edited Jan 13, 2012 at 3:44 PM

Greetings!

Does NCalc already provide Globalization support?

We're facing some issues regarding the culture where NCalc evalutor is currently applied. Even after explicity set the CurrentCulture property it did not affect the way which variables are parsed.

Is there any way to workaround? Or shall we move in order to implement Globalization and Localizing support?

Cheers!

----------------------------

Just to enlight the question:

Once we send a expression to be evaluated contening a "Double" value, but in portugues/Brazil (pt-br) where the decimal separator is a comma not a dot, it throws an exception.

Thanks!

Coordinator
Jan 13, 2012 at 4:45 PM

Actually all evaluations are supposed to be culture invariant in ncalc, so that any culture would behave the same.

What are your expectations regarding globalization ?

Jan 13, 2012 at 5:53 PM
Edited Jan 13, 2012 at 6:00 PM

Actually, we just pass an String like "2,5 + 1" to be evaluated by NCalc.

The "2,5" is double input that comes from the UI. As mentioned above the coma separator is the decimal value separator in Brazil. So, we expected the "2,5" to be interpreted as Double/Float.

After diving a bit on NCalc source, we realize that the grammar/lexer couldn't parse the value as a Float and throws the following exception:

NCalc.EvaluationException was unhandled
  Message=missing EOF at ',' at line 1:1
  Source=NCalc
  StackTrace:
       at NCalc.Expression.Evaluate() in C:\Documents and Settings\kpaixa\My Documents\experimentos\NCalc - Sources\NCalc - Sources\Evaluant.Calculator\Expression.cs:line 197
       at NCalc.Play.Program.Main(String[] args) in C:\Documents and Settings\kpaixa\My Documents\experimentos\NCalc - Sources\NCalc - Sources\Evaluant.Calculator.Play\Program.cs:line 21

In our case, we just replace the comma by a dot before evaluate the expression, but how could we parse that string and identify that numeric value?

Thanks for the attention!

Edit---

By the way, NCalc is culture invariant indeed! We sent a date value under different cultures on the string expression to be evalutare and it behaved as expected. But the comma separator is breaking it.