Hi Regina, On Friday, 2009-03-13 22:20:35 +0100, Regina Henschel wrote:
> It is a concession that the missing parameters are added, although the > user who will export to Excel-format should know, that Excel expects > three parameters. Not necessarily. They might use OOo and just have to export to Excel for some poor business partner or school teacher ... ;) Besides that, do you remember every function you used in a complex spreadsheet you built over the last 3 years? > Shouldn't we do the same for saving in old OOo > formats, especially, when OOo3.0 is set in general to use ODF1.0-format? Yes, should be done for backward compatibility. > If you agree, that in cases saving to old OOo-formats the missing second > and third parameters should be added, Not only the old 1.0/1.1 format, but also the new 1.2 format using ODFF, so that a 3.0/3.1 will be able to read it. > where is the place to do it? That's now in formula/source/core/api/token.cxx Take a look at these methods: 1. MissingConvention::isRewriteNeeded() Add the OpCode to the unconditional switch case. 2. FormulaMissingContext::AddMoreArgs() Add a new case for the OpCode to the switch. Note that mnCurArg is 0-based and indexes the last argument passed to the function. FormulaMissingContext::AddMissing() is only needed if a new version allows missing arguments between arguments, such as in FOO(1;;3) where the second parameter's argument is missing. >> [... Excel export ...] >> The "C" means that the 4th parameter is Calc-only and will be stripped >> on export. The trailing "I" is needed for some internal resons. > > I have done first the changes in formulabase.cxx. That gives no error, > but I see no effect, so I cannot say if it really works. Then I changed > xlformula.cxx. That works, now the entry in the xls-file has three > parameters in all cases. > > I have rethought the problem. It seems no good idea to strip the fourth > parameter. If it is stripped, there are no errors in Excel, but the > cells might have different values than OOo, because in OOo you calculate > the density function and in Excel the cumulative function is calculated. > The user cannot notice, that the values are wrong, because there are no > warnings. That is not good and we should not do it. There is no way to > determine whether the forth parameter is true or false, because it might > be no constant but a reference. > > The same problem is, when saving to old OOo-formats. Using four > parameters should give an error, when opening in old versions. Yes, that's true for OOo and hopefully others interpreting the ODF formulas, so when writing ODF all parameters should be preserved. However, when writing Excel file formats we have to keep in mind that - for binary file formats Excel simply crashes if a function has more arguments than parameters expected - for XML file formats Excel in such cases strips away the formula and writes only the result to the cell, which when changing values the formula depended on will give a wrong result again. Both cases IMHO can be resolved satisfactorily only if the function's expression is replaced with a NA() call that generates an error in the target. 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.
pgpXACp10wVID.pgp
Description: PGP signature
