Issue 86171 - ODFF: MINA(range)=MIN(range): text should equal zero also for formulas returning text
Summary: ODFF: MINA(range)=MIN(range): text should equal zero also for formulas return...
Status: CLOSED FIXED
Alias: None
Product: Calc
Classification: Application
Component: programming (show other issues)
Version: OOo 2.3.1
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sc
URL:
Keywords: ms_interoperability, oooqa
Depends on:
Blocks: 72764
  Show dependency tree
 
Reported: 2008-02-18 08:48 UTC by aliby
Modified: 2013-08-07 15:15 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
A patch. (663 bytes, text/plain)
2008-02-22 07:39 UTC, lvyue 		no flags Details
Second patch, based on the first, simplifed the condition. (624 bytes, text/plain)
2008-02-25 07:47 UTC, lvyue 		no flags Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description aliby 2008-02-18 08:48:02 UTC 
The solution to MINA(range) and MIN(range) is currently the same
MINA() should treat text as a zero value as per the function description even if
part of a range.

if A1=3; A2=2; A3=1; A4="text" then
MIN(A1:A4) =1 as it ignores text entries
MINA(A1:A4)=1 where it should be zero

NOTE however that ...
MINA(A1:A3;A4)=0 as it recognizes the text in the single entry

Also on Linux OOo Calc 2.3.0 (don't have 2.3.1) ...
MINA(A1:A4)=0 as it should be.
Comment 1 ooo 2008-02-18 13:49:14 UTC 
The problem here are formulas returning text. MINA(Ref) works fine if in Ref a
cell contains text, but formula cells in Ref are ignored.
Comment 2 aliby 2008-02-21 13:07:08 UTC 
Confirmed to be the same on Linux
TEXT is OK
Formulae returning TEXT is not OK
Comment 3 lvyue 2008-02-22 07:39:16 UTC 
Created attachment 51646 [details]
A patch.
Comment 4 ooo 2008-02-22 12:05:31 UTC 
Looks like the correct approach in general. However, since the previous condition

    if ( rErr || ((ScFormulaCell*)pCell)->IsValue() )

already obtained IsValue() during the boolean short-circuit (if the condition
does not match, IsValue() returned false) that doesn't need to be evaluated
again, the resulting code could be simplified to something like (untested and
off-hand)

    if ( rErr || ((ScFormulaCell*)pCell)->IsValue() )
        ...
    else if ( bTextAsZero )
        ...

Did you check the other interpreter cases where the ScValueIterator is used with
bTextAsZero? Did they exhibit wrong behavior as well that now is fixed?

Thanks
  Eike
Comment 5 lvyue 2008-02-25 07:47:33 UTC 
Created attachment 51700 [details]
Second patch, based on the first, simplifed the condition.
Comment 6 ooo 2008-03-12 09:58:36 UTC 
Setting to type PATCH.
Comment 7 ooo 2008-03-12 10:07:17 UTC 
And of course it ain't new anymore..
Comment 8 ooo 2008-04-10 17:07:14 UTC 
In cws odff03:

sc/source/core/data/dociter.cxx  1.20.22.1
Comment 9 ooo 2008-05-09 18:01:38 UTC 
Reassigning to QA for verification.
Comment 10 oc 2008-06-04 14:19:05 UTC 
verified in internal build cws_odff3
Comment 11 lohmaier 2008-08-05 18:35:41 UTC 
ok in m28