Hi Winfried, Btw, the bug title is misleading, it shouldn't be only ..._ADD functions but all Add-In functions. On Monday, 2018-05-28 09:41:20 +0000, Winfried Donkers wrote:
As I did some work in the past on this aspect, I try to fix this bug, even though I am not a big fan of the Add-In functions ;-). I came across code that I don't understand enough: 1. /scaddins/source/analysis/deffuncname.hxx contains a lot of static const char*[2], with German and English function name. Why is there a German function name, can't this be removed (this German function name must at least be related to the cause of the bug)?
Hairy stuff.. old Excel versions used to store localized (gasp!) Add-In function names, which these are used for, stored in FuncDataBase::pCompListID, then aCompList then obtained via FuncData::GetCompNameList() in AnalysisAddIn::getCompatibilityNames(), see also offapi/com/sun/star/sheet/XCompatibilityNames.idl
2. /scaddins/source/analysis/analysishelper.cxx contains a const FuncDataBase pFuncDatas[], that uses a macro FUNCDATA, which uses "get" to fill the structure. I can't easily find this "get"; do you know where it is defined?
It's not a function name to be called, but the FUNCDATA macro builds a string from "get" #FUNCNAME, for example with FUNCNAME "Workday" it gives "getWorkday". This with the namespace prefix "com.sun.star.addin.Analysis." then forms the programmatical name (e.g. here "com.sun.star.addin.Analysis.getWorkday") that was also used to store the function call in formulas prior to ODFF (i.e. Pre-ODF, PODF, ODF_11). See also sc/source/core/tool/odffmap.cxx and ScCompiler::fillFromAddInMap(). Note that the FUNCDATA macro also assigns ANALYSIS_FUNCNAME_##FUNCNAME (with the example FUNCNAME "Workday" resulting in the ANALYSIS_FUNCNAME_Workday symbol, see scaddins/inc/strings.hrc) to FuncDataBase::pUINameID which is used via FuncData::GetUINameID() to lookup the actual UI name in AnalysisAddIn::getDisplayFunctionName(), which uses AnalysisAddIn::AnalysisResId() to call Translate::get(). The underlying problem (localization not switched) seems to be somehow related to that either AnalysisAddIn::setLocale() is not called, or the there called AnalysisAddIn::InitData() does not actually result in a new Translate locale, or (most likely) the function name change is not propagated to ScCompiler's UI symbol table, i.e. that probably needs to be re-read/created with the then current Add-In names, see sc/source/core/tool/compiler.cxx ScCompiler::fillFromAddIn...() functions called from from formula::FormulaCompiler::loadSymbols() like FormulaCompiler::InitSymbolsEnglish() does, but it does that only once and probably does it when the Add-Ins' locale was still set to the current UI localization. Just guessing here. Finally, I can feel your pain ;) took me a while to dig through.. Hope that helps Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
signature.asc
Description: PGP signature