ARRAYTOTEXT returns a cell range or array as one text string,
taking the range and an optional format number.
Format 0 (or omitted) joins the values in row order with ", ".
Format 1 gives an array constant: braces around the array, ","
between columns, ";" between rows, and text quoted with any
inner double quote doubled. Any other format returns #VALUE!.
A number keeps its input-line text, a boolean reads TRUE or
FALSE in the current locale, an empty cell adds nothing, and an
error in a range lists as its error text while a reference to a
single error cell returns that error.
The function is wired up with its name tables, wizard entry,
parameter classification, and OOXML and binary filter mappings.
A self-checking OOXML workbook is verified after import and
after an XLSX and an ODS round trip, each with a recalc, and the
exported files are checked for the ARRAYTOTEXT formula. A ucalc
test covers the locale-dependent boolean text for a value and
a range.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I0cdd9737a51f402e39cf9a1346f4c5326680fe8f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7219
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit f66673d65ee307f17512a4239dd4b52ac189ac20)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208395
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Relocate the whole solver component out of the standalone sccomp module
and into sc. This moves the SolverComponent base class, the CoinMP and
Swarm solvers, the differential evolution and particle swarm headers, the
UNO service registration, the scc string resource, and the two unit tests.
The now-empty sccomp module is removed.
The solvers are Calc specific. Moving them inside sc is the first step
toward letting them work directly with ScDocument, and eventually clone a
document or its sheets so trial calculations can run in parallel. That
direct access is only possible from inside sc, so the relocation has to
come first.
This is a pure relocation with no behaviour change. The translation domain
stays "scc" and its polocation still points at "sccomp", so the existing
translations keep loading unchanged. Re-homing the scc translation domain
into sc is left as a follow-up.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I5b972daae4c51f04ca394fc9a92f89ac0c4dd599
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3832
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 7f1bea8723761f97c053f2e7e46aab7081b1bb21)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208080
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The Lpsolve solver and the CoinMP solver are both used for the same
thing: a linear model, with optional integer variables by branch
and bound. CoinMP (CLP plus CBC) is the more capable and better
maintained of the two, so the lp_solve one adds a second bundled
dependency and a parallel copy of the solver code for no capability
the other lacks.
Remove the LpsolveSolver component, the bundled lp_solve external
(and its colamd dependency, which only lp_solve used), and all the
build, configure, packaging and license references to them.
A document may still name com.sun.star.comp.Calc.LpsolveSolver as
its engine. SolverSettings now reads that name as the CoinMP
solver, which solves the same model, so such documents keep
working.
The Calc solver test that exercised the engine now uses CoinMP. Its
knapsack model has a single optimal total value of 6987, which fills
the weight capacity of 1000 exactly and which CoinMP finds. The
lp_solve run had returned a suboptimal 6981, so the test now expects
the true optimum.
The build setup changes only take effect after re-running autogen.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia14d8c491779873da6b0157aa524056275adf8f5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3810
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e77738a7ca7d44fd9d1f852e26d46e3a6d60467b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208038
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
A1# is the postfix counterpart of the @ prefix. When A1 is
the origin of a dynamic-array formula spilled into A1:A4, A1#
refers to the whole spill range, so SUM(A1#) totals the four
values and ROWS(A1#) returns 4.
The new opcode ocSpill sits in the unary-operator range. The
tokenizer produces it from a bare # after a reference or
value. Otherwise # stays the start of a #REF! or #NAME!
token. The compiler routes it through PostOpLine so it
follows its operand in the RPN.
ScSpilledRange pushes the spill range as an ScMatrixRangeToken
so aggregating functions see the whole range, and ISREF
reports it as a reference. A master yields its matrix. A
plain number, string, or non-master matrix slot yields the
the cell value.
A freshly typed =A1# counts as an array result, so it
promotes to a dynamic-array master and spills again. A cell
that does not promote collapses the range by implicit
intersection to the row-aligned value, or #VALUE! outside the
range, keeping that cell's number format.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Idf2752af3f7575f6bc95b940344aa365415e4a2f
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5785
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.com>
(cherry picked from commit 9b97b0fc91bce4b8726ea210347e8ea84270e148)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207904
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
The strip walked the array twice with the same parenthesis
depth. Start past the inner open with nDepth = 2 and watch
for depth dropping to 1. If the next token is the outer
close, the inner pair spans the whole argument and is
stripped. Otherwise the parentheses stay.
Expose the helper from formulabuffer.hxx so the new
sc_oox_helpers_test target can drive it directly.
RedundantParenthesesStripperTest covers the strip cases
through the OOXML compiler.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: I6ab95382b7776833b343754cdafb746454739d51
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/5652
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
(cherry picked from commit 41557a39d420e45880070b6d942ebfbe32ef8b49)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207873
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Open the Basic IDE, activate the VBA module window, then run the
document macro and verify it does not fail with
'Property or method not found: CutCopyMode'.
This covers the regression where Basic IDE / Object Browser activity
disturb VBA member resolution for the active document.
Change-Id: Id54b76cc633ba76377f201e3c4afca06a094ea7e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197754
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
opencl-test-1.cxx and opencl-test-2.cxx call
ScModelTestBase::enableOpenCL() and disableOpenCL() unconditionally,
but those helpers in qahelper.cxx are wrapped in
#if HAVE_FEATURE_OPENCL. configure.ac adds OPENCL to BUILD_TYPE and
defines HAVE_FEATURE_OPENCL together, so without OPENCL the link
fails with unresolved externals on test_sc_opencl-1.dll (seen on the
Windows app build).
Gate the two tests on OPENCL via gb_Helper_optional, matching the
pattern already used for Package_opencl in the same file.
Signed-off-by: Andras Timar <andras.timar@collabora.com>
Change-Id: I4fc9572f98c9b4bbbaab81fad7dc28780ef37397
(cherry picked from commit 36e32e6126e761af9fa7689cc9c1e59aa8b9c46e)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206655
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The existing API allows creating a color scale conditional format but it
has no entries and there is no API to create an instance of
XColorScaleEntry in order to add one. For data bars the existing API
instead creates a conditional format with two existing entries and then
you can use the XDataBarEntry interface to modify them. This patch makes
the color scale API work like the databar one. It adds constants to
ConditionEntryType to create a 2-color or 3-color scale which have the
entries pre-created.
This is an API change because it adds constants to an unpublished
constant group. It also makes it so that the getType method on the
conditional format will now return either COLORSCALE2 or COLORSCALE3
depending on the number of entries. In practice I think this is very
unlikely to break any existing code.
Change-Id: I28faa6c66ac3963220786e8da45a2d550058f095
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205944
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Writer paragraph styles already support percentage-based (80%, 115%)
and point-relative (+2pt, -4pt) font sizes for child styles inheriting
from a parent. Calc cell styles lacked this despite using the same
underlying SvxCharNamePage and FontSizeBox widgets.
The root cause was that Calc's ScStyleDlg::PageCreated() did not pass
the SVX_RELATIVE_MODE flag when creating the font tab page, so
FontSizeBox::EnableRelativeMode() and EnablePtRelativeMode() were
never called.
The fix adds a single SfxUInt32Item(SID_FLAG_TYPE, SVX_RELATIVE_MODE)
to the item set passed to the font page, matching what Writer's
SwTemplateDlgController already does.
No changes are needed in the core: SvxFontHeightItem::SetHeight()
already pre-calculates absolute values from relative ones, and
ScPatternAttr works correctly with these pre-calculated values.
Fix found with the help of Claude Sonnet 4.6 extended.
Change-Id: I3d759c028564a4722f96b325499ea0bfe8e4ba07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200885
Tested-by: Jakub Trzebiatowski <ubap.dev@gmail.com>
Tested-by: Jenkins
Reviewed-by: Jakub Trzebiatowski <ubap.dev@gmail.com>
svx::ODataAccessDescriptor contains properties for both a database
name and a local file database location. It parses a given name
via setDataSource() and puts the value into the correct property
depending on whether it starts with "file://" or not.
But this means that code which directly checks properties of
the ODataAccessDescriptor cannot just look for "DataSource"
but must also handle the "DatabaseLocation" property.
Net effect was that saving a Calc sheet with a cell range
backed by a database query from a local file database that was
NOT registered with LibreOffice would not save the database URL
to the .ods file, and on reload would lose the reference to the
database. This caused failures when trying to refresh the database
query.
On the UNO side creating import descriptors for a cell range
from a file with a database location would also fail to read
in the location. Fix that.
Change-Id: I7340f2d9f2f0552f436682f2b96249f39413c1fb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195173
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
Check sorting the auto-filter in a sheet view doesn't influence
the sorting in the other views.
Change-Id: Id7b4be75b2071709b67c7cb27ed7b4303029efcc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188148
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
- remove the inlines which are implicit anyway
- make compile type tests of the class
- move inline methods into body
Change-Id: If2656c1b750a300bc0ed589bc7ea6aec27b3237a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/190255
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Tomaž Vajngerl <quikee@gmail.com>
... for search vector and result vector when such vectors are given as
inline array.
AOO, Excel, Gnumeric and older LO versions allow it. Different
directions are also possible if the vector is given by a cell range.
The unintended change slipped in with commit
5079e1fb66.
Besides the unit test for tdf#167134, I have added a second unit test
about other situations that have inline arrays as parameter of LOOKUP.
LO does currently not fail for them, but this test might prevent
unintended behavior changes in the future. Such tests do not yet exist.
Change-Id: I21dd6b75d54aa938dcffbd2375acc51d3168b904
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187289
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
Some archs does not support NaN payload(e.g. riscv64).
It would be meaningless to continue building a test related
to NaN payload if the builder doesn't support this feature.
Change-Id: I895a8647bf7ff68f645faa7428d30b1c741669f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175293
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
This patch creates the API necessary to create solver models via macros, so that the model is visible in the Solver dialog, and the model is saved to the file.
This patch also includes a comprehensive unit test in scsolverobj.cxx.
Visit the bug ticket for a file with some examples of such macros.
Change-Id: Ib9cfbbdaab8243cd6b901a2bcd99e46c27be97e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171769
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
DatabaseRange has got the property TotalsRow with UI and UNO. But this
property was not written to ODF. The patch adds this as attribute
calcext:contains-footer to <table:database-range> element.
Related is issue OFFICE-4169 at OASIS.
Change-Id: I99a51198585b9b7dfb840217bdf1312f2462c9bc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173612
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
This adds the PivotTableFormatOutput, which main responsibility
is to resolve the reference for which the pivot table format is
set to. It first prepares the format data into such a structure
that it is easier to match with the pivot table fields and data.
Then the pivot table data is filled during the output, where we
remember the cell positions of the pivot table output. The last
step is to resolve the pivot table format references with the
filled data, where the cell formats are applied to the output.
PivotTableFormatsImportExport was added to test the correctnes of
the functionality.
Change-Id: Ie67ea15b3aa74739f15937800d03d256b8f68277
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165992
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
to reproduce the underlying problem: data, calc, recalculate hard:
which asserts that cell I367 is dirty during parallel calc
checking the dependencies for a parallel calc is supposed to find what
cells it depends on and either: ensure they are not dirty or detect its
not possible to do the parallel calc
checking starts in J9 where::
J9: =SUM(H$8:H9)-SUM(I9:I$9)
J10 =SUM(H$8:H10)-SUM(I10:I$9)
for the first sum it detects that the input range is H9:H367 and checks
that for dirty results, but for the second sum it detects a range of
just I9 and the dirty I367 is not detected and the problem arises on
calculation
The code to detect the range is:
// The first row that will be referenced through the doubleref.
SCROW nFirstRefRow = bIsRef1RowRel ? aAbs.aStart.Row() + mnStartOffset : aAbs.aStart.Row();
// The last row that will be referenced through the doubleref.
SCROW nLastRefRow = bIsRef2RowRel ? aAbs.aEnd.Row() + mnEndOffset : aAbs.aEnd.Row();
where for the I9 case has nFirstRefRow true and nLastRefRow false so we
just get a range of I9:I9 instead of I9:I367.
Trying to create a doc from scratch to reproduce this case proves
tricky, so trim down the original document to the sheet and subset
of columns that can trigger it.
Change-Id: I44bfd1f6d3a3ee13db9024c5b2efa2588cc30521
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165510
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
The A2 cell in the bugdoc has 01 in it, which was auto-converted to 1
(float) value on import, even if it was text originally.
This is hard to solve for HTML in general, which is not typed, but this
input is coming from google sheets, which has an additional
data-sheets-value attribute on <td> that does tell us about the type of
the cell.
Fix the problem by handling that attribute, and in case it explicitly
says it's text, then apply the matching number format.
Other types are not yet handled.
Change-Id: I2986ef864e97d9c46d191aba25ca5740a1151a71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162869
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Not a split, to avoid too many conflicts while cherry-picking, but at
least create a new suite where next tests can be added without too much
build time after source code edits.
Change-Id: I494df6e23941845a433aab6ec5ecef040feab30e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162473
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Create and check that the SdrPage, that is associated with the
current sheet, has a model::Theme available on creation.
Change-Id: I1814d4a86452b1a15ef01e0b2349d435405f4b7d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150263
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This patch implements the mechanism to save solver settings in LO Calc as well as export/import them from XLSX files.
In MS Excel solver settings are saved as hidden named ranges, so in this patch I used the same strategy to save solver settings in Calc, i.e. by creating named ranges to store the solver settings using the same terminology used in Excel.
With this we gain the ability to save solver settings by tab, as well as export/import since we already have "named ranges/expressions" import/export implemented in LO.
Change-Id: Id41bca261dc3cd8e6888643f0ed6a97b26097876
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148112
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
At least the unrelated
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/132372/> was killed
after 20 minutes of no stdout/-err activity, with CppunitTest_sc_opencl_test
still running. From its captured state, it looks like it was indeed still
making progress rather than being stuck: During
ScOpenCLTest::testLogicalFormulaXor, the main thread was waiting at
ScFormulaCell::InterpretFormulaGroupThreading ->
comphelper::ThreadPool::waitUntilDone, while four
comphelper::ThreadPool::ThreadWorker threads were each at
> #4 0x00007f70652f9234 in __gnu_debug::_Safe_iterator_base::_M_detach() () at /lib64/libstdc++.so.6
> #5 0x00007f7048d3e8e5 in __gnu_debug::_Safe_iterator_base::~_Safe_iterator_base() (this=0x7f703daa9f20) at /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/debug/safe_base.h:100
> #6 0x00007f7048d5d709 in __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<mdds::mtv::base_element_block* const*, std::__cxx1998::vector<mdds::mtv::base_element_block*, std::allocator<mdds::mtv::base_element_block*> > >, std::__debug::vector<mdds::mtv::base_element_block*, std::allocator<mdds::mtv::base_element_block*> > >::~_Safe_iterator() (this=0x7f703daa9f18) at /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/debug/safe_iterator.h:86
> #7 0x00007f7048d5d6cd in mdds::mtv::soa::detail::iterator_updater<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::const_iterator_trait>::grouped_iterator_type::~grouped_iterator_type() (this=0x7f703daa9ec8) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/./iterator.hpp:74
> #8 0x00007f7048d5d69d in mdds::mtv::soa::detail::iterator_updater<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::const_iterator_trait>::~iterator_updater() (this=0x7f703daa9e98) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/./iterator.hpp:55
> #9 0x00007f7048d5d665 in mdds::mtv::soa::detail::const_iterator_base<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::const_iterator_trait, mdds::mtv::soa::detail::iterator_base<mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>::iterator_trait> >::~const_iterator_base() (this=0x7f703daa9e98) at workdir/UnpackedTarball/mdds/include/mdds/multi_type_vector/soa/./iterator.hpp:309
> #10 0x00007f704900b9bd in ScValueIterator::GetThis(double&, FormulaError&) (this=0x7f703daaa078, rValue=@0x7f703daaa1f8: -18.819375178914722, rErr=@0x7f703daaa1f6: NONE) at sc/source/core/data/dociter.cxx:141
> #11 0x00007f704900c652 in ScValueIterator::GetNext(double&, FormulaError&) (this=0x7f703daaa078, rValue=@0x7f703daaa1f8: -18.819375178914722, rErr=@0x7f703daaa1f6: NONE) at sc/source/core/data/dociter.cxx:297
> #12 0x00007f70496c3619 in ScInterpreter::ScXor() (this=0x48b93a0) at sc/source/core/tool/interpr1.cxx:1525
with three of them apparently waiting in pthread_mutex_lock but one in
pthread_mutex_unlock (and thus presumably making progress). It looks like with
a debug-mode libstdc++ these worker threads can easily compete for these
listdc++-internal debug-mode mutices. And execution of --enable-dbgutil
CppunitTest_sc_opencl_test on my Linux laptop under load easily took 35 minutes,
so it looks plausible that that unit test was just too big.
While splitting it in two (arbitrarily taking the first and second half of the
CPPUNIT_TEST list), use the opportunity to drop the redundant "_test" from the
two new target names CppunitTest_sc_opencl-1 and CppunitTest_sc_opencl-2.
Change-Id: I9b8f148db667ff9bbf1aacdcaf150e5cb9b8ae87
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146252
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini