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


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


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.