RE: hints asked for fdo#59727
Hi Eike, The correct place would be a duplicate of saFuncTableOdf[], say saFuncTableOOoLO[], just to keep things cleanly separated because the functions are only known to LO and not defined in OpenFormula. The saFuncTableOOoLO also needs to be added to FunctionProviderImpl::FunctionProviderImpl() after the init of saFuncTableOdf. ... 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? Yes. Respectively use uppercase ORG.OPENOFFICE.WEEKS for .xlsx; setting the table up like described should solve things. I don't seem to get anywhere for some reason. The behaviour as described in the february-comments in bug 59727 could be reproduced with version 4.0.0, but can't be reproduced with version 4.0.3 or master. It can be reproduced with version 3.6 (openSUSE). On master the behaviour with or without patched code (saFuncTableOOoLO added including addition to FunctionProviderImpl::FunctionProviderImpl()) is the same: in a reopened xlsx file the add-in function is shown as com.sum.star.sheet.addin.datefunctions.getdiffweeks(...). Not having Excel (don't want to) nor having experience with building other versions than master, I don't know how to proceed. I can send the diff to gerrit marked as WIP, but the code is straightforward, I've only added WEEKS, MONTHS YEARS to test with. Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: hints asked for fdo#59727
Hi Winfried, On Friday, 2013-05-17 16:27:31 +0200, Winfried Donkers wrote: 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? Yes. Respectively use uppercase ORG.OPENOFFICE.WEEKS for .xlsx; setting the table up like described should solve things. I don't seem to get anywhere for some reason. The behaviour as described in the february-comments in bug 59727 could be reproduced with version 4.0.0, but can't be reproduced with version 4.0.3 or master. It can be reproduced with version 3.6 (openSUSE). Which behavior? Note that this needs a matrix of versions saved with and versions loaded with. There is no the behavior valid for all versions. I assume you referred https://bugs.freedesktop.org/show_bug.cgi?id=59727#c1 ? So loading the bugdoc (that was produced with 4.0.0.3?) with those versions? On master the behaviour with or without patched code (saFuncTableOOoLO added including addition to FunctionProviderImpl::FunctionProviderImpl()) is the same: in a reopened xlsx file the add-in function is shown as com.sum.star.sheet.addin.datefunctions.getdiffweeks(...). That's odd.. Not having Excel (don't want to) nor having experience with building other versions than master, I don't know how to proceed. Let's postpone this. I'll be on vacation now anyway and couldn't investigate or help. I may have to take over when I return. 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 pgphXTImummX7.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
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
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: hints asked for fdo#59727
Hi Eike, 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). I am not a great start with gdb, so stepping and finding out more will take some time. 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. -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 -in sc/source/core/tool/odffmap.cxx the problem functions have a different notation (first column of maAddInMap) than the other add-in functions. Am I missing a vital part of the add-in function principle? Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: hints asked for fdo#59727
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 pgpCjkj9OcPQV.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: hints asked for fdo#59727
Hi Winfried, On Thursday, 2013-05-02 12:24:42 +0200, Winfried Donkers wrote: Only if the .xlsx was saved with Calc 4.0, then the file contains com.sun.star.sheet.addin.DateFunctions.getDiffMonths, an original file containing MONTHS() also does not work though, the MONTHS is not recognized hence displayed as lowercase months. Seems to be a specific problem with Add-In functions. There are more problems with the add-in functions, see attachments with bug 59727. I assumed so.. But, since this does not seem to happen for all Add-In functions I suspect something else to be the culprit, maybe in the mappings/flags of the Excel import/export function name maps. Given the large number of misbehaviour with add-in functions, I seek some more advice before I start digging in the code. I have summarised the misbehaviours I noticed in comment 8 of the bug If you get stuck with it I'd take over. I'm not stuck (yet), but don't know where to begin... There are several places where things could go wrong.. * sc/source/core/tool/odffmap.cxx the entries should be correct, but the content is used in ScCompiler to populate the OpCodeMap lists in sc/source/core/tool/compiler.cxx ScCompiler::fillFromAddInCollection...() * the FormulaGrammar::Grammar set at ScCompiler might be wrong, which is used to determine the map to be used * a mapping in sc/source/filter/oox/formulabase.cxx might be wrong * the corresponding name is not found in the AddInCollection (unlikely) 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. 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 pgprJBKIB2prR.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: hints asked for fdo#59727
Hi Eike, There are more problems with the add-in functions, see attachments with bug 59727. I assumed so.. There are several places where things could go wrong.. [...] 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. Thank you for your suggestions. I'll start working based on your suggestions. I will take my time though. Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: hints asked for fdo#59727
Hi Eike, Only if the .xlsx was saved with Calc 4.0, then the file contains com.sun.star.sheet.addin.DateFunctions.getDiffMonths, an original file containing MONTHS() also does not work though, the MONTHS is not recognized hence displayed as lowercase months. Seems to be a specific problem with Add-In functions. There are more problems with the add-in functions, see attachments with bug 59727. But, since this does not seem to happen for all Add-In functions I suspect something else to be the culprit, maybe in the mappings/flags of the Excel import/export function name maps. Given the large number of misbehaviour with add-in functions, I seek some more advice before I start digging in the code. I have summarised the misbehaviours I noticed in comment 8 of the bug If you get stuck with it I'd take over. I'm not stuck (yet), but don't know where to begin... Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: hints asked for fdo#59727
Hi Winfried, On Thursday, 2013-04-25 08:31:39 +0200, Winfried Donkers wrote: Bug fdo59727 is about addin function MONTHS() that is not interpreted correctly when read from an xlsx file. That is, an xlsx file with the function MONTHS(...) opened with calc shows com.sun.star.sheet.addin.datefunctions.getdiffmonths(...) and understandably results to #NAME? . Only if the .xlsx was saved with Calc 4.0, then the file contains com.sun.star.sheet.addin.DateFunctions.getDiffMonths, an original file containing MONTHS() also does not work though, the MONTHS is not recognized hence displayed as lowercase months. Seems to be a specific problem with Add-In functions. .xlsx import implementation is in sc/source/filter/oox/* the export is in the sc/source/filter/excel/* objects saving with *.SaveXml() methods and the like. Hints where to look for the cause are welcome. I found maAddInMap in /core/sc/source/core/tool/odffmap.cxx, but don't know where and how this map is used to convert to and from xlsx. Indirectly. The compiler uses it to initialize the opcode maps from which export obtains the names again. See ScCompiler::fillFromAddIn*() functions. But, since this does not seem to happen for all Add-In functions I suspect something else to be the culprit, maybe in the mappings/flags of the Excel import/export function name maps. This area may be way out my comfort zone, so I'm not sure at all yet whether I want to be the assignee for this bug :-) If you get stuck with it I'd take over. 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 pgpQIAf837nMr.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
hints asked for fdo#59727
Hi, Bug fdo59727 is about addin function MONTHS() that is not interpreted correctly when read from an xlsx file. That is, an xlsx file with the function MONTHS(...) opened with calc shows com.sun.star.sheet.addin.datefunctions.getdiffmonths(...) and understandably results to #NAME? . The problem also occurs with function WEEKS, but not with OCT2HEX, so not with all addin functions. I have not tested with other addin functions. Hints where to look for the cause are welcome. I found maAddInMap in /core/sc/source/core/tool/odffmap.cxx, but don't know where and how this map is used to convert to and from xlsx. This area may be way out my comfort zone, so I'm not sure at all yet whether I want to be the assignee for this bug :-) Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
