Hi Winfried, On Monday, 2015-02-09 20:49:45 +0100, Eike Rathke wrote:
We have something similar with formula::svEmptyCell, my rough guess now is it should be enough to treat svMissing the same as svEmptyCell in comparisons (ScInterpreter::Compare() and ScInterpreter::CompareMat()), instead of forcing it into a context of svDouble at that stage, and when preparing the final result check for an ocMissing (interpr4.cxx line 4371 in Interpret() at "obtain result" before the current if( pCur->GetOpCode() == ocPush )) and if so pop it and push an empty cell, i.e. Pop(), PushTempToken( new ScEmptyCellToken( false, false))
So, rethinking, doing so would solve some common use cases, but not generalize things. Actually it would be smarter to push an svEmptyCell instead of svMissing for an ocMissing (in ScInterpreter::ScMissing()) in the context of an IF or IFERROR/IFNA jump path, i.e. if it is the only opcode in the path. That should be detectable by determining whether the current formula::FormulaTokenIterator is at the end of the code path, as only then the '"return" an ocMissing as code path' condition can occur. It may be sufficient to check aCode.IsEndOfPath() for this. 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
Attachment:
pgp6hIB78QwIe.pgp
Description: PGP signature