Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


Hi Eike,

I'm working on tdf64132, which is about SUM and text values that are not converted to numbers.

SUM uses ScInterpreter::IterateParameters(), which is used by various other Calc functions as well.

ScInterpreter::IterateParameters() does not handle the configuration settings for converting text to numbers properly.

For stack type svString I have a patch ready (gerrit #57346). The unit test is a problem for me, as the 'convert text to numbers' configuration is not in the test document and therefore unknown. This is illustrated by a test passing on my computer and failing for Jenkins.

But the larger challenge lies with stack type svDoubleRef (probably the most used one). Here a sc::ColumnSpanSet is used with sc::ColumnSpanSet::ColumnAction (a.o. FuncSum), which in turn uses NumericCellAccumulator. And that class handles only sc::element_type_numeric and sc::element_type_formula, so text is discarded. I could add sc::element_type_string and the conversion to numbers depending on the configuration settings.

As that will have consequences beyond the Calc functions SUM and the like, I would like you opinion on this before I start implementing.

And all this leads to the question if all Calc functions expecting numeric arguments handle the 'convert text to numbers' configuration as advertised. It looks like I can keep myself occupied for quite some time with this ;-)

Winfried


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.