Issue 112489

Summary: Wrong handling of Addin functions, which are also core functions
Product: Calc Reporter: Regina Henschel <rb.henschel>
Component: save-exportAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: daniel.rentz, issues, ooo
Version: OOo 3.2   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

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.