Issue 112489 - Wrong handling of Addin functions, which are also core functions
Summary: Wrong handling of Addin functions, which are also core functions
Status: CONFIRMED
Alias: None
Product: Calc
Classification: Application
Component: save-export (show other issues)
Version: OOo 3.2
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-17 21:00 UTC by Regina Henschel
Modified: 2013-01-29 21:41 UTC (History)
3 users (show)

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

Attachments
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 Regina Henschel 2010-06-17 21:00:57 UTC 
Take a spreadsheet.
Enter =ISEVEN(8)  You should see TRUE
Enter =ISEVEN_ADD(8)   You should see 1

Save to ods while Load/Save setting is "ODF 1.2"
Reopen.
Error: The formula =ISEVEN_ADD(8) is changed to =ISEVEN(8), without the _ADD
appendix.

Same entries, save to xls.
Reopen.
Error: The entry =ISEVEN shows #MACRO?, although the cell content is correctly
=ISEVEN(8)

(Save to ods while Load/Save setting is "ODF 1.0" and reopen gives a correct file.)
Comment 1 ooo 2010-06-18 14:02:19 UTC 
Saving ISEVEN_ADD as ISEVEN for ODF 1.2 is on purpose. We don't want two
different functions that do the same.

@dr:
How could we tell Excel that a function internal to OOo should be an AddIn
function in Excel? This applies to all functions that have
ScCompiler::AddInMap.bMapDupToInternal=true in 
sc/source/core/tool/odffmap.cxx, so the Excel export should consider that. We
may have to add some OpCode mapping to the struct respectively replace
bMapDupToInternal with an OpCode to look functions up for export, but I do not
want to maintain several places in the Excel export.