hints asked for fdo#59727

[Eike Rathke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20130514/20849ca9/attachment.pgp>