Unfortunately, the EXCEL data storage within xml-files is very complex, and as noted by others, it is virtually impossible to handle complex (and even very simple) data without the program EXCEL itself. I just discovered a new CAVEAT relating to the scribe plugin. Reading an EXCEL document with ScribeDocReadValue(), real numbers are always returned as 'integer string' without comma, and it seems impossible to get a meaningful value out of this. '29.84' -> 2984, '2984' -> 2984 (nothing to say about '2.3' -> 22999999999999998, etc.).
Although not documented, I tryed to address the field with a name ('Bill') instead of a cellcode 'C14'. Interestingly, this returned no error, if the name was defined in EXCEL, but a null (empty) value! Next try. The Excel calculation =TEXT(C14,"standard") returns the real number in a beautiful text format. However, scribe returns ERROR: Scribe returns ERROR for a any Text calculations, e.g. for 'C15' = 'Jane'; 'C16'= '=C15', ScribeDocReadValue ('C16') = ERROR. Probably scribe just can NOT access the 'SharedStringTable', nor any other secondary source tables (– this has other bad effects. If you write any values to an Excel 'fill down' range with Scribe (that is, through the backdoor), Excel will never recognize and evaluate these values correctly, etc. etc.)
What about the real numbers, then? I only found one solution: Defining an additional cell with a calculation like 'C16'= ROUND(('C14'+1000)*10000000000000,0), or (more generic) defining TWO additional fields calculating the INT and MOD part of the number.
What an abonimably atrocious workaround!
However, I really wonder WHERE the 'comma' position is stored in xlm-EXCEL, and, eventually, if you guys at 360works may plan to retrieve this information in a next version. That would be great!
@Excel for Mac 2011, v14.3.6, OS X 10.8.4, Java 7 25 (Build 1.7.0_25-b15), FM 12.0v4 Adv, 360Works Scribe v1.262