Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.