Hi Winfried, I'm also mixing in some quotes from your previous mail of this topic
On Sunday, 2017-02-26 14:10:57 +0100, Winfried Donkers wrote:
On Wednesday, 2017-04-12 16:37:54 +0200, Winfried Donkers wrote:
> I'm sort of stuck with tdf106013.
>
> There is a group of Add-In functions that were newly defined in Excel 2013
> (IMCOSH, IMCOT, IMCSC, IMCSCH, IMSEC, IMSECH, IMSINH and IMTAN, I'll call
> them IMxx).
>
> In Calc these functions are defined in scaddins and also mentioned in
> sc/source/filter/oox/formulabase.cxx in saFuncTable2013[].
>
>
> The problem is that the IMxx functions saved as xlsx by Calc won't open
> correctly by Excel and vice versa.
>
> Calc writes the IMxx functions in xlsx as =IMxx(...), just as on ods.
>
> Excel writes the IMxx functions in xlsx as =_xlfn.IMxx(...), and in ods as
> =IMxx(...).
>
> The other Add-In functions are written by both Calc and Excel as
> =FUNCTIONNAME(...).
This is due to that the functions defined in the Add-In were defined by
Excel long ago and are part of OOXML, and those Add-In functions are
treated accordingly during export. Unfortunately the exceptional IM*
cases don't seem to fit into the XclFunctionInfo tables of
sc/source/filter/excel/xlformula.cxx, only the case of writing an
internal function as Add-In is handled there (those with
EXC_FUNCFLAG_ADDINEQUIV set). But the lookup is done by OpCode in those
tables, so that doesn't work for ocExternal.
> When I define the IMxx functions as regular functions, there are written as
> =_xlfn.IMxx(...) in xlsx, but when written to xls, they give problems when
> opening in Excel.
Where and how did you define them as regular functions? Were they also
written as _xlfn.IMxx to .xls? Or without _xlfn.? As macro calls? Or...?
> Any suggestions for a solution?
I could imagine to define some extra range of OpCode for XclFunctionInfo
starting at 0xFF00 or any other unused high value and for
ocExternal/svExternal do an extra lookup depending on the value of the
XclExpScToken's aTokData.mpScToken->GetExternal() programmatical name,
that for example is "com.sun.star.sheet.addin.Analysis.getImcsch", using
a simple std:map like
opcodevalue["com.sun.star.sheet.addin.Analysis.getImcsch"] = 0xFF00;
The corresponding XclFunctionInfo entry then could be
{ 0xFF00, 255, 2, 2, V, { RO_E, RO },
EXC_FUNCFLAG_EXPORTONLY, EXC_FUNCNAME( "IMCSCH" ) },
Note that these 255-export-only definitions due to the BIFF .xls macro
call storage use minparam+1 and maxparam+1, so for IMCSCH that expects
one parameter the definition is 2,2
In XclExpFmlaCompImpl::ProcessFunction() there's
maFuncProv.GetFuncInfoFromOpCode( eOpCode )
which for (eOpCode == ocExternal && rTokData.GetType() == svExternal)
would needed to be called with the new eOpCode according to the mapping.
I hope that helps.
> I just noticed that tdf100450 regarding the Add-in function ACCRINT has a
> similar problem.
> It currently reflects pre-Excel2013 behaviour, but does not comply with
> ODFF1.2 or with the current Excel.
Probably keep the 7 parameters ACCRINT as Add-In function but name it
ACCRINT_EXCEL or such, and for 8 parameters introduce a new ACCRINT
function that is stored as _xlfn.ACCRINT (or whatever Excel does? OOXML
only defines 7 parameters).
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
