Hello,
Regina Henschel schrieb:
Daniel Rentz schrieb:
Right, fix has been integrated into m77
http://qa.openoffice.org/issues/show_bug.cgi?id=79854
Now I have a build based on m78. I made some import/export tests.
Excel2003 xml is totally broken (issue 94261) and not mentioned below.
Yes, that filter is not in a good state.
== A ==
I have added SEC, CSC, SECH, and CSCH, to saFuncTable_Odf. All four new
functions have op-codes. Tests look good:
Reloading directly is correct for ods, xls, sdc, and sxc.
Loading and resaving with StarOffice8 (for ods, sdc, and sxc) and
Excel2010 (for xls) and then loading in my build is correct too.
Good! Did you add them to the sc and oox modules?
== B ==
But I have still questions concerning the new imaginary functions. Those
functions have no op-code. Need I to add them to saFuncTable_Odf? If
yes, how can I do it?
Yes, the filters in sc are used for import/export of the XLS format. On
export, the current behaviour is:
If the function is an add-in function, the XCompatibilityNames interface
is used to retrieve its name used in the XLS file format (see in file
sc/source/filter/excel/xeformula.cxx, in function
XclExpFmlaCompImpl::AppendAddInCallToken(), call to GetExcelName()). So
I would suggest that this interface returns the "_xlfnodf.XYZ" function
names, to not get any name clashes with existing functions in Excel. The
import filter will try to convert these function names back to add-in
functions, again with the mentioned interface. But I do not know if this
will work out of the box. In file sc/source/filter/excel/xiroot.cxx,
there is a function XclImpRoot::GetScAddInName() that calls
GetCalcName() if you want to debug it.
I tried to add them to saFuncTableOdf in oox/source/xls/formulabase.cxx,
but does not know, which values to use for eighth and ninth parameter. I
have tried all combination of {RR},{VR} and FUNCFLAG_EXTERNAL,
FUNCFLAG_MACROCALLODF. But it has no effect on my test results.
Currently, the filters in the oox modules are only used to import XLSX
and XLSB file format. As we cannot export to these formats, the new
functions should not appear in these files. (It is planned to move the
old filters from sc to oox, but this is not finished yet.) So, it is
more important to add them to the sc filters.
To answer the question:
- 8th parameter: The token class codes RR, VR, etc. are important for
the function parameters, to let Excel distinguish reference, array, and
value parameters. They do not affect how the function itself is handled.
If you have "regular" value parameters, the code VR is sufficient in
most cases.
- 9th parameter: Special flags. Are used to trigger some special
behaviour in the filters. All functions unknown by Excel should get the
FUNCFLAG_MACROCALLODF flag. This will cause the import filter to convert
the function "_xlfnodf.FUNCNAME" to "FUNCNAME".
The test results are:
== B1 Directly reloading ==
Correct with general setting 'ODF 1.0' in ods, sdc, sxc, and xls
Correct with general setting 'ODF 1.2 extended' in ods, sdc, and xls. It
fails for sxc (issue 95312).
== B2 Opening and resaving in StarOffice8 and Excel2010, reloading in my
build ==
Correct with general setting 'ODF 1.0' in xls, sdc, and sxc.
Correct with general setting 'ODF 1.2 extended' in xls and sdc.
In the cases
'ODF 1.0' with ods and
'ODF 1.2 extended' with sxc and ods,
the new functions are reloaded with #NAME?, but the cells contain the
formulas like '=imsech(z)'.
In contrast to issue 95312 the old imaginary functions are handled
correctly in this round trip through StarOffice8 and Excel2010
respectively.
Cannot say about the ODF filter, Eike should know better.
Do I miss something, or is that a general error with 'new' addin-functions?
Please have a look at issue 101386. Is it the same problem?
Again, something for Eike.
Regards
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
