RE: hints asked for fdo#59727

Hi Eike,

> They are implemented in scaddins/source/datefunc/

I wouldn't have looked for ROT13 there... Is that a location to be maintained or should it be moved 
to scaddins/source/analysis?

> 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

As far as I can find out, the problem functions (WEEKS, MONTHS, YEARS, ISLEAPYEAR, DAYSINMONTH, 
DAYSINYEAR, WEEKSINYEAR, ROT13) do not exist in Excel. 
I don't have Excel, so I can't be certain.

In sc/source/filter/oox/formulabase.cxx I want to add these functions, but I have some questions 
about the members of struct FunctionData.
 Take e.g. WEEKS:
    { "WEEKS",                  "ORG.OPENOFFICE.WEEKS", NOID,   NOID,   3,  3,  V, { VR, VR, VR     
 }, FUNCFLAG_EXPORTONLY }
Should mpcOdfFuncName also include ORG.OPENOFFICE.?
Should I use IDs (there not in any BIFF, so I set both to NOID)?
Which flag should I use (i.e. does filter mean: leave out, or does it mean: process)?
I have not yet given serious attention to the FunctionParamInfo.

If I understand you correctly, WEEKS in an ods should translate to 'org.openoffice.weeks' when 
saving tp xlsx, which should be translated to WEEKS when saving to ods. Am I correct?

I intend to fix the xlsx-bug first and then to look at the inconsequent error messages when no 
parameters are entered and posisbly to see if I can get the locale presentation right (i.e. present 
English function names when set so in options). And of course do some clean-up if I can.

Winfried