Hi Winfried, On Tuesday, 2013-05-14 13:02:04 +0200, Winfried Donkers wrote:
There are more problems with the add-in functions, see attachments with bug 59727.I'd start by setting a breakpoint in formula/source/core/api/FormulaCompiler.cxx FormulaCompiler::CreateStringFromToken() for case svExternal and step through to see what is actually executed and which map is used and where/how it was initialized.The string read from the xlsx file is com.sun.star.sheet.addin.datefunctions.getdiffweeks(...) right from the start (for WEEKS).
Yes, the function names are already stored like that. We may have to introduce some special mappings to read these names correctly, unless we continue to store them like this, see below.
In the mean time I have come across some differences between add-in functions that I can't explain: -there are 8 add-in functies that show the problem as described in bug fdo59727: WEEKS, MONTHS, YEARS, ISLEAPYEAR, DAYSINMONTH, DAYSINYEAR, WEEKSINYEAR, ROT13. I will call them problem functions.
Ah, that's a good hint ...
-the problem functions are not present anywhere in the following files, whereas the other add-in functions are: sc/source/filter/oox/formulabase.cxx scaddins/source/analysis/analysis_deffuncnames.src scaddins/source/analysis/analysis_funcnames.src scaddins/source/analysis/analysis.src scaddins/source/analysis/analysishelper.cxx
They are implemented in scaddins/source/datefunc/ It seems they are missing from sc/source/filter/oox/formulabase.cxx so adding them there should solve the store case, and if they are stored correctly they should also be read correctly. (assuming, I didn't try or investigate deeper) The problem probably is that these funcions are not known by Excel, which is to be verified. If they aren't, then we can (or need to?) store them as the programmatic name, e.g. com.sun.star.sheet.addin.datefunctions.getdiffweeks, but need the mapping to ODFF ORG.OPENOFFICE.WEEKS in sc/source/filter/oox/formulabase.cxx
-in sc/source/core/tool/odffmap.cxx the problem functions have a different notation (first column of maAddInMap) than the other add-in functions.
Yes, they are additions that are not defined in ODFF so are stored as ORG.OPENOFFICE.* for ODF.
Am I missing a vital part of the add-in function principle?
I don't think so, just get acquainted with the mappings in sc/source/filter/oox/formulabase.cxx Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key ID: 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A For key transition see http://erack.de/key-transition-2013-01-10.txt.asc Support the FSFE, care about Free Software! https://fsfe.org/support/?erack
Attachment:
pgpHQvj37Gnj8.pgp
Description: PGP signature