Regina Henschel schrieb am 25.07.2025 um 11:18:
Hi all,
this is about bug 167582. The fix itself is in
https://gerrit.libreoffice.org/c/core/+/188304
But currently without unit test.
I could add the test values themselves to
sc/qa/unit/data/functions/spreadsheet/fods/lookup.fods
But were to put the source file for the external links?
Make the source file a pseudo test, so that
sc_spreadsheet_functions_test does not fail?
Or is there another place?
I have tried to add files lookup_source.fods and lookup_target.fods to
the folder sc/qa/unit/data/functions/spreadsheet/fods/. That way it will
be used by CppunitTest_sc_spreadsheet_functions_test. That test goes
through all files in the folder and finally calls FunctionsTest::load()
in sc/qa/unit/functions_test.cxx for each fods file on that folder. My
files have the structure, that is expected by FunctionsTest::load(). But
it does not work at all.
I think, the following are the problems; please correct me, if I'm wrong.
For to get the external references work in every build environment, the
references need to use relative IRIs. Problem is, that LibreOffice do
not really write relative IRIs to the file markup, but uses a trick to
handle them pseudo-relative: LibreOffice fetches the values from the
source and stores them in a hidden table. This table is linked to the
source via a relative IRI. The name of this table is the absolute IRI as
it is written in the parameters of the function. After the file is
loaded, the user gets a message bar to update the links. Only then, when
the user updates the links, the absolute IRIs in the parameter are
updated to the current position of the source.
The method FunctionsTest::load() tests itself, whether the opened file
has the expected functions results. It makes a hard Recalc, but it does
not update the links. Thus the value in the test cell B3 is never true.
So the problem of writing a unit test is still unsolved.
Kind regards,
Regina
