tdf97815 switching to English function names does not work with _ADD functions

[Eike Rathke]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20180528/dcf51eff/attachment.sig>