Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
That's odd. I'd have to take a deeper look at that. I expected that with
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT },
the last IMCOT would had setup the map for FormulaGrammar::GRAM_PODF to
be used in 'oooc:' namespace import, see ScCompiler::fillFromAddInMap().
Using FindFunction() may be a workaround, but I'd rather find the real
cause and a different solution without looking through all AddIns.
I have tested it once again. And you are right, using
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT }
works indeed. It was my fault, nothing to do for you. I'll will change
the file in this way.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Regina Henschel schrieb:
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
That's odd. I'd have to take a deeper look at that. I expected that with
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot, IMCOT },
the last IMCOT would had setup the map for FormulaGrammar::GRAM_PODF to
be used in 'oooc:' namespace import, see ScCompiler::fillFromAddInMap().
Using FindFunction() may be a workaround, but I'd rather find the real
cause and a different solution without looking through all AddIns.
I have tested it once again. And you are right, using
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT }
works indeed. It was my fault, nothing to do for you. I'll will change
the file in this way.
The round trip ODF1.2 - OOo2.4.3 - ODF1.2 for sxc file format is OK
with that setting, but now sxc files fail both for reopen and for round
trip through OOo2.4.3 if load/save setting is ODF1.0 with an entry of
kind =com.sun.star.addin.analysis.getimcot :(
I have attached a summary of my tests and the current version of my work
(based on DEV300m78) to issue 111609. Perhaps you can find the cause of
the Addin troubles.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Thursday, 2010-06-03 16:56:56 +0200, Regina Henschel wrote:
[..]
Using in odffmap.cxx the entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
results in the correct attribute in the file.
Thanks for clarifying, I already started to wonder ;-)
That the round trip though OOo2.4.3 does not work for sxc file format
can be solved be forcing OOo3 to setting ODF 1.0/1.1 when saving in
sxc, as already suggested in issue 95312. So the remaining problem would
be the round trip of an ods document produced with ODF 1.2 setting. Do
you can give me a hint, how I can tell OOo3 to translate
oooc:=IMCOT(z) to a valid function call when opening such document
coming from OOo2.4.3? Or do you know a way to get the correct attribute
in the file format, when using the IMCOT entry in odffmap.cxx?
I have now looked at ScCompiler::IsOpCode. You have added a comment
(line 2520)
// If that isn't found we might continue with rName lookup as a
// last resort by just falling through to FindFunction(), but
// it shouldn't happen if the map was setup correctly. Don't
// waste time and bail out.
I have now added this FindFunction()
if (!aIntName.Len())
{
aIntName = ScGlobal::GetAddInCollection()-FindFunction(
rName, !mxSymbols-isEnglish());
}
And now all new AddIn-Functions are found when reloading and after
roundtrip through OOo2.4.3, both in setting ODF 1.0 and 1.2, and both in
ods and sxc format. So there might be something wrong with the map?
Kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
same additional information:
I use the odffmap entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT }
(1) Save document in setting ODF 1.2.
(2) Open it in OOo2.4.3 and save there. That results in document version
ODF1.1 and file attribute oooc=IMCOT.
(3) Open in my Build results in shown value #NAME? and cell content =imcot.
(4) Now save as in setting ODF 1.2 and reload. The function IMCOT is
detected correctly.
Is there perhaps some recompiling missing, when first opening in step (3)?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel,
Daniel Rentz schrieb:
Hi Regina,
Regina Henschel schrieb:
If I use ocExternal the prefix is set, but the functions are not
distinct, only one name is written and on import the whole function
name is stripped, so only =(z) remains from =_xlfnodf.IMSECH(z).
I see no way to add the imaginary functions to list saFuncTable_Odf,
because they have no op-code.
Do I understand you right, that I should try to add the prefix in
function GetExcelName in /sc/.../addincol.cxx?
Yes, that was the idea, sort of. Sorry, I was not clear enough about
this. In my eyes, the solution is to not touch the _Odf table, but to
add the functions into the resource files in scaddins that are used for
the XCompatibilityNames implementation. This would be in
scaddins/source/analysis/analysis_deffuncnames.src. These strings are
returned by the GetExcelName() functions of the addin collection.
I have now used in analysis_deffuncnames.src an entry:
StringArray ANALYSIS_DEFFUNCNAME_Imcot
{
ItemList =
{
_xlfnodf.IMCOT; ;
_xlfnodf.IMCOT; ;
};
};
And for comparison an entry
StringArray ANALYSIS_DEFFUNCNAME_Imcsc
{
ItemList =
{
IMCSC; ;
IMCSC; ;
};
};
This are the results, all in setting ODF 1.2 and always saving to xls
format:
As far as I can see in the binary of the file, the function name is
stored as _xlfnodf.IMCOT and IMCSC respectively. The order of that
function names is: addin functions, named references, core functions.
(1) Opening and saving in Excel, then reopening in my build: All
functions are recognized correctly. It makes no difference using prefix
_xlfnodf. or not.
(2) Opening and saving in OOo2.4.3, then reopening in my build: In
OOo2.4.3 the unknown core functions are marked as #MACRO?, the unknown
addin functions as #ADDIN? Reopening in my build the core functions are
recognized, the addin functions are not recognizes and marked as #MACRO?
Here too, it makes no difference using prefix _xlfnodf. or not.
(3) Opening and saving in Gnumeric, then reopening in my build: All
functions with prefix _xlfnodf are not recognized, the addin functions
without prefix are recognized. Reopening in my build all core functions
are recognized, the addin functions without prefix are recognized, the
addin functions with prefix are not recognized.
So for the round trip through
Excel: It makes no difference whether use prefix or not; works always,
OOo2.4.3: It makes no difference whether use prefix or not; works never,
Gnumeric: Works without prefix, fails with prefix.
Should I use the prefix as described above?
Do you know, why reopen result from OOo243 fails?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi,
Regina Henschel schrieb:
I have now used in analysis_deffuncnames.src an entry:
StringArray ANALYSIS_DEFFUNCNAME_Imcot
{
ItemList =
{
_xlfnodf.IMCOT; ;
_xlfnodf.IMCOT; ;
};
};
And for comparison an entry
StringArray ANALYSIS_DEFFUNCNAME_Imcsc
{
ItemList =
{
IMCSC; ;
IMCSC; ;
};
};
This are the results, all in setting ODF 1.2 and always saving to xls
format:
As far as I can see in the binary of the file, the function name is
stored as _xlfnodf.IMCOT and IMCSC respectively. The order of that
function names is: addin functions, named references, core functions.
(1) Opening and saving in Excel, then reopening in my build: All
functions are recognized correctly. It makes no difference using prefix
_xlfnodf. or not.
Good, I expected that :)
(2) Opening and saving in OOo2.4.3, then reopening in my build: In
OOo2.4.3 the unknown core functions are marked as #MACRO?, the unknown
addin functions as #ADDIN? Reopening in my build the core functions are
recognized, the addin functions are not recognizes and marked as #MACRO?
Here too, it makes no difference using prefix _xlfnodf. or not.
As the add-in implementation of OOo 2.4.3 does not know about these
functions, the Excel filter cannot handle them (e.g. it does not get
them from GetExcelName()).
(3) Opening and saving in Gnumeric, then reopening in my build: All
functions with prefix _xlfnodf are not recognized, the addin functions
without prefix are recognized. Reopening in my build all core functions
are recognized, the addin functions without prefix are recognized, the
addin functions with prefix are not recognized.
Would be interesting how Gnumeric saves the _xlfnodf functions.
I have introduced the _xlfnodf prefix for Calc-internal functions
unknown to Excel to prevent name clashes with e.g. Basic macros that
have the same name. Excel keeps the function names (but cannot work with
them of course) and writes them out exactly as it has read them, so the
import filter can convert back the name _xlfnodf.XYZ to the internal
function XYZ.
I think, in this case you can remove the prefix, because we have add-in
functions, and not core functions. In the XLS format, the add-in
functions are written into their own namespace and therefore cannot be
mixed up with Basic macro calls.
Regards
Daniel
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
HI Eike,
Regina Henschel schrieb:
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Sunday, 2010-05-30 22:44:06 +0200, Regina Henschel wrote:
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.
Do I miss something, or is that a general error with 'new'
addin-functions?
Please add the new function names to sc/source/core/tool/odffmap.cxx
that should fix ODF 1.0/1.1 and ODF 1.2 .ods
They are already in the list
ScCompiler::AddInMap ScCompiler::maAddInMap[]
For example
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
I have mimic the entries of the existing ones.
If I set load/save to ODF 1.0/1.1 before saving, the round trip
mybuild - OOo2.4.3 - mybuild is OK for file format ods, sxc and sdc.
If I set load/save to ODF 1.2 before saving, the round trip mybuild
-OOo2.4.3 - mybuild is correct for file format sdc. But in file format
ods and sxc the new addin-functions are marked with #NAME?, although the
cell entries show the correct formula.
I have now changed the entries to the form, for example
{ IMCOT, IMCOT, false, IMCOT, IMCOT },
Now I can use setting ODF 1.2 or ODF 1.0/1.1, file format ods, sxc,
or sdc, reopen directly or round trip through SO8 with keeping file
format. All cases work well. So I thing, that the OOo import/export part
is solved.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Regina Henschel schrieb:
HI Eike,
Regina Henschel schrieb:
I have now changed the entries to the form, for example
{ IMCOT, IMCOT, false, IMCOT, IMCOT },
Now I can use setting ODF 1.2 or ODF 1.0/1.1, file format ods, sxc,
or sdc, reopen directly or round trip through SO8 with keeping file
format. All cases work well. So I thing, that the OOo import/export part
is solved.
I have to take back the solved. In the file format the attribute then is
table:formula=of:=COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT(z)
but it should be
table:formula=of:=IMCOT(z)
because IMCOT is defined in ODFF. So Gnumeric cannot open the file
correctly although Gnumeric knows the function IMCOT.
Using in odffmap.cxx the entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
results in the correct attribute in the file.
That the round trip though OOo2.4.3 does not work for sxc file format
can be solved be forcing OOo3 to setting ODF 1.0/1.1 when saving in
sxc, as already suggested in issue 95312. So the remaining problem would
be the round trip of an ods document produced with ODF 1.2 setting. Do
you can give me a hint, how I can tell OOo3 to translate
oooc:=IMCOT(z) to a valid function call when opening such document
coming from OOo2.4.3? Or do you know a way to get the correct attribute
in the file format, when using the IMCOT entry in odffmap.cxx?
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Regina,
On Thursday, 2010-06-03 16:56:56 +0200, Regina Henschel wrote:
I have now changed the entries to the form, for example
{ IMCOT, IMCOT, false, IMCOT, IMCOT },
Now I can use setting ODF 1.2 or ODF 1.0/1.1, file format ods, sxc,
or sdc, reopen directly or round trip through SO8 with keeping file
format. All cases work well. So I thing, that the OOo import/export part
is solved.
I have to take back the solved. In the file format the attribute then is
table:formula=of:=COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT(z)
but it should be
table:formula=of:=IMCOT(z)
because IMCOT is defined in ODFF. So Gnumeric cannot open the file
correctly although Gnumeric knows the function IMCOT.
Using in odffmap.cxx the entry
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
results in the correct attribute in the file.
Thanks for clarifying, I already started to wonder ;-)
That the round trip though OOo2.4.3 does not work for sxc file format
can be solved be forcing OOo3 to setting ODF 1.0/1.1 when saving in
sxc, as already suggested in issue 95312. So the remaining problem would
be the round trip of an ods document produced with ODF 1.2 setting. Do
you can give me a hint, how I can tell OOo3 to translate
oooc:=IMCOT(z) to a valid function call when opening such document
coming from OOo2.4.3? Or do you know a way to get the correct attribute
in the file format, when using the IMCOT entry in odffmap.cxx?
Off-head, as pre-3.0 doesn't implement that function and the (upper)
programmatical name is not expected to be encountered in documents
originating from ODF 1.1 and earlier, does
{ IMCOT, IMCOT, false, com.sun.star.sheet.addin.Analysis.getImcot,
IMCOT },
already help?
Eike
--
OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer.
SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't send personal mail to the e...@sun.com account, which I use for
mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks.
pgpWQwGdJn7RK.pgp
Description: PGP signature
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Regina, Regina Henschel schrieb: If I use ocExternal the prefix is set, but the functions are not distinct, only one name is written and on import the whole function name is stripped, so only =(z) remains from =_xlfnodf.IMSECH(z). I see no way to add the imaginary functions to list saFuncTable_Odf, because they have no op-code. Do I understand you right, that I should try to add the prefix in function GetExcelName in /sc/.../addincol.cxx? Yes, that was the idea, sort of. Sorry, I was not clear enough about this. In my eyes, the solution is to not touch the _Odf table, but to add the functions into the resource files in scaddins that are used for the XCompatibilityNames implementation. This would be in scaddins/source/analysis/analysis_deffuncnames.src. These strings are returned by the GetExcelName() functions of the addin collection. Regards Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Regina, On Sunday, 2010-05-30 22:44:06 +0200, Regina Henschel wrote: 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. Do I miss something, or is that a general error with 'new' addin-functions? Please add the new function names to sc/source/core/tool/odffmap.cxx that should fix ODF 1.0/1.1 and ODF 1.2 .ods Please have a look at issue 101386. Is it the same problem? No, that is about the old Add-Ins using the deprecated binary interface. Though all is related somehow.. Eike -- OOo/SO Calc core developer. Number formatter stricken i18n transpositionizer. SunSign 0x87F8D412 : 2F58 5236 DB02 F335 8304 7D6C 65C9 F9B5 87F8 D412 OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't send personal mail to the e...@sun.com account, which I use for mailing lists only and don't read from outside Sun. Use er...@sun.com Thanks. pgpNQWG40Vpob.pgp Description: PGP signature
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Eike,
Eike Rathke schrieb:
Hi Regina,
On Sunday, 2010-05-30 22:44:06 +0200, Regina Henschel wrote:
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.
Do I miss something, or is that a general error with 'new' addin-functions?
Please add the new function names to sc/source/core/tool/odffmap.cxx
that should fix ODF 1.0/1.1 and ODF 1.2 .ods
They are already in the list
ScCompiler::AddInMap ScCompiler::maAddInMap[]
For example
{ IMCOT, IMCOT, false,
com.sun.star.sheet.addin.Analysis.getImcot,
COM.SUN.STAR.SHEET.ADDIN.ANALYSIS.GETIMCOT },
I have mimic the entries of the existing ones.
If I set load/save to ODF 1.0/1.1 before saving, the round trip
mybuild - OOo2.4.3 - mybuild is OK for file format ods, sxc and sdc.
If I set load/save to ODF 1.2 before saving, the round trip mybuild
-OOo2.4.3 - mybuild is correct for file format sdc. But in file format
ods and sxc the new addin-functions are marked with #NAME?, although the
cell entries show the correct formula.
kind regards
Regina
-
To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org
For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
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
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hallo Daniel, Daniel Rentz schrieb: Hello, Regina Henschel schrieb: == 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? I have added them only to saFuncTable_Odf in sc/.../xlformula.cxx. They get the prefix _xlfnodf., I see it in the xls file. == 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 have added the imaginary functions to saFuncTable_Odf with opcode ocNoName now. The prefix _xlfnodf. is not set. It does not work out of the box. You do not notice the missing prefix in the test results, when testing the round trip mybuild - Excel - mybuild. There the cell entries are OK. But you see it in the round trip in xls format mybuild - OOo243 - mybuild, which results in #MACRO?, and if you look into the xls file with an editor. if you want to debug it There is no hurry to implement the new functions. So I will try to make it correct and learn a little bit about the filters. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Regina Henschel schrieb: Hi Daniel, Daniel Rentz schrieb: Same for the equivalent table saFuncTable_Odf in sc/source/filter/excel/xlformula.cxx. It seems, that I have to wait till m78, because m76 does not contain saFuncTable_Odf and m77 does not build for me. Right, fix has been integrated into m77 http://qa.openoffice.org/issues/show_bug.cgi?id=79854 Daniel - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
On 05/16/10 21:31, Regina Henschel wrote: Daniel Rentz schrieb: scadddins/analysis should contain only these functions that Excel offers in its Analysis add-in. New functions should go into the Calc core IMHO. (Anyway, starting from Excel 2007, all Analysis functions are built-in in Excel.) I'm not sure if the filters are prepared to handle functions from the Calc Analysis add-in that do not exist in Excel. Will think about that tomorrow :) I have collected the function names including the used categories [1]. This might help to decide, whether those functions, which are part of ODFF, should be moved to somewhere else. [1] http://wiki.services.openoffice.org/wiki/File:Compare_Function_Category_Excel_ODF_OOo.ods Simply moving a function will cause some changes in behavior (like the API getFormula method). For consistency, let's add the new complex-number functions to the analysis add-in, so their behavior is as similar as possible to the existing functions. There are already add-in functions that have no Excel equivalent (like ROT13 in the date add-in), probably the new functions can be handled the same way. Niklas - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
On 05/17/10 00:21, Regina Henschel wrote: When reloading into my patched DEV300m76 I get this up to now, without any entry in the files formulabase.cxx: save in .sxc: All addin functions, including the existing ones, result in #Name?, but the cell content contains the correct formula. That part is due to issue 95312. Niklas - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: Hi regina, Regina Henschel schrieb: the file oox/source/xls/formulabase.cxx has a section /** Functions defined by OpenFormula, but not supported by Calc or by Excel. */ Does this refer to the draft ODF 1.2 formula spec? No. I just scanned the function op-codes defined by sc (nowadays formula/inc/formula/opcode.hxx). Which functions are listed there? For example, why are the imaginary functions and the secant functions not listed there? This list in oox is not used anywhere. So I need not worry about that file? I added it to have the entries available for copypaste once Calc and Excel will support the functions... Which functions are we talking about exactly? I'm working on SEC, CSC, SECH and CSCH (issue 111413) and on IMCOSH, IMCOT, IMCSC, IMCSCH, IMSEC, IMSECH, IMSINH, IMTAN (issue 111609). The code is nearly ready, but for filters. For filters I would need some advise, what to change and add. SEC, CSC, SECH and CSCH are normal functions in the Math-group and the IMxxx-functions belong to scadddins/analysis. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: scadddins/analysis should contain only these functions that Excel offers in its Analysis add-in. New functions should go into the Calc core IMHO. (Anyway, starting from Excel 2007, all Analysis functions are built-in in Excel.) I'm not sure if the filters are prepared to handle functions from the Calc Analysis add-in that do not exist in Excel. Will think about that tomorrow :) I have collected the function names including the used categories [1]. This might help to decide, whether those functions, which are part of ODFF, should be moved to somewhere else. [1] http://wiki.services.openoffice.org/wiki/File:Compare_Function_Category_Excel_ODF_OOo.ods kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: Regina Henschel schrieb: Hi Daniel, Daniel Rentz schrieb: Hi regina, Regina Henschel schrieb: the file oox/source/xls/formulabase.cxx has a section /** Functions defined by OpenFormula, but not supported by Calc or by Excel. */ Does this refer to the draft ODF 1.2 formula spec? No. I just scanned the function op-codes defined by sc (nowadays formula/inc/formula/opcode.hxx). Which functions are listed there? For example, why are the imaginary functions and the secant functions not listed there? This list in oox is not used anywhere. So I need not worry about that file? Sorry, just have taken a closer look. This table *is* used to preserve Calc-only functions in roundtrip (save to Excel, load from Excel). When reloading into my patched DEV300m76 I get this up to now, without any entry in the files formulabase.cxx: save in .sxc: All addin functions, including the existing ones, result in #Name?, but the cell content contains the correct formula. save in .xls: All addin functions are correct including the new ones, all other functions unknown to Excel are shown with #MACRO?, but the cell content contains the correct formula. For the Addin functions the information in analysis_deffuncnames.src is used. save in .xml: All functions have an additional of:]. Excel cannot read the file. But that is not my fault, that is already broken in OOo3.2. So I think, that using new Addin functions works well. Gnumeric can read the ods file with all new functions, the normal and the Addin function. Same for the equivalent table saFuncTable_Odf in sc/source/filter/excel/xlformula.cxx. [..] Just add the new functions to the tables. As Excel does not know them (right?), the entries are used to create a unique function name in the Excel file format (e.g. _xlfnodf.SEC), and the import filter will restore the function known by Calc. Will try the filter files tomorrow. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
Re: [sc-dev] Questions about oox/source/xls/formulabase.cxx
Hi Daniel, Daniel Rentz schrieb: Same for the equivalent table saFuncTable_Odf in sc/source/filter/excel/xlformula.cxx. It seems, that I have to wait till m78, because m76 does not contain saFuncTable_Odf and m77 does not build for me. kind regards Regina - To unsubscribe, e-mail: dev-unsubscr...@sc.openoffice.org For additional commands, e-mail: dev-h...@sc.openoffice.org
