Could it be possible for the INTEGER & DECIMAL ABL functions to be improved so that they could handle E-Notation Currently I'm importing data from MS Excel where it's stores the data in an E-Notation. I'm currently having to test for the presence of a 'E' in the string and handle the calculation my self.
a = DECIMAL("123E+4") .
What am doing now:
FUNCTION E-Notation RETURNS DECIMAL ( INPUT pchStringValue AS CHARACTER ) : DEFINE VARIABLE deTempDecimalValue AS DECIMAL NO-UNDO. DEFINE VARIABLE deTempIntegerValue AS INTEGER NO-UNDO. pchStringValue = TRIM(pchStringValue) IF NUM-ENTRIES(TRIM(ImportWorkSheetData.cellValue),'E') EQ 2 THEN ASSIGN deTempDecimalValue = DECIMAL( ENTRY(1,pchStringValue,'E':U) ) deTempIntegerValue = INTEGER( ENTRY(2,pchStringValue,'E':U) ) deTempDecimalValue = deTempDecimalValue * EXP( 10, deTempIntegerValue). ELSE deTempDecimalValue = DECIMAL( pchStringValue). RETURN deTempDecimalValue. /* Function return value. */ END FUNCTION.
Assuming a reasonably recent version of Progress and Windows, Try something like this.
def var c as char.
def var d as dec.
c = "123E+4".
d = System.Double:Parse(c).
I should of mentions that I am running OE WebSpeed 11.3 on Linux CentOS. Can't do that fancy .NET stuff.
e notation requires floating point arithmetic which allows for representing very large or very small numbers. OpenEdge uses fixed point decimal. The language doesn't support floats (or doubles). So you're stuck parsing it as you have done, or using .NET to parse it for you. As long as the number isn't too big, you can stuff it into a decimal after parsing it. Watch out for the number of decimal places when dealing with really small numbers.